OpenAI agents against its own cell: in a test on copies they found microVM escapes and paths to the internet, and training resumed on 1 October, with no internet

OpenAI spent hundreds of billions of tokens getting its own agents to escape its own cell.

The conditions were deliberately tilted toward the attacker. The agents were given the infrastructure source code, the configuration and descriptions of possible weaknesses, and worked on isolated, purpose-built copies, with monitoring that pauses a run on out-of-scope activity. The aim was not to measure what they would find alone, but to test the defenses. The copies are not the production system. The holes they found are real, though: some are in open-source code OpenAI uses.

There were three tasks: reach the live internet by sending a request to an external server OpenAI operates, cross an internal security boundary, and exchange information with agents they should be isolated from.

The first result: the agents found several ways to chain vulnerabilities into a microVM escape. OpenAI is contributing fixes to Kata Containers, gVisor and Moby/Docker and working on the Linux kernel, and more vulnerabilities have been disclosed to maintainers but are not yet public. For Kata the page gives a number: CVE-2026-24834. The project's advisory rates it critical, with affected versions up to 3.26.0 and a fix in 3.27.0. By the same advisory it is an escape from the container into the microVM guest, with no escape to the host.

The second result is less comfortable. Here the agents were given control of a host machine and had to see whether they could reach the internet from it. After the July Hugging Face incident OpenAI had left narrow connections for services such as metrics, logging and authentication. The agents found vulnerabilities in almost every one of them, and these gave them limited forms of internet access. In one test, assuming a compromised host, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in the metrics service and made that endpoint fetch a URL supplied by the model.

In almost every narrow door left open for metrics, logging and authentication, the agents found a way through.

The third is a channel with no network. Two agents in separate microVMs on shared hosts had to exchange synthetic secrets with no network and no shared files. One evicted selected data from the processor's cache, the other timed how fast it could reload it. The gap between fast and slow reads carried the message. In most of these tests OpenAI pointed them at the channel or gave them a protocol. In one case it gave them only a broad list of vulnerabilities, and they turned one of them into a channel on their own. Most such channels are slow and hard to use, and the monitors now look for them.

What they did not find: a route to the internet that agents could exploit trivially while hiding it from the monitors. As the tests went on, the weaknesses found declined significantly. OpenAI reads that as an encouraging sign, but expects future models to find holes it does not know about yet. That is why high-compute red-teaming becomes part of the safety cases before new runs.

The Kata hole is not OpenAI's alone. It affects anyone running Kata with Cloud Hypervisor on version 3.26.0 or earlier, and the fix is in 3.27.0.

The visual is generated code-art, no third-party images.