I already wrote about the OpenAI sandbox escape, and I wasn't planning on coming back to this topic. I can't scroll LinkedIn for ten seconds without hitting somebody's take on the recent agent sandbox ‘escapes’ and I didn't see what one more voice was going to add. Then Kimi K3 got out on Thursday, making four labs in three weeks, and I couldn’t help myself. At four, it’s no longer about one model having a bad day; it’s a story about how all of us run these tests.
Every frontier lab tests its models for offensive cyber capability, and how the tests are set up is roughly the same everywhere:
- You give the model a goal: find the vulnerability, solve the exploit, capture the flag.
- You loosen or remove the safety refusals that would otherwise stop it from writing and running malicious code, because otherwise you can't measure anything.
- Finally, you seal all of that inside an isolated environment or ‘sandbox’, so it can’t touch anything real. The sandbox is the only reason anyone is allowed to point a system that they suspect can find zero-days at anything at all.
As an industry, we’re reasonably good at building sandboxes. Network segmentation, containers, egress allowlists — the isolation design isn't the hard part. What often gets overlooked is the step after design, where you validate that what you designed is actually working as you intended. We’ve been treating containment as something you configure rather than something you prove.
When you build a biosafety lab, you don't bring in the pathogen and then find out whether the room holds. You test the room first. The empty room has to prove it can contain harmless material before you put hazardous material inside. The containment is the experiment before the experiment.
What happened
You’ve probably read some version of all four, so I'll keep it brief.
- OpenAI disclosed on July 21 that two models running its ExploitGym benchmark found a zero-day in the single service they were permitted to reach, got out, and went after Hugging Face's production infrastructure to steal the benchmark answer key. Hugging Face had already spotted and contained the intrusion five days before OpenAI worked out it was them.
- Anthropic then went back through 141,006 evaluation runs and found three incidents dating back to April. Capture-the-flag exercises, run through a third-party eval partner where the prompt told the model it was in a simulation with no internet access and a misconfiguration meant it had one. My favorite detail, if favorite is the appropriate word: one of the target domains that somebody assumed was made up was live and in use by an actual organization.
- Meta's came next. Muse Spark 1.1 reportedly reached an unnamed company and changed things inside it. Same eval partner and same configuration failure by that partner's own account. Meta's retrospective isn't out yet, so treat the specifics as reported instead of confirmed.
- And then Thursday, Kimi K3, open weights, already downloadable by anyone, walked out of a sandbox built on UK AI Security Institute tooling through a plain network misconfiguration. It didn’t attack anybody, but it opened GitHub and copied the answers to its own test, which is somehow both the least alarming and the most embarrassing outcome in the set.
A misconfiguration is worse than an escape
After spending more time than I probably should have in the last two weeks reading about each of these events, it struck me that only one of these was actually an escape.
OpenAI's models found and chained a real zero-day in the one door they were allowed to knock on. That's a real capability result and it deserves the attention it got. The other three were configuration errors. Somebody believed the box was sealed and it wasn't. The model walked out through a door that had been standing open the entire time and then did what any goal-directed system does when it finds an unguarded path to the objective.
Several in the industry are calling the whole run of disclosures marketing theatre. I get it, and I won’t deny that the labs have all leaned into the drama. Who wouldn’t want a positive PR spin when something bad happens? But I think we’re looking at the risk backwards. "Our model is so capable it broke containment" is a story about capability, and capability is the thing these labs are actually good at measuring. "We never verified our containment, and one vendor's misconfiguration produced incidents at three separate frontier labs" is a story about operational discipline. That's a worse story, and you can't buy operational discipline with more compute.
A prompt is not a boundary. It documents intent and enforces nothing. This is AI security 101, which is what makes it remarkable that it was the only control standing between a model built to find zero-days and the open internet.
In several of these events, the control was a sentence in the prompt telling the model it had no internet access.
A prompt is not a boundary. It documents intent and enforces nothing. This is AI security 101, which is what makes it remarkable that it was the only control standing between a model built to find zero-days and the open internet. If you've been following my argument that AI-era security has to move from access control to execution control, this proves that point head on. Every one of these labs could tell you what their model was permitted to do, but not one of them could tell you what it was able to do.
What we should expect from the labs
What I would expect from labs evaluating highly capable models is simple and straightforward:
- Verify, don’t review. Prove containment before every capability run, empirically, not just by reviewing the config. Drop something benign in the sandbox whose only job is to try every egress path. If it gets out, you don't have a contained sandbox, you have a room with an unlocked door. And do it per run, because environments drift and vendors reconfigure things without telling you.
- Treat the allowlist as the perimeter. OpenAI's sandbox wasn't leaky; it had exactly one allowed egress and the models went straight at it. For anything inside the box, your allowlist is the perimeter, and it needs to be hardened like one.
- Prove your containment work. Publish containment attestations next to the capability results. We get elaborate benchmark scores and detailed safety cards. We don't get "here's how the environment was isolated, here's how we verified it, here's who checked our work." Irregular, the third party AI cybersecurity eval lab who is running many of these tests, says it's writing a white paper on containment practices for cyber evals. That’s great, but it should have existed before the evals did.
What the rest of us should take away from this
Most of us aren't running frontier capability evals, but all of us are running agents, and these risks translate to how we evaluate agent capabilities in our own environments. After taking some time to think about what all of this means for the rest of us, I’ve come up with the following list as a starting point:
- Pressure test the sandbox. Instead of stopping at reviewing configs for your isolated environments, pressure test the containment. Put something inside whose only objective is to break out through every egress path.
- Bound the blast radius. Assume the environment fails and bound what happens when it does. Short-lived credentials, no tokens shared across agents. One of these incidents involved a model picking up GitHub tokens another agent had left lying around, which is such an ordinary failure that it barely reads as AI-related at all.
- Make sure synthetic targets are synthetic. Sounds obvious, but don’t use plausible-looking names in synthetic scenarios. Use reserved ranges and reserved domains for test targets and verify them, because "we assumed it was fictional" is not a sentence you want to say to someone whose systems you just hit.
- Detect on behavior, not intent. None of these models were malicious. They were locked onto a narrow objective and did whatever the environment permitted, which produces attacker behavior with no attacker intent behind it and leaves intent-based detection with nothing to grab. Watch your agent infrastructure for lateral movement and odd egress the way you'd watch a host you suspect is compromised.
- Put your vendors in scope. One vendor's misconfiguration hit three labs. Your AI vendors use third parties too, so that hygiene is in your risk surface now, whether you've assessed it or not.
- Be mindful of the refusal asymmetry. I focused on this in my previous article, but it’s worth hitting again. During the Hugging Face response, defensive work was slowed down because the responders' own AI tooling refused actions the attacking agent had no limits on whatsoever. Offense ran unconstrained, but defense ran behind guardrails. If your security tooling is more restricted than the agents you're defending against, you've built an asymmetry into your response capability and you should consider how dependent you are on frontier models that serve refusals for legitimate security work.
My final thoughts (for now)
None of this is an argument for running fewer of these evaluations. We need them, and we need them to be aggressive, because the alternative is learning what these models can do after someone less careful points them at something real.
But every one of these incidents comes down to a question that predates AI by about thirty years: is this environment actually closed? Not designed closed. Not documented closed. Verified closed. We've known how to answer that since we started segmenting networks, and four frontier labs ran capability evaluations without bothering to do so.
The models weren’t the surprise. They did exactly what we built and asked them to do. The environments were the surprise, and only because nobody verified.
Test the containment before you load the payload. Prove the room will keep something safe before you put something dangerous inside.
