Agent sandboxing — what isolation actually means for autonomous agents

It is worth separating these explicitly, because both get described loosely as “agent security” and the distinction matters for where a finding gets routed. Tool-use permission scoping governs what the agent is allowed to do — which APIs it can call, which data it can read or write, whether a given action requires human approval. That boundary is enforced by the tool manifest and the authorization checks each tool performs, and it assumes the agent's own execution is trustworthy: the review question is about the agent's declared capabilities, not about whether the agent could act outside them.

Sandboxing governs something upstream and independent of that: given the agent's execution — whatever code it runs, whatever tools it was granted — is that execution actually confined to the compute, filesystem, and network boundary the architecture intends, or can it reach further than the tool manifest suggests by escaping the runtime itself? A system can have an exemplary least-privilege tool manifest and a completely porous execution boundary, or the reverse. A review that only asks about tool scope has not asked about isolation at all.

The practical difficulty is that “sandboxed” is satisfied, in a narrow technical sense, by an enormous range of implementations with very different real-world guarantees. A subprocess launched with a resource limit is, in one sense, sandboxed — it cannot exceed a memory or CPU ceiling. A container with default namespace isolation is sandboxed in a stronger sense — it has its own process tree and, depending on configuration, its own filesystem view. A microVM (Firecracker, gVisor and similar) is sandboxed in a stronger sense again — it does not share a kernel with the host in the way a container does, which closes off an entire class of container-escape techniques. Each of these is a legitimate use of the word, and each carries a materially different breakout difficulty and blast radius.

The four dimensions below are what a real isolation boundary has to bound, regardless of which specific technology implements it. A review that names the specific technology — which container runtime, which VM type, which network policy engine — can be checked against known properties of that technology. A review that accepts “sandboxed” without that specificity has verified nothing.

The first dimension is the most literal reading of “sandboxed”: can the agent's execution escape the compute boundary it was allocated, reaching resources, processes, or a kernel it was not meant to touch? The strength of this guarantee varies enormously by implementation. A plain subprocess with a cgroup resource limit shares the host kernel entirely — it bounds CPU and memory consumption but does nothing to prevent a kernel exploit or a misconfigured capability from granting broader access. Container-based isolation (Docker, standard runc) improves on this with namespace separation but still shares a kernel with the host, which is the attack surface every container-escape vulnerability targets. A microVM adds a hardware-virtualization or user-space kernel emulation boundary that closes off shared-kernel escape paths entirely, at a real cost in startup latency and operational complexity.

In many agent frameworks, the “sandboxed code execution” feature advertised in the product documentation is, on inspection, the first of these three — a subprocess with a timeout and a memory limit — not a genuine isolation boundary against a determined escape attempt. That is not necessarily wrong for every deployment context, but it is a materially different risk posture than the microVM option, and a review has to know which one it is looking at rather than accepting the marketing term.

The second dimension is whether the agent's execution is actually confined to a designated working directory, or whether it can read or write outside that scope. The architecture diagram's promise is usually something like “the agent operates within /workspace” — a convention, not necessarily an enforced boundary.

The common failure here is a mounted volume that grants broader access than the working-directory convention implies. Containers running agentic workloads frequently mount a shared volume for artefact output, dependency caching, or shared model weights across multiple agent instances — and that mount, if it is writable and not itself scoped narrowly, gives the agent filesystem reach well beyond its declared working directory. A second, subtler failure is symlink or path-traversal handling inside the container: a working-directory convention enforced by application-level path validation, rather than by the container runtime's own filesystem boundary, can often be defeated by a crafted relative path or a symlink the agent is tricked into creating.

The third dimension is the one we see left unaddressed most often, because it requires a distinct configuration step from the compute and filesystem boundary and is easy to treat as someone else's concern. Bounding compute and filesystem access does nothing to prevent an agent's execution from reaching arbitrary external hosts if the sandbox's network policy is left at its default. Container runtimes commonly default to outbound-open networking — a container can reach the public internet unless a network policy explicitly restricts it — because the default is oriented toward developer convenience, not toward a production security boundary.

The consequence is a specific and serious one: an agent that can execute code and reach arbitrary hosts can exfiltrate data through that channel regardless of how tightly its tool manifest is scoped. A code-execution sandbox with no outbound network tool in its manifest is not protected against exfiltration if the underlying container itself has unrestricted network egress — the exfiltration does not need a tool call at all; it needs a line of generated code making an HTTP request, which the sandbox's network layer, not its tool manifest, is the only thing positioned to stop. This is precisely why network egress belongs to the sandbox boundary and not to the tool-permission review: it is a property of the execution environment, independent of what tools were ever declared.

The fourth dimension asks the question a single-layer isolation review tends to skip: what happens if the isolation boundary itself is compromised? Every isolation technology has a non-zero breakout probability — that is why defense in depth exists as a concept at all — and the review question is not whether breakout is possible, but what an attacker who achieves it actually reaches next.

A sandbox running as the only isolation layer, on the same host as the orchestrator process, the credentials it holds, and potentially other tenants' agent executions, turns a single breakout into full host compromise — the orchestrator's secrets, other agents' data, and whatever else shares that host become reachable in one step. A sandbox running as one layer inside a second, independently privileged isolation boundary — a dedicated, network-isolated host or VM per execution, with the orchestrator and its secrets held entirely outside that boundary — contains a breakout to that single execution's narrow blast radius instead.

This is the dimension most architecture diagrams do not represent at all, because the diagram typically stops at “agent runs in sandbox” and does not show what sits around the sandbox. A review has to ask the question the diagram does not answer on its own.

The gap between the box labeled “sandbox” and what the runtime actually enforces is rarely a case of a vendor or an internal team deliberately misrepresenting the architecture. It is far more often the result of the isolation boundary being designed once, for one purpose — usually resource management or a basic security gesture during initial development — and never revisited as the agent's capabilities grew. A sandbox scoped adequately for an agent that only reads files can be entirely inadequate once the same runtime is extended to make outbound API calls, and the diagram's “sandbox” label does not change to reflect that the guarantee it once represented no longer holds for the current capability set.

The practical takeaway for a review is that the word itself carries no information. What carries information is the specific answer to each of the four dimensions above, named against the specific technology in use — not a generic architecture-diagram label that has to be taken on faith or, equally often, has simply gone stale relative to what the agent can now do.

A review has verified the sandbox boundary, rather than accepted the label, when it can answer each of the following with a named technology and configuration detail, not a description:

• Compute isolation: what specific technology enforces the boundary — subprocess with resource limits, container, or microVM — and what shared-kernel exposure, if any, does that choice carry?
• Filesystem scope: what is the full mount table for the execution environment, not just the declared working directory, and is every writable mount justified against the agent's actual task?
• Network egress: is outbound network access allow-listed to specific destinations, or open by default? Is the policy enforced at the network layer, independent of whether the tool manifest includes a network-capable tool?
• Breakout blast radius: is there a second, independently privileged isolation layer around the sandbox, or does a successful breakout reach the orchestrator, its credentials, or other tenants' executions directly?
• Currency: when was the isolation boundary last reviewed against the agent's current capability set, and has that capability set grown since the boundary was designed?

Where a vendor or internal team cannot answer these with specifics, the honest finding is not “isolation is broken” — it is “isolation is unverified,” recorded as an evidence gap with an owner, not accepted on the strength of a single word in an architecture diagram.