An agent that writes and executes code is executing text produced by a probabilistic system from inputs that may include content an attacker controls. Treating that code as trusted because it came from your own model is a category error. Sandboxing is the containment answer: give the execution environment the minimum it needs, assume it will eventually be turned against you, and design so that the worst case is contained rather than merely unlikely.
Isolation comes in layers with real tradeoffs. Process-level restrictions such as seccomp and namespaces are cheap and weak. Containers are the common default and are meaningfully stronger, though a shared kernel remains a shared attack surface. MicroVMs like Firecracker and sandboxed runtimes like gVisor give near-VM isolation at close to container startup cost, which is why they underpin most hosted code-execution products. WebAssembly offers strong isolation with a restricted capability set and is a good fit for untrusted plugin code that does not need a full operating system. Full ephemeral VMs are the strongest and the slowest.
The boundary people get wrong is the network, and it is the one that matters most. Filesystem isolation gets attention because it is visible, but the dominant risk with an agent is not that it deletes a file, it is that it sends something out. A sandbox with unrestricted outbound access is not a sandbox; it is a container with a courier service. Default-deny egress with a narrow allowlist is the single highest-value control, and it directly blocks the standard exfiltration path where injected instructions convince an agent to post retrieved data to an attacker endpoint.
The rest is discipline about what goes in. Credentials are the classic mistake: mounting the parent process environment gives the sandbox every API key the host holds, so scoped short-lived tokens issued per task are the correct pattern. Filesystems should be read-only with a writable scratch directory that is destroyed afterwards. CPU, memory, wall-clock, and spend limits need to be enforced by the runtime rather than requested in a prompt, since a runaway loop is both a cost incident and a denial-of-service on your own capacity.
Sandboxing sits at a specific place in the assurance stack and it helps to see it there. Formal verification proves properties about the boundary, policy engines decide what is permitted, and sandboxing enforces the decision at runtime. All three are outside the model on purpose. Anything you enforce by instructing the model is a preference, not a control.
Why It Matters
Code-executing agents are now standard in developer tooling, data analysis, and automation, which means arbitrary generated code runs against real infrastructure many times a day. The exposure is not hypothetical: indirect prompt injection through a fetched page or an uploaded document is a well-documented path from untrusted content to executed code. Sandboxing is what makes that path survivable, and it is one of the few controls that holds regardless of how convincing the injection was.
Example
A data analysis agent runs generated Python against uploaded customer files. A crafted CSV includes a comment instructing the agent to load the credentials file and POST its contents to an external host, and the model complies. In the original setup the container inherits the host environment and has open internet access, so the keys leave the building. After hardening, the sandbox has no host credentials, a read-only mount limited to the single uploaded file, and default-deny egress with only the internal analysis API allowlisted. The same attack still runs and produces a connection error.