The Lockdown Room: Why AI Agents Need a Machine of Their Own
Vivek Pandey (JoyStream CTO) on isolation, ephemerality, and why sandboxing just became as fundamental as Docker was to cloud apps.
3 min read
Watch the full conversation: Why AI Agents Need Sandboxes
Next in this series: Four Things That Don't Live in Your Agent's Sandbox (And Why That's the Point)
Why Agents Started Needing a Computer, Not Just a Prompt
Everyone running a coding agent locally today is handing it the keys to everything.
Not metaphorically. Codex, Claude Code, any agent running in your local shell inherits your entire environment — every secret, every credential, every variable you've ever exported. That was a tolerable risk when agents mostly read and wrote text. It stopped being tolerable the moment agents started doing real work: downloading a CSV and turning it into a report, pulling a script off GitHub and running it, installing a package to finish a job. Each of those is a request for actual operating-system access — file I/O, execution, network — not a request for better autocomplete. And OS-level access is exactly where things go wrong: a downloaded script can carry malware nobody asked for, and two agents wanting two different Python versions on the same host will happily break each other.
The agents didn't get more dangerous. They got more capable, and capability on a shared machine is a liability with a delay on it.
What a Sandbox Actually Gives an Agent
A sandbox is just a computer, handed to an agent that shouldn't be trusted with yours.
Hardware, an operating system, the packages it needs, network access, enough memory and CPU to actually finish the job — all of it, under policy you set in advance. The part that's easy to get wrong is assuming a Docker container is sufficient isolation. It isn't. A standard container can run as root and reach into host files, which defeats the entire point. The isolation that actually holds is VM-level — Kata containers, hardened virtual machines, the kind of boundary that doesn't ask the agent to behave itself. This isn't an obscure enterprise pattern anymore, either: Apple now ships Kata-style container isolation built directly into macOS. It's already running on laptops that have nothing to do with agent infrastructure.
The room has to be locked before the agent walks in, not after something goes wrong inside it.
Why Sandboxes Get Thrown Away, Not Reused
The sandbox that worked perfectly yesterday is the one that'll burn you tomorrow, if you let it stick around.
Every sandbox gets seeded with whatever a specific task needs — sometimes that's sensitive company data. Reuse that same sandbox for the next agent, and whatever was seeded for the first task is now sitting there for the second one to find. It's not even always a security problem. Sometimes it's just wrong: a leftover file with the same name as something the new agent expects, holding completely different contents, quietly corrupting a result that looked fine. The fix isn't more careful cleanup logic. It's refusing to need cleanup logic at all — spin the sandbox up, run the task, garbage-collect it. Every time, no exceptions, no sandbox old enough to have a history.
An environment with no memory can't leak one.
Sandboxing Is Becoming What Containers Were to Cloud Apps
Cloud computing didn't get dependable until every workload got its own disposable box.
That box was the container, and Docker turned it into the unit the entire industry built on. The same shift is happening again, one layer up: OpenAI's hosted sandbox, E2B, AWS Lambda microVMs, Kata containers — the infrastructure already exists, connected by the same idea, that an agent needs a machine nobody else is using and nobody will reuse after it. What's missing isn't the technology. It's the habit. Most teams running agents in production haven't asked themselves this question once, and the ones who have mostly answered it with a shared VM and a hope.
The agent was never the risky part. The room you let it run in always was.