How to Secure Tool-Using AI Agents Before They Touch Production

Tool-using AI agents are not just chatbots with better prompts. They can read files, call APIs, run code, browse data, and chain multiple actions into one workflow. That makes agent security an engineering problem, not a vibes problem.

Docker’s practical overview frames AI-agent security around execution isolation, tool access control, identity and credential management, and runtime monitoring. Docker This Learning Hub guide turns that frame into a vendor-neutral checklist mapped to OWASP, NIST, OpenAI, and Anthropic guidance.

Why AI agents change the threat model

Traditional web apps usually expose known routes and known actions. Agents interpret instructions dynamically, decide which tools to use, and may pass data from one tool to another. Docker highlights that shift as a reason agent security needs controls around runtime behavior, not only pre-deployment code review. Docker

OWASP’s LLM Top 10 lists Prompt Injection, Sensitive Information Disclosure, Supply Chain, Excessive Agency, and Unbounded Consumption as major LLM application risks. OWASP LLM Top 10 The most agent-specific risk is Excessive Agency: an LLM system can cause damage when it has too much functionality, too much permission, or too much autonomy. OWASP LLM06

Start with an agent inventory

Before adding new controls, list what the agent can touch. The inventory should include tools, APIs, documents, databases, code repositories, external-send capabilities, identities, secrets, and actions with financial, legal, destructive, or public-facing side effects.

Ask four questions for every tool

• What data can this tool read?
• What state can this tool change?
• What identity does the agent use when it calls the tool?
• What human approval or policy check is required before high-impact actions?

This is where NIST guidance helps. The NIST AI Risk Management Framework is voluntary guidance built around Govern, Map, Measure, and Manage. NIST AI RMF The NIST Cybersecurity Framework 2.0 adds a familiar enterprise structure: Govern, Identify, Protect, Detect, Respond, and Recover. NIST CSF

Layer 1: isolate execution

Run agents in an isolated, disposable environment appropriate to the risk: a hardened container, microVM, VM, managed sandbox, or separate worker account. Docker recommends isolated and disposable execution environments because an agent may process untrusted inputs and invoke tools in sequences the developer did not pre-script. Docker

Restrict network egress

Do not let an agent reach the whole internet by default. Use allow-listed destinations, private service endpoints, DNS controls, and explicit approval for unfamiliar outbound connections. OWASP’s Unbounded Consumption guidance includes resource limits, throttling, and controls around network/API usage as part of reducing runaway or abusive behavior. OWASP LLM10

Layer 2: scope tools per task

Agents should not receive every tool the platform supports. OWASP recommends minimizing extensions, minimizing tool functionality, minimizing permissions, and avoiding open-ended tools where possible. OWASP LLM06

OpenAI’s function-calling documentation shows that developers can constrain tool use through tool choice and allowed tools, while strict schemas can make tool inputs more predictable. OpenAI function calling Anthropic’s tool-use documentation similarly treats tool calls as structured requests that the developer’s application or a server-side tool executes. Anthropic tool use

Use a tool gateway

A practical pattern is to put a policy-enforcing gateway between the model and production systems. The model can request an action, but application code checks the tool name, parameters, user identity, risk tier, rate limit, and approval requirement before anything executes.

Layer 3: defend against prompt injection

OWASP says prompt injection can be direct or indirect, including instructions hidden in websites, files, or other external content. OWASP LLM01 Anthropic’s guardrail guidance recommends treating tool outputs, document content, and search results as untrusted, labeling sources, separating untrusted content, screening tool outputs, red-teaming, and monitoring. Anthropic guardrails

Do not rely on prompts alone

Instructions such as “never leak secrets” are useful but insufficient. Put the real enforcement in code: redact sensitive values before the model sees them, validate outputs before execution, require approval for high-impact actions, and block tools that are not needed for the current task.

Layer 4: give agents dedicated identities

Do not run an agent as a full-power human user unless that is explicitly necessary. Use dedicated agent identities, task-scoped permissions, runtime secret injection, short-lived tokens, and separate credentials for separate environments. Docker recommends agent-specific credentials and runtime secret injection. Docker OWASP’s Excessive Agency mitigation guidance also emphasizes least privilege and user-context execution. OWASP LLM06

Keep secrets out of prompts and logs

Secrets should not be pasted into prompts, stored in chat history, or written into verbose agent logs. Give the runtime a way to retrieve secrets only when needed, and log that a secret was used without logging the secret itself.

Layer 5: monitor the decision chain

Agent monitoring needs more than a final success or failure message. Log the user request, selected tools, parameters, approval decisions, tool results, identity used, network destinations, errors, and final action. Docker recommends logging the full chain of tool calls, parameters, sequencing, and outcomes. Docker

OpenAI’s safety best-practices guidance recommends adversarial testing, human review for high-stakes or code-generation use cases, constrained inputs and outputs, and monitoring/reporting channels. OpenAI safety best practices

A 30/60/90-day rollout plan

First 30 days: reduce blast radius

• Inventory all tools, data sources, identities, and side effects.
• Move agents into isolated, disposable runtimes.
• Disable unnecessary tools and block open internet egress by default.
• Require human approval for destructive, financial, legal, external-send, or privilege-changing actions.

Next 60 days: enforce policy in code

• Add a tool gateway with allow-lists, strict schemas, and parameter validation.
• Create dedicated agent identities with least-privilege permissions.
• Move secrets to runtime injection with short-lived credentials.
• Label and isolate untrusted content from webpages, files, emails, and other agents.

By 90 days: monitor and rehearse failures

• Baseline normal tool use and alert on unusual sequences.
• Run prompt-injection and tool-poisoning red-team tests.
• Review logs for blocked actions and policy bypass attempts.
• Create an incident playbook for runaway tools, leaked data, bad external sends, and compromised agent credentials.

Final production checklist

• Agent runs in an isolated, disposable environment.
• Outbound network access is allow-listed.
• Tools are scoped to the task, not the entire platform.
• Tool inputs use schemas and server-side validation.
• High-impact actions require human approval.
• Agent credentials are dedicated, least-privilege, and short-lived.
• Secrets are injected at runtime and never logged in plaintext.
• Tool outputs, webpages, documents, and agent-to-agent messages are treated as untrusted input.
• Tool calls, parameters, identities, policy decisions, and outcomes are logged.
• Prompt-injection and excessive-agency tests are part of release readiness.

The goal is not to make agents harmless by asking them to behave. The goal is to design systems where a wrong or manipulated agent has fewer tools, fewer secrets, fewer network paths, and a smaller blast radius.

docker run --rm --name agent-sandbox-smoke 
  --network none 
  --read-only 
  --cap-drop=ALL 
  --security-opt no-new-privileges 
  --pids-limit 128 
  --memory 512m 
  --cpus 1 
  agent-runtime:latest ./run-agent-smoke-test.sh

docker inspect agent-worker --format '{{.HostConfig.NetworkMode}} {{.HostConfig.ReadonlyRootfs}} {{.HostConfig.CapDrop}} {{.HostConfig.PidsLimit}}'
docker logs --tail 200 agent-worker
docker info --format '{{json .SecurityOptions}}'

curl -sS -X POST https://agent-gateway.example.internal/tools/deploy 
  -H 'Content-Type: application/json' 
  -d '{"tool":"deploy","environment":"production","approved_by":null}'

python -m pytest tests/redteam/test_indirect_prompt_injection.py -q
python -m pytest tests/security/test_tool_allowlist.py -q
python -m pytest tests/security/test_sensitive_output_redaction.py -q

Featured image: locked laptop by Santeri Viinamäki, licensed under CC BY-SA 4.0, via Wikimedia Commons.