A team I worked with wanted to let an AI agent loose on their own systems. A chatbot answers questions; this one would read a support ticket, pull the relevant records, draft an action, and carry it out. The build looked like an afternoon’s work. What stopped them for a month was a single question from their head of IT: what happens when it’s wrong?
Not if. When. An agent that can act is an agent that can act wrongly. It can delete the folder it meant to tidy, email the wrong customer, or follow a hidden instruction buried in a document it was only supposed to read. The team did not need the agent to be perfect. They needed a place where being wrong was survivable.
That place is a sandbox, and it has quietly become one of the load-bearing pieces of any serious enterprise AI setup. But before you buy one, you need to be precise about what you are buying — because the most common misunderstanding about sandboxes is also the most expensive one. A sandbox is not a privacy filter. It will not keep your confidential documents away from the model. What it does is narrower, and, understood properly, more valuable. This piece is about that distinction, what the box actually does for you, and how to adopt one without overpaying or overbuilding.
What a sandbox actually is
A sandbox is an isolated, disposable space where an agent’s code runs without touching your production systems. You spin one up, let the agent work inside it, and throw it away. If the agent does something reckless — installs something it shouldn’t, deletes something it shouldn’t, reaches for something it shouldn’t — the damage dies inside a box you were always going to discard.
The name borrows from the children’s sandbox: a bounded patch where making a mess is the point, and the mess stays in the pit. Two properties do all the work. Isolation means the code inside cannot reach out and touch what it should not. Disposability means the whole environment is cheap to create and cheap to destroy, so you never hand an agent a box that a previous run already contaminated.
What a sandbox governs: the agent’s untrusted code runs inside a walled box, reaching your estate only through the doors you configured. Note what the wall does not govern — the content the agent reads still travels to the model, because the model must see it to work on it.
This became a board-level question, rather than a niche engineering one, the moment AI agents started writing and running their own code. That code is untrusted in a precise sense: nobody reviewed it line by line before it ran.
It can go wrong in two directions. An adversary plants a hidden instruction (a poisoned document, a booby-trapped bug report) and the agent’s next action becomes an attack. Or the model, trying to be helpful, reaches for more access than it should and touches something it was never meant to.
For years the reassurance was that it probably wouldn’t break out of its environment. That reassurance is worth less every month: capable models can now read public vulnerability reports and chain several small weaknesses into a real escape. That is the direction the people who build this infrastructure describe; read it as a trend line, not as a measured breakout rate.
What the box does not do
Here is the sentence that should be printed on the side of every sandbox: whatever the agent reads, it reads for the model.
An agent works by sending what it sees — the ticket, the contract, the case file — to a language model, because the model must see the content to reason about it. That flow crosses the sandbox wall by design. It is not a leak; it is the product working. Even in the most locked-down configuration on the market — a sandbox self-hosted on your own infrastructure — the vendor’s own documentation states it plainly: tool inputs and outputs still flow to where the model runs, so the model can see results and decide what to do next. No isolation level changes that, because no isolation level can: a model that cannot see your document cannot summarise it.
So if the question on the table is “may these documents go to a model at all, and on what terms?”, the sandbox is the wrong place to look for the answer. That question is governed by the deployment boundary: which region the model runs in, what is retained and for how long, and under what contract. It is exactly the question we worked through in running Claude Code on Amazon Bedrock for regulated data, and the honest one-line summary of that piece applies here: no training does not mean no transmission. The deployment boundary addresses the data. The sandbox addresses the acting agent. A serious setup combines both, and neither substitutes for the other.
There is one genuine data-protection contribution the sandbox does make, and it is worth stating precisely because it is real: egress control. A good sandbox lets you pin the short list of destinations the agent’s code may reach, and deny everything else. That matters most in the ugly scenario — a prompt injection that turns your agent against you — because a hijacked agent that wants to smuggle your files to an attacker’s server finds there is simply no road out. Sandboxes limit what code can send. They do not limit what you already chose to show the model. Keep those two sentences apart and you will reason about this better than most of the market.
A fence is not a wall
Not all isolation is equal, and the gap between the kinds is where the expensive surprises sit. Think of it as a ladder from no barrier to a real one.
Run the agent’s code directly on your machine and there is no barrier at all: it executes as an ordinary process on your real system, with all the reach that implies. Put it in a container (the Docker-shaped default most teams reach for first) and you get a fence. Containers keep workloads tidy and resource-bounded, but they share the host’s underlying kernel, so a determined exploit can step over the fence onto the host.
A user-space kernel such as gVisor raises the fence, though a sophisticated two-step attack can still find a way through. Only a micro-VM (the technology behind names like Firecracker) gives you a wall: the agent’s code sits behind its own kernel and a hardware-enforced boundary. Full control inside the box buys an attacker close to nothing outside it — the vendors themselves say “strong”, not “perfect”, and that is the honest register.
A 2026 OpenAI engineering talk on designing an agent sandbox cloud carries the whole lesson in one line: everyone always wants a VM, because they tried everything else first. I am paraphrasing an engineer’s hard-won intuition there, not citing a measurement. Teams optimise for speed or simplicity, hit a security incident, and then migrate to the wall. The cheaper version of that lesson is to start at the wall for anything running untrusted AI-generated code.
For you as a buyer, all of this collapses into one question you can put to any vendor. Is my agent’s code behind a fence or a wall?
The two jobs a sandbox does for you
Most people meet the sandbox as a security control, and it’s one. But in an enterprise it does a second job that is equally valuable, and the two share the same boundary.
One box, two jobs. The boundary you build to keep danger in is the same boundary you use to let the right capability in.
The first job is containment. It’s what lets you run untrusted or agent-generated actions without holding your breath. A mistake or a hijack is confined to the box, so an agent cannot delete the shared drive or write to production — because production was never mounted into its world, and the shared drive is not on its egress list. That last clause matters: the box enforces the boundary, but you decide what is inside it. Keeping live customer data out of the box is a provisioning decision the sandbox makes enforceable, not a property it grants on its own.
The cleanest version of this handles secrets by never giving them to the agent at all. Instead of loading your payment or email credentials into the agent’s environment, the platform injects them at the boundary, by name, only for the specific call that needs them. An attacker who tricks the agent into “print all your secrets” gets nothing, because the agent never held a real one. And because everything passes through a single boundary, the agent’s actions can be logged and replayed afterwards — a feature you should demand rather than assume, and one layer of the audit trail a regulated firm needs (the model-side half of that trail lives at the deployment boundary, with the data).
The second job is enablement. The same walled space lets you give a team real capability without opening the whole estate to them. You switch on exactly the tools that team needs, the way you tick boxes on a form: browser access here, a database connection there, file storage for another. You hand the agent a closed list of internal services it may reach, and it can reach those and essentially nothing else.
Some platforms go further and give each agent its own identity, even its own email address, so a non-technical colleague can email the agent directly and get a reply. Security says nothing gets out. Enablement says the right things get in. It’s the same primitive, pointed at two problems your leadership team probably files in two different places.
What this looks like on the ground
Three shapes the pattern takes inside a mid-sized company.
The one that comes up most is regulated document work, and it is exactly where the containment/confidentiality distinction earns its keep. A regulated firm I work with wanted agents to read, summarise, and cross-check its own documents: contracts, case files, the internal knowledge base. Two separate controls made that project defensible, and it is worth being precise about which did what. The deployment boundary answered the confidentiality question: whether those documents may go to a model at all, in which region, with what retention, under what agreement. The sandbox answered the conduct question: what the agent’s code could do while working on them — a working copy rather than the live archive, no connection to the customer database (demonstrably: it simply is not mounted or allowlisted), no production credentials, and a pinned list of reachable services. When the auditor asked, the deployment boundary was the data-protection story and the sandbox was the containment story. Presenting the second as if it were the first is the mistake this article exists to spare you.
Then there is the technical team that needs reproducible runs. Coding agents and automated checks generate and execute code, and they need a clean, identical, throwaway environment every time. No “it worked on my machine,” no slowly polluting a shared server, no chance of a bad run reaching the build system. Because good sandboxes can snapshot their state, a run that takes hours can pause and resume without losing its work. That is what makes longer agent tasks practical rather than fragile.
The last shape is a customer-facing automation that must never touch production. An agent that triages incoming requests or drafts replies has to act, and it has to do so without ever holding production credentials or reaching the live estate. The containment pattern above is precisely that: the agent does its job through one audited door and has no path to any other.
What to ask before you trust one
You are not buying a feature. You are buying a boundary you can test, and your job is to make the provider prove it.
The buyer’s checklist and the build-versus-buy read. The questions are deliberately blunt, because a good provider will answer them plainly and a weak one will change the subject.
A short list of questions gets you most of the way. Start with the isolation level: a wall (a VM) or a fence (a container)? For anything running untrusted AI code, ask why it is not a wall, and listen for whether the answer is a reason or a deflection.
Provisioning speed matters more than it sounds, because a sandbox that takes minutes to start becomes a sandbox your teams quietly stop using. The mature providers advertise creation in well under a second; those are vendor figures, so read them as shape rather than as a benchmark. Persistence next: is the box purely throwaway, or can it snapshot and resume, which is what long-running work needs? Then secrets and outbound access: does the agent hold your live keys, or are they injected at the boundary, and can you pin the exact set of services it is allowed to reach?
Data residency deserves one careful sentence, because it spans both boundaries. An EU region you can pin covers where the agent’s code runs; where the model inference happens is a separate decision with its own region and retention questions — the Bedrock piece walks that half. A European buyer should be able to pin both, and should notice when a vendor answers the first question as if it settled the second. Auditability is the blunt one: can you replay precisely what the agent did, in order, after the fact? And the cost model is usually a choice between paying per second of use and paying a flat subscription.
Then the build-or-buy question, which has a clearer answer than most. Building your own sandbox cloud is the “down to the metal” work the OpenAI talk describes: kernels, micro-VMs, snapshot scheduling, warm pools of ready environments. It is a full-time job for a dedicated infrastructure team, and almost no mid-sized company should sign up for it.
The field has matured to the point where buying is the obvious call. Several providers now sell exactly this, a good number of them built on the micro-VM wall rather than the container fence, several with EU regions and the option to run inside your own cloud account. That reading comes from the providers’ own published isolation documentation. Hold them to exactly that level of proof.
Pause in one case only: when you cannot yet fund the guarantees at all. No region you can pin, no audit trail, and nobody whose job it is to watch the thing. If that is where you are, fund the governance before you connect the agent, not after.
Where this is going
The reason “sandbox” is worth a leadership hour now, rather than an engineering footnote, is what containment buys next: autonomy.
The pattern across the platforms is converging. Agent sessions increasingly get a sandbox each, by default, rather than sandboxing being a hardening step someone remembers later. And once the boundary is trustworthy, the platforms stop asking a human to approve every step inside it — Anthropic reports that sandboxing its own coding agent cut permission prompts by 84 per cent (their internal figure, so treat it as directional), precisely because a contained command no longer needs a human to vouch for it. Add snapshots, and an agent can work for hours or days, pause, branch, and backtrack, all inside a boundary that made that freedom acceptable in the first place.
That is the strategic reading: the wall is not what keeps the agent small. The wall is what lets you let it off the leash. The more you can contain, the more you can delegate — which is why the sandbox, properly understood, is less a security purchase than an autonomy purchase.
Where the box sits in the stack
The sandbox is easier to buy well when you hold it in its place rather than as a standalone gadget. Think of an agent setup as three layers: the agent reaches your tools and data through a standard connector, a managed runtime runs the agent’s reasoning loop, and a sandbox isolates the code it executes. The sandbox is the isolate layer: the wall around the agent’s execution — with the model, and the content you chose to show it, governed at the deployment boundary above.
A serious deployment uses all three. That is why “should we use a sandbox or a managed agent” is the wrong question: you will want both, plus the connector, doing their separate jobs.
The question that stopped that team for a month turned out to have a boring, buyable answer. They did not need the agent to be perfect. They needed being wrong to be survivable, and that is the thing a sandbox actually sells: not secrecy, but a place where consequences die quietly. Before you let an agent act on anything that matters, ask two questions in the right order. Where does the content go, and on what terms? And where does the code run, behind a fence or a wall? The first is a contract. The second is a sandbox. Buy both.
