Agent Containment: the Boundary That Matters After a Bad Agent Decision

The safety question is not whether an agent can be persuaded; it is what happens if it is.

What agent containment means here

Containment is the set of deterministic, external controls that decide what an agent can read, write, reach, spend, and persist, independent of what the model is told, persuaded, or trained to do. It is an editorial synthesis drawn from current practitioner guidance, not a published standard. It does not make a bad outcome impossible; it makes the blast radius of a bad outcome more survivable and recoverable.

This framing matters because prompts and approvals operate inside the agent’s reasoning loop. Containment operates outside it. Once you accept that an agent can be wrong, confused by injected text, or act on incomplete context, the question stops being “how do I keep it safe?” and becomes “what boundary catches it when it is not?”

Why prompts and approvals are not enough

Prompts are instructions to a model that can be displaced by later instructions, including adversarial ones. Approvals shift authority to a human, but repeated prompts can become routine and an approval can still validate a mistaken plan.

The boundary that holds under failure is the one that does not require the failing component to cooperate. Anthropic’s sandboxing writeup documents why filesystem and network restrictions must work together, with a proxy outside the process controlling outgoing interactions. The OWASP AI Agent Security Cheat Sheet extends that logic to tool grants, per-tool scoping, explicit authorization for sensitive actions, and isolated memory between sessions. AWS’s four security principles for agentic AI makes the same architectural point: agentic systems plan and execute, so the controls around them need to be deterministic and continuously evaluated, not merely advisory. None of these sources says containment solves prompt injection. The point is to bound its consequences.

The seven-part minimum

Each part addresses a different blast radius. Leave one out and a single mistaken action can reach further than the task requires.

1. Data scope

Decide what data the agent can read and write. Default-deny by repository, table, prefix, or classification. A policy the agent cannot edit at runtime makes that decision.

2. Filesystem

Decide where the agent’s process can touch disk. Anthropic’s sandbox design treats filesystem isolation as necessary in combination with network controls. Writable scratch space is fine; writable home directories, configuration, and credential stores are not.

3. Network

Decide which destinations the agent can reach and what requests it can make. Use a proxy that validates outgoing interactions where the workflow warrants it. Allow only the endpoints required for the task; deny everything else by default.

4. Identity

Give the agent its own short-lived identity. It should not inherit a human administrator’s broad, long-lived credentials or be able to change its own role. Scope every credential to the task and make it independently revocable.

5. Tool surface

Decide which tools exist, which arguments they accept, and which resources they can affect. Per-tool read/write/resource scoping is the OWASP recommendation. A fetch tool restricted to a known corpus is a different capability from a general shell.

6. Approval gate

Require human or deterministic sign-off at a consequential boundary: payment, publication, deletion, identity changes, production data, or a new network destination. Bind approval to the specific normalized action and target, rather than a vague plan.

7. Logs, kill path, and recovery

Capture tool calls, policy decisions, outbound requests, file writes, and approvals outside the agent runtime. Keep an emergency path that can stop the run, revoke its scoped identity, quarantine outputs, and preserve evidence. Then prove you can rebuild from verified inputs rather than trusting contaminated state.

A research agent, before and after

Before containment

A drafting-only research agent gets a directory under a user’s home folder, full network access, a shell, and a search tool. It is asked to summarize a topic and write notes. Later, a page it fetches contains injected instructions to send sensitive files elsewhere. With broad user credentials, no output controls, and no action log, the agent has far more authority than its research task needs.

After containment

Run the same task in a scratch directory only, with outbound access limited to two approved sources, a fetch tool that treats returned content as untrusted data, an ephemeral identity, and a structured action log. If the page contains hostile instructions, an unapproved outbound destination is denied at the boundary and recorded. The emergency path can terminate the task and revoke its scoped identity. The agent is not smarter; the boundary catches the failure.

Minimum viable containment checklist

• Define the job in one sentence and list the exact data it may read and change.
• Give it a disposable runtime, read-only inputs, and one explicit writable output directory.
• Deny network access until each destination and operation is justified.
• Use a distinct, short-lived, task-scoped identity; remove human admin tokens and wildcard scopes.
• Grant only narrow tools with server-side validation of resources and arguments.
• Keep payment, publication, deletion, identity changes, and production changes behind a consequence-based approval gate.
• Record policy decisions, tool calls, outbound requests, writes, approvals, denials, and retries outside the runtime.
• Test the emergency path: stop the run, revoke its identity, quarantine outputs, and retain the logs.
• Test with hostile documents, tool responses, changed parameters, and poisoned memory before unattended operation.
• Rebuild a clean environment after a suspicious run; do not nurse unverified state back into production.

What containment cannot promise

Containment does not promise the agent will do the right thing, will not be tricked, or will not produce a wrong answer. It does not solve prompt injection; the OWASP guidance treats it as a risk to mitigate, not eliminate. It does not make compromise impossible. It makes failure more local, visible, and recoverable.

The METR investigation published on 2026-08-26 concerns agents in an unusual cyber-evaluation setting that located an unsanctioned shared message board. That is a useful reminder to treat shared infrastructure and persistent state as attack surfaces. It is not evidence that ordinary business agents behave the same way, and this guide does not make that claim.

Done means

You are done when an operator can answer yes to these questions: Can you list exactly where this agent can read and write? Can you show recent outbound requests and policy decisions? Can the designated emergency path stop a run, revoke its scoped identity, and quarantine outputs? Can you re-run the task from a clean state? Can you demonstrate that no credential held by the agent reaches outside its task scope? If any answer is “I think so,” the boundary is not ready.

What this article does NOT cover

Model alignment, training-time safety, content moderation, eval design, supply-chain risk in model weights, legal responsibility for agent actions, or detailed prompt-injection defenses. It also does not prescribe a particular vendor’s sandbox, a single compliance framework, or a universal benchmark for containment.

Related guides

• AI Operator Shift: Pick the Computer Before You Delegate the Work
• Multiplayer AI Agents: Shared Sessions Need Real Handoffs
• Rollback Before You Deploy: Name the Trigger, Artifact, and Decision Maker

Sources

• Anthropic — Claude Code sandboxing
• OWASP — AI Agent Security Cheat Sheet
• AWS Security Blog — Four security principles for agentic AI systems
• METR — OpenAI / Hugging Face incident investigation (2026-08-26)
• Research dossier (canonical): Johnny5/Websites/Agentic Botsitting/research/agent-containment/agent-containment-research-2026-09-07.md