Four Things That Don't Live in Your Agent's Sandbox (And Why That's the Point)

Watch the full conversation: 5 Questions Before You Trust an Agent Sandbox

Previous in this series: The Lockdown Room: Why AI Agents Need a Machine of Their Own

Next in this series: Where Does an Agent Actually Live, If Not Inside Its Sandbox?

The Sandbox Is Never the Agent's Whole Life

The sandbox is never the agent's whole life. It's one task inside it.

An agent breaks a problem into steps before it does anything else, and only some of those steps need isolation — the rest don't touch a file system or a network at all. Deciding which is which isn't the sandbox's job; it belongs to a layer above it, an orchestrator. Claude Code is one. Codex is another. JoyStream's Agent Builder is a third. Different names, same concept — a meta agent that choreographs the steps and decides where each one actually runs. That orchestrator can itself be running inside a sandbox, inside some VM, and it still has to go find a separate place for every agent it's managing underneath it. A sandbox's real unit of work is a task — ten scripts at once, or one — never the agent's entire existence.

Confuse the task with the agent, and the architecture breaks before it ever gets interesting.

A Sandbox Doesn't Remember Anything, on Purpose

A sandbox doesn't remember anything, on purpose.

Think of it as a plain input/output system: you give it something to do, it hands back a result, and that result is the state — not anything stored inside the box itself. Sandboxes get created, used, and thrown away the same way an operating-system process does, and they can crash or get killed at any point without anyone needing to care. Try to bake state into one anyway, and the sandbox effectively has to live forever to protect it — which defeats the entire reason it existed. The discipline is narrower than that: keep nothing in a sandbox beyond what one task strictly needs, then let it go.

A sandbox with no memory has nothing left to lose when it dies.

The Reasoning Loop Lives Somewhere Else Entirely

The reasoning loop lives somewhere else entirely — never inside the thing doing the work.

Picture an agent assembling an executive sales briefing: pulling numbers from Salesforce, pricing data from another system, deal history from a third, any one of which can fail mid-run and needs a retry before the actual slide deck gets built. Some of that has to happen in sequence. Some of it can run in parallel. None of it can be choreographed from inside a single sandbox, because at any given moment the orchestrator may be running several of them at once just to finish one job. The person who actually writes the agent doesn't need to think about any of this — from where they sit, sandboxing is an implementation detail the platform is supposed to handle, not a decision they make themselves.

The Easiest Way to Design This Is Also the Most Dangerous One

The easiest way to design this is also the most dangerous one.

The simplest approach injects an agent's real credentials — Drive access, CRM keys, whatever a task needs — directly into the sandbox as environment variables, available to every process that runs there. It works, right up until one of those processes is a script pulled from somewhere outside the company and quietly compromised. At that point, the blast radius isn't the one task that script was supposed to perform. It's every credential that sandbox ever had access to, and there's a real chance nobody notices for a while. The alternative is to never let the sandbox see a real credential at all — hand it a short-lived token, scoped to one tenant and one agent, that can only call back through a proxy layer holding the actual secrets encrypted elsewhere. The token dies the instant the sandbox does.

The leak gets smaller. It doesn't disappear.

What Survives a Sandbox Matters as Much as What Runs Inside It

What survives a sandbox matters as much as what runs inside it.

Logs and generated artifacts need to outlive the box they came from — error streams, standard output, whatever the task actually produced — because without them there's no way to audit what happened, debug what failed, or justify what it cost to run. There's a smaller, less obvious problem underneath that one: no platform can pre-pack every tool or package version an agent might ever need, so the work of making an agent portable falls on whoever wrote it, not the sandbox underneath it. Ask any vendor claiming to offer "agent sandboxes" where the execution boundary actually sits, where state lives, and what a compromised task can and can't reach — the answers tell you more about the architecture than the word "sandbox" ever will.

The room was never the hard part. Knowing what's allowed to walk out of it still is.