Agent Containment: What a Boundary Is Actually Made Of

What these stories usually describe

Reports of an agent doing something outside its sandbox are worth reading carefully, because the interesting detail is almost always the same and it is rarely the one in the headline.

The agent did something it was permitted to do. Not through cleverness or intent, but because the permitted set was larger than anyone had written down. A test harness with a real network path. A container with credentials mounted for convenience. A file write that was scoped to a directory whose symlink pointed elsewhere. A shell tool with no allowlist, in an environment where a shell can reach the internet.

So the useful question is not whether a model wanted to exceed its boundary. It is whether anyone enumerated the boundary in the first place, and whether the enumeration was enforced somewhere the model cannot influence.

That reframing matters because it moves the work from speculation about model behavior to ordinary systems engineering, where the techniques are known and the results are testable.

Instructions are not boundaries

The single most common design error is putting a constraint in the prompt and treating it as a control.

A sentence saying the agent must not touch production sits in the same channel as everything else the model reads: the task, the tool output, the web page it just fetched, and any text that arrived from outside. It is weighed rather than enforced. Under pressure to complete a task, with a plausible justification in front of it, a model can reason its way past its own guidance, and it will do so while explaining why this case is different.

That is not deception. It is what generation conditioned on a whole context window does.

A boundary is something the agent cannot cross even when it concludes that it should. In practice that means the operating system, the network layer, and the credential itself, not the system prompt. The test for whether you have a control or a suggestion is simple: could a sufficiently confident wrong decision by the model get past it? If yes, it is a suggestion.

The four layers to enumerate

Process. What can the agent execute, and what can those processes do? A shell tool inherits the environment it runs in. If that environment has network access, package installation, and ambient credentials, then the shell tool has all of those regardless of what your tool description says.

Filesystem. Which paths, read and write, resolved rather than declared. Directory scoping that does not resolve symlinks and relative traversal is scoping in name only, and this is the classic way a containment assumption turns out to be false.

Network. Which destinations. Default deny with an allowlist is the only version of this that holds, because the failure mode of default allow is exfiltration through any channel the agent can reach, and there are always more channels than you enumerated.

Credentials. What the agent's tokens can do, at the provider, not in your code. A key scoped to read is a boundary. A key scoped to everything, with your application choosing to only read, is a hope.

Write these four down for any agent that runs unattended. The exercise usually surfaces at least one permission nobody knew was there, and it takes an afternoon rather than a project.

Test it, and reduce what needs testing

An untested control is an assumption. Try to cross each boundary deliberately: have the agent attempt a write outside its scope, a call to a destination not on the allowlist, and an action its credential should refuse. Confirm the refusal comes from the layer you intended rather than from the model declining politely, because those look identical in a transcript and are completely different in an incident.

Then reduce the surface that needs containment at all.

A large share of what agents reach for is knowledge rather than capability: reading files to understand a system, fetching documentation, re-deriving conventions. Every one of those is a reason to grant broader filesystem or network access than the task actually requires.

Retrieval removes much of that pressure. RDK indexes files from local vaults, docs, and code as encrypted private chunks, and agents search those chunks before querying a model, so the answer arrives without the agent needing to roam the filesystem or the network to reconstruct it. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated, and the permission surface shrinks alongside it.

That is the quieter benefit of a knowledge layer: an agent that does not need to go looking is an agent you can confine more tightly.