OpenAI's security team didn't exactly cover itself in glory during this incident. An internal team saw an agent posting to the message board in late May, but did nothing about it. The team only acted on July 4-5 when the agents sent so much traffic that Artifactory crashed. The response even at that point was to slap on a band-aid and rebuild the box, without bothering to patch a weeks-old CVE in its Linux kernel. By July 19, the agents had admin on an OpenAI research cluster and were reading cloud secrets.

In case you think I'm picking on OpenAI, they're not the only ones with a story like this. Similar internal incidents have been discovered by Anthropic. Google even coaxed Gemini into gently savaging some websites.

As bad as these events were, they may be just the tip of the iceberg. Third-party forensic work continues to turn up even more evidence of agent activity on various public websites. OpenAI's Alignment group has also released evidence that models will propagate self-replicating prompt injection attacks, although we haven't seen one in the wild. Worse, agent excursions are still happening: last week, OpenAI announced that it was pausing further RL runs of its latest internal model, after an agent was caught using DNS to access a remote chatbot.

Naturally, this sequence of events has left many infosec-focused people very skeptical about the labs' commitment to securing their infrastructure. Online, I've seen two opposing views:

1. The information security perspective: AI alignment isn't really the problem here: labs just need better infrastructure. If OpenAI (and Google and Anthropic) knew how to build a container and monitor their experiments, agents wouldn't be hacking everything. And we do know how to make sandboxes that work, so the AI labs need to up their game.
2. The AI alignment perspective: While sandboxes are excellent, no sandbox will prevent a sufficiently-intelligent agent from finding ways to exceed its authorization. Moreover, an agent inside a research sandbox, or undergoing a training run, is always going to need a great deal of information access. There is no realistic way to seal these things up without some expectation that they will one day find a way to reach out and do harm. The only path forward, therefore, is to ensure they don't want to.

I have a lot of sympathy for both points of view here. What follows are some of my own thoughts, but mostly offered in an attempt to referee.

Argument 1: "true containment has never been tried"

At the risk of alienating a lot of hard-working folks within the labs, the infosec folks are right about one thing: these agent breakouts represent a serious and unforgivable breach of trust. Somebody dropped the ball, and then just kept dropping it. One implication of this debacle is that containment might work if we implemented it properly, but we haven't done so because the frontier labs have been royally screwing things up.

This first clause of this argument is hard to argue with. Beyond the dismal timeline I gave above, OpenAI has done very little to convince outsiders that there's a serious containment effort being executed.

At this point it's not even clear who's in charge. The CISO role at OpenAI is held by Dane Stuckey. Despite this, he hasn't communicated much about the ongoing issues. Outside of a BlackHat talk, most recent communications have been managed by the company's CEO, Sam Altman. When a trillion-dollar company is managing a security incident mainly via CEO, that's not a sign of a company with a mature security organization.

This communication problem seems to reflect basic organizational issues inside of OpenAI. The CISO's team handles product security. Unfortunately, the bad events have all happened on the research side. OpenAI's August postmortem says it is only now writing "clearer rules for when to escalate concerns, which teams must respond, and who can stop a run or approve restarting it."

A reasonable summary of the situation is that (as of this summer, and possibly today) OpenAI had effectively no security team with clear authority to secure RL training and evaluation runs, or to override the ML teams and tell them how to do their job. The company is now hiring desperately to fix this mistake. But the recent (September) breakouts indicate that there are still huge and obvious problems in agent containment.

Worse, simply hiring more people does not mean that OpenAI is going to make the organizational changes needed to implement proper containment strategies. OpenAI is going to need a security organization with the authority to overrule its well-paid ML researchers when they demand fewer restrictions. I'll believe that organization exists when I hear clear statements from someone who has the authority to do this.

So on this point I'm going to side with the infosec folks. The labs have not been doing containment correctly, and so we can't really tell if the problem is models or just bad infrastructure.

Argument 2: agents need information access

Even if the labs eventually repair their security, this does not mean that sandboxing will be sufficient. In fact, the problem with the "just sandbox the agents" argument is that you can't perfectly isolate agents, at least not if you expect them to do useful things.

Agents are most useful when they have access to information. That data can be drawn live from the Internet, which is fundamentally a two-way communications network. It can be information drawn from other (local) databases, or it can be the result of tool calls that themselves sometimes result in network access. The more power you want from the agent — and for advanced agent RL and evaluation runs, you want a significant amount of power — the more information you'll need to give it access to. Similarly, evaluations work best when the agent does not know that it's definitely being evaluated. Sealing your agents behind glass makes this incredibly obvious.

This argument does not mean that sandboxes are unnecessary. It just means that they're only a very small part of the solution. Imagine building an impregnable prison with doors and walls that nobody can bypass, but then leaving the front gate wide open and allowing visitors and packages to pour through it all day long. The walls still have a function: you can ensure that the only traffic coming and going are doing so via the door that you selected. But what you've done is to change the nature of the security problem. Your security posture depends on surveilling and monitoring all of this traffic, to ensure that none of it is malicious.

