Explore

How sandboxes contain an agent

Put a coding agent in a box, one control per step, and see what each control stops and what still gets through. About 10 minutes.

Step 01 of 06

The box

At the invoicing software company from How software gets built with AI, a developer hands a coding agent (Claude Code, Copilot, Codex, Cursor) a GitHub issue: upgrade the PDF library from version 4 to 5. The model, at a lab such as Anthropic or OpenAI, proposes commands and never runs them. They run in a sandbox holding a copy of the repo, on the vendor's machines for a cloud agent (this page follows one) or on the developer's laptop for a local one. Under it is the host machine, in the cloud shared with other customers. Containment is everything that limits what the agent can reach and change, whatever the model decides. A container fences off files and processes but shares the host's kernel (the core of the operating system) with every other container on it. Google's gVisor puts a stand-in kernel in between. A micro-VM gets its own kernel: AWS's Firecracker, which runs Lambda, boots one in under 125 milliseconds.

Your guess

The agent installs version 5, and one of its packages runs a script that hunts for keys. In a fresh container in the vendor's cloud, what does the script find?

Make a guess to continue.

The answer is C. A fresh container holds only what was put in it. On developers' own machines it's different: in the Nx attack (August 2025), poisoned packages tried to drive coding agents to hunt for credentials, and 2,349 were taken from 1,079 systems.

What can go wrong now

“Sandbox” covers boundaries of very different strength, and vendors don't always say which. A container is the weakest for code nobody has read, since a kernel bug is a way out to the host and the other customers on it. Even gVisor's docs say a sandbox is no substitute for a secure design.

How teams handle it

Ask every vendor what boundary, what network and what credentials sit inside. Prefer a micro-VM or gVisor for code nobody has read, and start each task in a fresh sandbox, so nothing planted in one run waits for the next. More in AI agents: what limits the damage.

Next:The box limits the script to what's inside, so what you put inside matters: What's inside.

Questions people ask

Does the model run inside the sandbox?

No. The model runs at the lab and only sends back text, including the commands it wants run. The sandbox is where those commands run, and the coding agent passes the results back. That's why containment holds whatever the model decides: the walls are around the commands.

How long does one sandbox live?

It depends on the vendor. OpenAI's containers expire after 20 idle minutes, Anthropic's code execution containers after 30 days, and AWS's micro-VM sessions after up to 8 hours. I'd still start each task in a fresh one, since anything that lives on can carry what a bad run planted.

Who's liable if code escapes the sandbox?

On AWS the split is written down: AWS answers for bugs in the isolation, and the customer for how the sandbox's role is scoped. So the role is yours to get right, even on a managed platform.

What about an agent on a developer's laptop?

The operating system's own sandbox can limit what it writes to the working folder: Claude Code does this on macOS and Linux. Without one, a local agent acts with the developer's own credentials and files, the riskiest case.

What's the sandbox for the support agent in How agents fail?

There isn't one in the same sense. That agent calls the company's own tools on its servers, such as looking up an order or issuing a credit, so its limits are scopes, amounts and approvals. A sandbox matters once an agent runs code or commands nobody has read. Browser agents get one too: a separate browser in its own virtual machine.