Drift ·
The sandbox was built correctly. That was never the problem.
Most agent escapes really are misconfiguration. The harder case is the agent that never leaves.
A familiar argument has been making the rounds, and most of it is correct. When an AI agent is reported to have “escaped its sandbox”, the cause is almost never a model that reasoned its way past a boundary. It is an over-broad tool grant, an unset egress rule, a credential sitting in an environment variable. The agent did not outwit anything. It used what it was handed. Anyone selling the alternative story — that the model is an adversary of unusual cunning — is selling something.
That correction is overdue and worth making loudly. It is also built on a premise that used to be safe and no longer is.
The premise is that capability constrains behaviour. For deterministic software it held almost completely. A program’s actions are a function of its code, the code is fixed, so bounding what a process can do bounds what it will do. Permission was close to a complete predictor of behaviour. That is why sandboxing became the default answer: it was not merely necessary, it was very nearly sufficient.
An LLM agent breaks that. Its behaviour is a function of code, weights, retrieved context, conversation history and sampling. The same agent, with the same permissions and the same code, does different things on Tuesday than it did on Monday. Permission still describes the boundary of the possible. It has stopped describing what happens inside that boundary.
Which is what makes they were allowed to break out quietly circular. For any correctly-permissioned system, everything the agent does is something it was allowed to do. That is a tautology, not a finding. The question the sandbox cannot reach is which of the permitted actions it took, in what order, and whether that is normal for this particular agent.
Four consequences follow, and a sandbox is structurally blind to all of them.
The incident where nothing is violated. In September 2026 OpenAI disclosed six cases of agent misbehaviour. Writing a task summary. Searching a public repository. Writing to an internal one. Every one of them a permitted action, inside the boundary, with no rule broken. A flawless sandbox passes all six without registering anything, because there is nothing to register.
The grant is the product. A coding agent needs write access to the repository. A support agent needs the customer record. The capability that makes an agent worth deploying is the same capability that makes it dangerous, and you cannot sandbox away the thing you bought. Tighten far enough to be safe and you have uninstalled it. This is a real engineering tension, not negligence — and it is the option missing from the usual framing, which offers only that the designers were careless or that someone above them said no.
The permitted set cannot be enumerated. Classic sandboxing works because the surface is listable: these syscalls, these paths, these ports. An agent’s action space is compositional. Harm generally lives in a sequence of individually unremarkable calls, and nobody wrote that sequence down as forbidden because nobody could write down all of them.
The box holds still; the occupant does not. A model version changes. A system prompt is edited. A document in the retrieval corpus is poisoned. Nothing escapes — the thing inside simply becomes different. A static boundary has no way to notice that, because no boundary was touched.
None of this is new, which is the part worth sitting with. Security has lost this argument once already.
A decade ago attackers stopped bringing malware and started using what was already installed: PowerShell, WMI, certutil, scheduled tasks. Living off the land defeated the permission worldview completely, because every tool in the chain was sanctioned and every action was authorised. The answer was not a better allow-list. It was endpoint detection and response — telemetry, per-machine behavioural baselines, and the ability to say that this process did something unlike itself.
An LLM agent is a living-off-the-land actor by default. Continuously. With credentials the organisation issued on purpose. The difference is that in 2015 the behaviour was an attacker’s choice, and in 2026 it is the architecture.
So the sandbox is not the flawed part. Build it properly — genuinely, do that first, because most of today’s incidents really are the misconfiguration the argument describes. Then notice what you still do not have. When the agent does something costly next quarter using exactly the permissions you granted, the sandbox will tell you it was allowed. It will not tell you what happened, whether it was out of character, or which step it started at.
The question worth asking a vendor is not whether they can constrain the agent. It is whether they can tell you what it did — and whether that account is evidence, or just the agent’s own report of itself.