Agent sandboxing

Agent sandboxing restricts the environment in which an agent’s requested code or tools execute. The boundary is implemented by surrounding software and operating-system mechanisms, rather than by asking the model to behave cautiously. gVisor illustrates one design: an application kernel called the Sentry handles application system calls, while a separate Gofer mediates filesystem access. This is a particular isolation architecture, not the definition of every sandbox. 1

The boundary needs a threat model

The gVisor security model aims to reduce exposure to host system interfaces through layered restrictions. It also describes limits: hardware side channels, host resource controls and other reachable services require separate consideration. Its documentation explicitly treats a sandbox as one part of a secure architecture. These statements concern gVisor’s design and assumptions; they do not prove that any environment labeled “sandboxed” provides equivalent isolation. 2

For an illustrative research assistant, the threat model could include a tool accidentally overwriting an unrelated file, untrusted downloaded code running a subprocess, or a generated command attempting an unauthorized connection. A proposed sandbox would need to state which of those actions it constrains and what remains reachable. Listing the threats would be more informative than simply displaying a sandbox badge.

Files and network are separate surfaces

Anthropic’s 2025 engineering announcement describes filesystem and network isolation for its agent coding tools. It explains directory restrictions and an external proxy enforcing allowed network destinations, including restrictions applying to subprocesses. This is vendor architecture guidance for the described implementation. It should not be generalized into a claim about current defaults, all coding agents, or a measured security guarantee for this website. 3

In the research-assistant example, a writable scratch directory would not answer whether the process can also contact arbitrary servers. Conversely, blocking external connections would not answer whether it can modify an unrelated local project. A useful boundary description would separately identify permitted reads, writes and destinations, along with how exceptions are handled.

The relevant unit is the actual executing process and its descendants. Naming the assistant’s top-level tool is insufficient if the command starts other programs with different access. The cited vendor example discusses subprocess coverage; 3 a different implementation would need its own evidence of what inherits the restrictions.

Isolation is not unlimited compatibility

gVisor’s overview notes that its Linux-compatible environment does not implement every system call or interface, so some applications may be incompatible. Restricting exposed behavior has practical consequences for what software can run. 1 A failure inside a sandbox could therefore reflect an intentional boundary or a compatibility gap, rather than evidence that a task needs unrestricted access.

For the example, a denied write would be recorded as denied. A recovery step could choose another permitted way to produce a reviewable artifact, or stop with the boundary stated. It would not silently interpret a failed operation as successful. This is a proposed recovery criterion, not a claim about a deployed assistant here.

Permissions and content still matter

The gVisor security model allows applications to use resources exposed inside their environment and relies on additional controls for resource exhaustion and network policy. 2 Isolation consequently does not settle whether a reachable application operation is appropriate. Tool permissions address that action-level boundary; prompt injection addresses attempts to redirect the agent through untrusted material.

A sandboxed assistant could still produce an unsupported statement in a permitted output file. Factual review needs different evidence. An observability record could show that a command was denied or completed, while human oversight could decide how to respond. Tests of the example would inspect the actual filesystem, connection policy and action outcome, including subprocess behavior and interruption. Sandboxing can limit consequences within a stated model; it does not certify the whole agent.