An agent that can write and execute code is dramatically more capable than one that cannot. It is also running code nobody reviewed, generated by a system that can be influenced by any document it reads. The model is not adversarial. The content reaching it might be, and the code it produces in response is the payload.
Treating that code as untrusted is not paranoia. It is the same posture you would take toward code submitted by an anonymous user.
What changed in 2026
- Hosted sandboxes became a product category. Managed execution environments purpose-built for agent code, with isolation and lifecycle handled for you, moved into general availability.
- Lightweight virtualization spread. Microvm approaches offering hardware-level isolation with near-container startup times became practical for per-request sandboxes.
- Egress control became the emphasis. As isolation improved, attention shifted to what a sandboxed process can reach over the network, which is where exfiltration actually happens.
- Indirect injection drove the threat model. Attacks arriving through retrieved documents rather than user input became the primary scenario people design against.
Isolation levels
| Level |
Protects against |
Weak against |
Startup |
| Same process, restricted interpreter |
Casual mistakes |
Determined escape |
Instant |
| Separate process, user isolation |
Accidental file access |
Kernel exploits, egress |
Fast |
| Container |
Most filesystem and process access |
Kernel exploits, egress by default |
Fast |
| Microvm |
Kernel-level escape |
Misconfigured egress |
Fast enough per request |
| Full virtual machine |
Nearly everything |
Egress, cost |
Slow |
| Separate physical network segment |
Lateral movement |
Nothing much |
Infrastructure |
Notice that egress appears in nearly every row. Isolation technologies focus on preventing a process from touching things on the host, and they say nothing about what it can send over the network. A perfectly isolated container that can reach the internet can still read whatever data was handed to it and post it somewhere — which is the actual attack, not a kernel escape.
What to configure
Deny egress by default. Allow only the specific hosts the task genuinely requires. This single control blocks the exfiltration path that all the isolation work does not address.
Set resource limits. Memory caps, CPU quotas, execution timeouts, and process count limits. The overwhelming majority of sandbox problems are not attacks — they are generated code with an infinite loop or an accidental fork bomb, and limits turn those into a clean failure rather than a dead host.
Make it ephemeral. Destroy the environment after each task. State that persists between tasks is state an earlier task can leave for a later one, and it removes any confidence about what is in there.
Mount data narrowly. Give the sandbox exactly the files the task needs, read-only where possible. Do not mount a home directory because it is convenient.
Never place credentials inside. If the task needs an authenticated call, proxy it through a service outside the sandbox that holds the credential and enforces scope — which is the containment principle in AI agent permissions.
Log everything the sandbox executed and every network attempt it made. When something odd happens you want the record, and denied egress attempts are a genuine signal worth alerting on.
Common mistakes
- Allowing open network access. Undoes the isolation for the attack that matters.
- Reusing environments across tasks. Leaked state between unrelated work.
- Credentials mounted into the sandbox. Now the boundary protects nothing valuable.
- No resource limits. Ordinary bugs take down the host.
- Running on a developer machine. Convenient, and that machine holds keys and customer data.
- Trusting the model to behave. The model is not the threat; the content it reads is.
FAQ
Is a container enough?
For low-stakes scratch work with egress denied, usually. For anything adjacent to production data or credentials, use stronger isolation.
Are hosted sandbox services safe?
Reputable ones provide better isolation than most teams build themselves. Verify their egress model and data handling rather than assuming.
What about running code in the browser?
Browser sandboxes are strong and constrain what code can do. Useful for computation, insufficient when the task needs filesystem or network work.
How do I let an agent call an API safely?
Proxy it. A service outside the sandbox holds the credential, enforces scope and rate limits, and the sandbox calls that.
Where to go next
For the permission model around it, read AI agent permissions. For the injection vector, prompt injection defense, and for connector risk, MCP security risks.