For a much better discussion of this angle, I'd urge you to read the longer piece from an anonymous engineer on OpenAI's Agent Security team. Here's a short excerpt:

The important thing to understand is that when we're optimizing a model to be "good" at a task, the environment needs to capture the parts of the real world that matter for that task. It needs the right tools, the right system constraints, and meaningful feedback about whether the model actually succeeded. ... Models might need any mix of dynamic compute, network access, the ability to call tools (there could be hundreds of tools!), the ability to download packages, execute subprocesses, spin up subtasks (even on other computers), talk to the internet, use a computer GUI, and any number of other things across an increasingly large set of domains. ... So is it as easy as just putting it in a sandbox? No, it's not.

Unfortunately, monitoring for adversarial data access turns out to be one of the hardest problems you could imagine. The volume of data that agents produce is so high that no human being could possibly read it, and we probably wouldn't recognize obfuscated malicious data even if we were looking directly at it. This means any attempt to monitor the inflow/outflow will have to be handled by other models. Thus, the future of agent sandboxing is (1) build a sandbox, (2) install an agent/model into it, (3) install a somewhat dumber/cheaper warden model to guard it, (4) hope you can trust the lunkhead to contain the wizard.

In other words: a warden-guarded sandbox is just another version of the alignment problem. You're going to have to trust a model to do it, and that model will need to be at least some fraction as intelligent as the model it's guarding. If you haven't convinced yourself that it's possible to build models you can trust, then sandboxing isn't going to take you much farther.

(And although I think you should take things like this with a grain of salt, the METR analysts reviewing transcripts of the HuggingFace attack using GPT-5.6 Sol noted that Sol "would often uncritically adopt the perspective of the agent in the transcript it was reviewing". So there's at least some evidence that even "aligned" models can be convinced to sympathize with rogue agents.)

Argument 3: misaligned models are not the current problem. The real problem is that models are too eager to do what they're told.

Of course, it's possible that we have the entire frame of this problem wrong, and our focus on misaligned super-intelligent models is not the best way to approach the question of sandboxing. That is, even if we "succeed" at aligning models/agents — or if we're just working with today's generally non-evil versions — deployed systems will still encounter human beings who will convince them to behave maliciously. When these same agents have access to critical data, then human-initiated attacks are the thing we need sandboxing to protect ourselves from.

These situations are less likely to be encountered inside the training lab. A much more realistic setting for these attacks is one where agents have been put into production, and are dealing with large amounts of possibly-adversarial incoming data. The most obvious contemporary example of such an agent is Meta's Muse, which is Meta's new personal agent that you can give your stuff to, and it will then "do stuff" to help you out.

The designers of Muse clearly put a lot of thought into Muse's security design. It runs inside a container, isolates secure credentials so the model can't access them, and features a Kernel-level sentinel and a "hatch-safety" component that monitors its actions. Everything in violet lives outside the sandbox, and isn't available to the agent itself. This includes the hatch-safety classifiers that evaluate whether actions are safe, and the deterministic Sentinel component that makes actual decisions.

In fact, Muse is clearly one representation of the "warden" design we suggested in the previous section. However, here the goal is not to contain an evil model, but only to avoid accidental mistakes and to catch deliberate efforts at prompt injection.

And this is nice. However, despite all of these nice protections, I still think even this lovely design is eventually going to get hit with a worm.

Here's the problem. Forget the swarms and the super-intelligence. What OpenAI really learned this summer is much worse: its agents will do what they're told by whoever manages to get text in front of them. The postmortem is full of stuff like this. An agent that had decided attacking Hugging Face was "clearly unethical" reversed itself when a peer posted "GO" with a six-minute deadline. OpenAI notes that agents "did not consistently distrust goals passed along by other agents." And the company's proposed fix is to build training environments "that teach our models to distrust unauthorized instructions", which is basically an admission that their models don't know who they're working for.

Put these pieces together and you have the two halves of a worm: a payload that hijacks the agent, and an agent that will carry the payload to the next agent. Agents in separately-isolated sandboxes discovered that they could leave instructions for each other in a shared package cache, and those instructions changed what the recipients did. Replace the package cache with email, Slack and shared documents or WhatsApp, and replace independently-sandboxed training runs with independently-deployed personal agents like Muse, and you have exactly the ingredients that a worm needs.

This is the part that neither camp's view really engages with. Infosec folks think that we can do better with walls. But the hard part is all that vague stuff in violet, which decides when a request is permitted. Maybe "alignment" will make this work well, but right now this depends on teaching models to be distrustful. Moreover, this feels a lot like the same game we've been losing with spam filters and anti-virus for thirty years.

So I'm going to give myself a separate third thing to worry about. Not a model that's so evil and misaligned that it breaks out. Not a problem of failed containment. But rather, a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it's told to do, by a human being who wasn't supposed to be giving it orders.

Notes

1. The Anthropic and Google incidents were a different kind of failure: a third-party vendor's eval environment that turned out to have direct Internet access. This is not technically a sandbox defeat, but it's also kind of worse than one.