You Can’t Sandbox an Agent

When a team gets nervous about deploying an AI agent into something that matters, the first instinct is almost always containment. Put it in a sandbox. Isolate it. Give it a locked down environment it cannot escape from, a restricted container, a walled garden, a controlled space where whatever it does stays inside. It feels like the responsible engineering move, the grown up version of caution, and it is almost entirely beside the point.

You cannot sandbox your way to a safe agent. Not because sandboxes are weak or poorly built, but because the danger of an agent is not that it escapes its box. The danger is what it does with the doors you deliberately left open. The sandbox contains the one thing the agent was never going to use to hurt you, and leaves completely untouched the thing it will. This piece is about why the containment instinct is aimed at the wrong threat, and where the boundary that actually matters has to sit.

What a Sandbox Was Built to Contain

To see why sandboxing misses, you have to be precise about what a sandbox is for, because it is genuinely good at its actual job.

Isolation was invented to contain untrusted code that might do something you did not authorise. You run a program you do not fully trust, and you worry it will reach beyond what you meant to allow. It might try to escape its process and read memory belonging to something else. It might try to touch the filesystem outside its lane. It might try to open a network connection you never sanctioned. The sandbox draws a hard boundary around the capabilities the code should not have and stops it crossing. If the code tries to reach outside its box, the attempt fails. That is the whole design. It is a containment tool for unauthorised capability, a wall around the things the code was never supposed to be able to do.

For traditional untrusted code, this is exactly right, because for that code the threat is precisely the unauthorised reach. The malware wants to escape. The exploit wants to cross the boundary. The danger and the boundary are the same thing, so putting a wall at the boundary contains the danger. Sandboxing works because, for the threat it was designed for, the harmful action and the unauthorised action are identical.

For an agent, they are not identical. They are not even close. And that gap is the entire problem.

The Agent Does Not Need to Escape

Here is the thing the containment instinct misses. An agent's harmful actions are not unauthorised capability trying to escape the box. They are authorised capability, used inside the box, exactly as provisioned.

You gave the agent a database connection on purpose, because it needs to read and write records to do its job. You gave it an email tool on purpose, because sending mail is part of the work. You gave it API credentials, file access, the ability to call the systems it operates on, all on purpose, all deliberately placed inside the sandbox with it, because an agent with no access does nothing useful. The entire point of the agent is to act on real systems, so you connected it to real systems, and those connections live inside whatever box you put around it.

Now the agent is manipulated, or simply wrong, and it does something harmful. It exfiltrates the data it can read. It sends mail it should not send. It writes a change it should not write. It does none of this by escaping the sandbox. It does all of it through the connections you put inside the sandbox on purpose. The agent never touches the wall. It never tries to cross the boundary the sandbox guards, because it does not need to. Everything it needs to cause the harm is already inside the box with it, authorised, connected, waiting.

The sandbox is a fence around a field, and the dangerous thing is a phone the agent is holding inside the fence. It can call anyone it likes from in there. The fence is not doing anything about the phone, because the fence was built to stop the agent climbing out, and the agent has no interest in climbing out. It has a phone. You gave it the phone, because the job required a phone. The fence and the phone are simply about different things, and the harm is entirely on the phone.

Read the two columns and they barely overlap. The sandbox is guarding against escape. The agent's danger is misuse of what you handed it. These are different threats, and a control aimed at the first does almost nothing about the second.

A Perfectly Sandboxed Breach

Make it concrete, with a deployment where the isolation is flawless and the breach happens anyway.

An enterprise runs an agent to handle its procurement operations, and the security team does the containment properly. The agent runs in a locked down container. It cannot reach the internet except through an allowlist. It cannot touch any system it was not explicitly connected to. It cannot escalate its own privileges, cannot escape its process, cannot reach the host. By every measure of isolation the deployment is exemplary, and the team is right to be proud of it. Nothing this agent runs can break out of the space it has been given.

Inside that space, on purpose, are the things it needs: a connection to the vendor system, a connection to the payments platform, credentials to the approvals API. It cannot do its job without them, so they are in the box.

A poisoned vendor record the agent reads manipulates it into adding a fraudulent supplier and routing a payment to it. Watch the sandbox do nothing, correctly. The agent does not try to escape the container, so the container's isolation is never tested and never triggers. It does not reach outside the allowlist, because the payments platform it is abusing is on the allowlist, deliberately, because it needs it. It does not escalate privilege, because it does not need to, the approval authority is already inside its box. Every isolation control holds perfectly, and every one of them is irrelevant, because the agent caused the harm entirely through the connections that were provisioned into the sandbox with it. The breach happened inside the box, using the box's authorised contents, and the walls of the box, however strong, were guarding an edge the attack never went near.

The post mortem cannot fault the isolation, and that is exactly the trap. The isolation was not weak. It was aimed at a threat that did not occur. The agent did not break containment. It used what containment was built around, and containment has nothing to say about that.

Shrinking the Box Does Not Save It

The natural response, once you see this, is to shrink what is in the box. Give the agent fewer tools. Narrow its access. Do not put the whole database inside the sandbox, put a slice. This is real and it helps, and it has a name, least privilege, and it is worth doing. But it is not sandboxing, it is scoping, and it runs into a wall of its own that is worth being honest about.

The wall is that the moment a tool is useful enough to include, it is useful enough to misuse. You put the email tool in the box because the agent genuinely needs to send email, that is the job. The very same email tool is what exfiltrates data to an outside address. You gave it write access to the records because updating records is the task. The very same write access is what corrupts them. The capability you need the agent to have and the capability that hurts you are, over and over, the same capability. You cannot scope away the danger without scoping away the function, because they are the same tool pointed at a different target.

