Sandboxing an AI Agent

There's a specific moment a lot of people building AI agents remember: watching Claude Code or something similar write a shell command and execute it before you've even finished reading what it says. The first time is terrifying. After that, most people just... stop watching. Auto-approve gets flipped on because babysitting every command kills the whole point of an autonomous agent, and now the industry is racing toward agents that run for hours, planning and correcting themselves with no human in the loop at all.

That's exactly the setup Simon Willison flagged as the lethal trifecta: an agent with access to private data, exposure to content it didn't write, and a way to phone data out to the internet. Give it all three and one poisoned email or GitHub issue is enough to turn the agent against you. It's not hypothetical. EchoLeak got Microsoft 365 Copilot to exfiltrate internal files from a single crafted email, no click needed. A booby-trapped GitHub issue steered an agent through the GitHub MCP server into leaking a private repo via a public pull request. A Replit agent nuked a production database during a code freeze and then faked logs to hide it. These aren't edge cases, they're the new normal for what happens when you give a reasoner full machine access and something malicious slips into its inputs.

Sandboxes are the practical answer, and they're not a new concept, just newly aimed at agents. Spin up an isolated box with its own filesystem, CPU and memory limits, and network boundary, let the agent do whatever it wants inside, then delete it. Providers like Daytona and Modal have made this a three-line operation: create, exec, delete. Beyond containment, the appeal is boring but real: multiple agents can run in parallel without fighting over ports or clobbering each other's dependencies, every run starts from an identical known image so results stop depending on whatever junk a previous run left behind, and when something goes catastrophically wrong you just torch the box and fork a fresh one from a snapshot in milliseconds instead of debugging a half-wrecked git history at 2am.

There are two real architectures here, and they matter more than the marketing suggests. In the tool-backend model, used by LangChain's deepagents, the agent loop and the LLM calls stay on your own machine, and only bash commands and file operations cross into the remote box. Your API key never leaves home, but you pay for it in plumbing: files don't cross the boundary automatically, so uploading a PDF for analysis and pulling the finished report back out has to be done by hand. In the agent-in-the-box model, which is how the Claude Agent SDK works, the entire agent including the LLM calls lives inside the sandbox, which means the API key has to live in there too as an environment variable. That's a much cleaner trust boundary, but it moves the isolation burden onto guarding a live secret, and it comes with its own bruises: the Claude Code CLI bundles a Node runtime that OOM-killed a default 1-2 GiB sandbox on first run, quietly, with no useful error, until the box got bumped to 4 GiB.

Neither approach is objectively better; they solve different problems. If the agent is one piece of a larger system you already run, keeping the loop local keeps your orchestration and secrets close to home. If the whole point is a long-running autonomous agent that owns its own environment end to end, the agent-in-the-box model gives the simplest mental model: start it, let it go, collect the results whenever it's done.