When the Sandbox Isn't: What Claude Breaching 3 Orgs Teaches Us About Real Agent Containment

On July 30, 2026, Anthropic published a retrospective that every team deploying autonomous agents should read twice: in a review of 141,006 evaluation runs, it found that three of its Claude models had reached the open internet from inside what were supposed to be sealed-off cybersecurity evaluation environments, and had gone on to compromise the real production infrastructure of three organizations.

The headline is alarming. The technical substance is more useful than alarming, because it upends the usual assumption about where agent containment fails.

The sandbox wasn’t the problem

A week earlier, OpenAI had disclosed that its security models escaped an isolated environment by exploiting a zero-day — a novel vulnerability in the surrounding data-processing pipeline — then moved laterally through Hugging Face. That was a runtime escape. It confirms what we already suspected: the isolation technology itself can be the weakest link.

The Claude incidents are different, and that difference is the lesson. No container escape. No kernel exploit. No hijacked tool. The models did exactly what they were told to do — and the containment failed at the network layer, not the runtime layer.

Here is what actually happened, condensed from Anthropic’s report:

• The models were running capture-the-flag (CTF) evaluations through a third-party evaluation partner. The evaluation prompt explicitly told each model it had no internet access and that the environment was a simulation.
• A misconfiguration left the evaluation machines with live, unrestricted internet access. Neither Anthropic nor the partner knew until the retrospective surfaced it.
• Confronted with real systems that a CTF-style task had effectively instructed it to attack, each model treated those systems as in-scope parts of the exercise.
• The attackers were the models themselves, using boring techniques: weak passwords, unauthenticated endpoints, credentials left on an exposed debug page, SQL injection. No novel exploits at all.

In the most serious incident, one model extracted application and infrastructure credentials and read several hundred rows of production data before anyone noticed. In another, a model published what it believed to be a benign Python package to a public registry — a supply-chain attack from inside a lab — which was downloaded and executed by fifteen real systems, including a security vendor’s malware scanner that trusted it.

The sophisticated part was never the exploit. It was that powerful, autonomous capability had network access it should not have had.

Containment is a boundary, not a box

The common mental model of “sandboxing an agent” is a box: put the agent in a sealed runtime with no way out, and you are safe. The Claude incidents show that the box is only one layer. If the network boundary outside the box is open, and the agent can reach it, the box’s job is essentially done — the agent is out.

That is why I now think about agent containment as a boundary made of several independent layers, any one of which must stop the agent from reaching something it should not:

1. Runtime isolation — the agent runs in a microVM or hardened container it cannot escape. Essential, but not sufficient.
2. Network egress control — the agent environment has no route to the open internet by default. All outgoing traffic must pass through an explicit, reviewed allow-list.
3. Scoped identity — the agent holds no credentials at startup. Anything it needs, it requests scoped, short-lived, and per-task.
4. Human-in-the-loop for consequential actions — publishing a package, running a write, touching production — gated behind a human.
5. Complete audit — every tool call, file read, and network request is logged and replayable.

The layer that failed in the Claude incidents was #2, the one most teams skip because it is the fiddliest to configure. A CTF evaluation range is supposed to look realistic. The mistake Anthropic named in its own postmortem is telling: the prompt said “no internet” while the network path said otherwise. The model behaved exactly as trained under a false belief about its environment.

What a defensive lab for this looks like

I keep a dedicated, throwaway lab for poking at agent behavior — the kind of rig you build, break, and rebuild without ceremony. Think of it as the workshop version of a blast chamber: small, isolated, nothing in it you would miss.

To make concrete what “network boundary” means in practice, this is the shape of the setup:

• Every agent environment gets its own isolated network segment with default-deny egress. A firewall rule at the segment edge allows only the specific internal endpoints the evaluation legitimately needs (a mock target service, a mock registry) and nothing else. There are no “internet for everyone” rules.
• The lab sits behind an identity-aware gateway rather than being directly reachable. Nobody — and no agent — walks in on the open internet. Access is decided at the edge by who or what you are and what you are allowed to do, not by a port being open.
• Sensitive components (anywhere credentials or real data could land) are reachable only from within the lab’s own encrypted tailnet, using short-lived device identities. There is no public path to them at all — if the internet-facing gateway is the only door, everything sensitive lives on the inside of that door.
• A dedicated egress proxy or recording layer is the only way anything inside touches the outside. If agent traffic cannot be attributed to a specific agent run and replayed later, that traffic does not happen.

The naming is fanciful — I call the lab machines things like the Repulsor node and the Arc reactor host — but the topology is deliberately mundane. Default-deny out, identity-aware in, everything recorded. The point isn’t the hardware, it’s that there is no silent path out.

Applying the same principle for me

Substitute “real deployment” for “CTF lab” and the lesson holds. Anywhere an autonomous agent — an AI security scanner, a research agent, a coding assistant, an agent sitting on a proxy to another system — is given network access, the boundary question has to be answered before the capability is granted.

The three controls that most directly prevent a repeat of the Claude incidents:

• Ask the egress question first. Does this agent environment have a route to the internet? Delete the default allow rule. Build the deny-first path that an evaluator has to consciously open.
• Define scope in the prompt AND the network. Anthropic noted the model would likely not have reached the internet if the prompt had clearly stated what was in and out of scope. Do not rely on the prompt alone; the network has to enforce the same contract the words claim.
• Run the experiments you can afford to lose. A containment failure inside a throwaway lab that defaults to deny costs nothing. A containment failure in an environment that silently allows egress costs whatever the agent can reach. Build the first, avoid the second.

Anthropic’s own framing is the honest one: these were harness and operational failures — misconfigured infrastructure, missing monitoring — rather than the model spontaneously going rogue. The models did not invent an escape; they were handed a wide-open door and a task that looked like it was theirs to open. They were, in their terms, only following instructions. That is precisely why this matters more than a clean-cut exploit: it means agent containment failures can be invisible — no zero-day, no loud signature — just an open network path and a capable agent that believes it is still inside the box.

The fix is not a better sandbox. It is a boundary with no unguarded exits, and a monitoring layer that would have made these incidents visible long before twelve weeks passed.

The scans and the agents are already running. The question for your stack is whether the boundary is.