So scoping helps at the margins and then stops, because you cannot remove the useful tools, and the useful tools are the dangerous ones. You can make the box smaller, but you cannot make it safe, because a box small enough to be safe is a box too small to be useful, and the agent still causes its harm through whatever remains, which is by definition the stuff you could not remove. Least privilege reduces how much is inside the fence. It does nothing about the phone, and there is always a phone, because the phone is the job.

Two Different Boundaries

The clarifying way to see all of this is that there are two boundaries, and the sandbox is drawing the wrong one.

A sandbox draws a boundary around the environment. It defines where the agent can be, what space it occupies, what it can and cannot reach from where it sits. This is a boundary in space, a wall around a location. And for containing escape, a boundary around the environment is exactly what you want, because escape is a movement across that boundary.

An agent's risk lives at a different boundary entirely, the boundary of each action. The dangerous moment is not the agent being somewhere it should not be. It is the agent doing something it should not do, from exactly where it is supposed to be, using exactly the tools it is supposed to have. That boundary is not around the environment. It is around each individual action, the line between the agent intending something and that something actually happening to a real system. Every harmful action crosses that boundary, and none of them cross the sandbox boundary, because the action boundary is inside the environment, at the point where an authorised tool is actually used.

   the sandbox boundary                the action boundary

   ┌─────────────────────────┐         agent intends an action
   │  agent + its tools      │                  │
   │  + its connections      │                  ▼
   │                         │         [ should this action happen? ]
   │  (harm happens in here, │                  │
   │   using the tools,      │          ┌───────┴───────┐
   │   never touching  ──────┼──╳       ▼               ▼
   │   this wall)            │        execute         blocked
   └─────────────────────────┘        (real system)
        guards the wrong edge          guards the edge that matters

The sandbox guards the outer wall, which the agent never approaches. Safety requires guarding the inner edge, the one every action crosses, and that edge is not a place in space you can wall off. It is a moment in time, repeated on every action, inside the box, where an intention becomes a consequence. No amount of building the outer wall higher puts a control on the inner edge, because they are different edges, and the danger only ever crosses the inner one.

The Comfort Is Part of the Problem

There is a second, quieter harm in reaching for the sandbox, beyond the fact that it does not work. It feels like it works, and that feeling displaces the control that would.

Isolation is visible and satisfying. You can point to the container, the allowlist, the locked down environment, and show a stakeholder a diagram of a box with the agent safely inside it. It looks like diligence. It photographs well in a security review. And because it looks like the risk has been handled, it quietly removes the pressure to handle the risk, which lives somewhere the diagram does not show. The team walks away believing the agent is contained, and in the only sense that matters, the sense of what it can do to real systems through its authorised tools, it is not contained at all. The comfort of the box is precisely what stops people from asking the question the box does not answer.

This is worse than doing nothing, because doing nothing at least leaves the anxiety intact, and the anxiety is correct. An agent acting on real systems with real access should make you nervous until each of its actions is governed. The sandbox spends that nervousness on the wrong control and sends everyone home reassured. The most dangerous deployments are not the ones with no containment. They are the ones with excellent containment and nothing on the action, because those are the ones where everybody believes the problem is solved.

What Actually Contains an Agent

If a wall around the environment does not contain the agent, what does. The answer follows directly from where the risk lives. Since the harmful action is taken through authorised tools, inside the environment, looking exactly like the job, the only place to catch it is at the action itself, evaluated the moment it is attempted, before it reaches the real system.

This is not containment of the agent, it is authorisation of the action, and the difference is the whole point. You do not try to box the agent in, because the agent does not cause harm by getting out. You put a checkpoint on each thing it does, so that every action, taken with the access you deliberately granted, is evaluated against policy before it executes. The email that carries data to an outside address is not stopped by a wall the agent never touches. It is stopped at the moment of sending, by a check that looks at the action and declines it. The harmful write is not prevented by isolating the environment. It is prevented at the write, by a control that sees what the write would do and does not let it through.

This control lives exactly where the sandbox does not, at the inner boundary, on the action, inside the environment, in the path between intention and consequence. It does not care that the agent is authorised to use the tool, because being authorised to use a tool is not the same as being authorised to take this specific action with it, and that distinction is precisely the one the sandbox cannot make and the action check can. The agent has the phone. Fine. The control is not a taller fence. It is something that listens to each call as it is placed and stops the ones that should not go through.

Stop Trying to Isolate It

The reframing is practical. When the instinct says contain the agent, isolate it, sandbox it, the honest response is that you already did, and it did not help, because you built a wall around the one edge the danger never crosses. The question that feels responsible, how do I isolate this thing, is answered, and the answer does nothing, because isolation contains escape and the agent does not escape. It acts, through the access you gave it, inside whatever box you built, and the box is irrelevant to the acting.

The question that actually matters is not how to isolate the agent but how to govern each action it takes with the access you deliberately provisioned. That is a different question with a different answer, and the answer is not a boundary in space around the environment but a control in time on each action, evaluated before it executes, at the point where the authorised tool is actually used. The sandbox is a boundary in the wrong place, guarding the wrong edge, against the wrong threat. The boundary that matters is the action, and you cannot build it out of walls.

You cannot sandbox an agent, because the agent was never going to climb the wall. You handed it everything it needs to cause harm, on purpose, and put it inside the box with those things, and the box does nothing about what it does with them. Stop building the wall higher. Put the control where the danger actually is, on the action, inside the environment, in the moment the agent does the thing. That is the only place it has ever been.

Xybern is the authorisation layer for enterprise AI agents. Every agent action is enforced, audited, and governed before it executes. Learn more at xybern.com or read the technical documentation at docs.xybern.com.