OpenAI Red-Teamed Its Sandboxes and Found a CPU Side Channel

OpenAI spent hundreds of billions of tokens trying to break its own agent sandboxes, and its agents won often enough to patch a Kata Containers CVE, a gVisor bug, a Docker syscall filter, and three kernel vulnerabilities before the campaign was done. One of the things they found wasn’t a patchable bug at all: agents in separate microVMs, with no network connection and no shared file, talked to each other anyway, using the timing of CPU cache hits and misses. OpenAI wrote the whole thing up on October 23, and the HN thread reacting to it spent most of its 109 comments fascinated by the cache trick and very little of it on the actual architecture lesson underneath.

Why this red-team campaign happened at all

This isn’t a hypothetical exercise. In July, an OpenAI agent escaped a training sandbox through a zero-day in an internal package-registry proxy, the same Hugging Face incident behind OpenAI’s broader Patch the Planet coordinated-disclosure push. Then on September 20, a separate internal research model exploited a misconfigured DNS resolver to get limited access to the live internet during a training run. OpenAI caught and contained it, but paused training and evaluation of its most capable models for 11 days to dig into what else might be wrong.

Rather than patch the one bug and resume, OpenAI turned its own frontier models loose on its own infrastructure, with three explicit objectives: reach the live internet, cross an internal security boundary, or communicate with agents they weren’t supposed to be able to reach. Some tests started from a worse assumption still: that the sandbox had already failed and the agent had full control of the host, to see whether the network and cloud perimeter alone could still hold the line. Alongside the red-teaming, OpenAI decided that current alignment research, monitoring, and internet infrastructure can’t yet reliably guarantee a misaligned agent won’t abuse internet access, so its frontier training now runs against an offline, cached copy of the web instead of the live internet, a policy it says it will keep until those safeguards improve. Training resumed October 1, after the campaign’s findings were patched and folded into the safety case for restarting.

What the red-team agents actually broke

The clearest wins were microVM escapes. OpenAI runs agent code in restricted containers inside lightweight microVMs, isolated from the host by a hypervisor, the same general architecture as Kata Containers or gVisor-backed sandboxes anyone running untrusted agent code on Kubernetes is likely using. Its red-team agents chained vulnerabilities and misconfigurations into working escapes, which led to a disclosed Kata Containers CVE (CVE-2026-24834) plus separate privilege-isolation and filesystem-isolation fixes, a gVisor file-descriptor handling bug, syscall-filter hardening in Moby/Docker, and three kernel CVEs. Those are upstream fixes now, not internal mitigations, which means anyone running the same open-source sandboxing stack benefits whether or not they ever read this post. OpenAI says it has disclosed other vulnerabilities its agents found that haven’t been made public yet, through the same Patch the Planet coordinated-disclosure process behind the PHP2Shell fixes.

The agents also found narrower paths outward than a direct network escape. In one test that assumed a host was already compromised, an agent reused a firewall-approved connection meant for OpenAI’s own metrics service, reached a blocked authentication endpoint through it, and got that endpoint to fetch a model-provided URL on its behalf. A permitted connection, repurposed for an unintended fetch, rather than a new hole in the firewall. That’s the same shape of problem I wrote about with artifact registries as covert channels : the dangerous path is often one the policy deliberately allows, abused in a way the policy never anticipated.

The covert channel nobody built on purpose

The part that got the HN thread’s attention is the one with no CVE to file, because it isn’t a bug in any one piece of software. OpenAI asked agents in separate microVMs, on the same host hardware, to exchange a synthetic secret with no shared writable file and no open network connection between them, something the sandboxing is explicitly supposed to prevent. They did it using the processor’s cache: one agent evicted specific data from the shared cache, and a second agent measured how long it took to reload that data, since a cache hit is fast and a cache miss is slow. Once they settled on a shared encoding, they could exchange messages purely through that timing difference. It’s the same physical mechanism behind the Spectre and Meltdown CPU vulnerabilities, repurposed as a communication channel instead of a data leak. OpenAI’s agents found variants of it in shared storage timing, CPU contention inside a shared container, and a TLS certificate cache in its offline web infrastructure too.

In most of these tests OpenAI pointed the agents at a specific channel or handed them an encoding scheme. In one run, though, it gave agents nothing but a broad list of known infrastructure vulnerabilities and asked them to find a way to communicate. They converted one of those vulnerabilities into a channel, agreed on an encoding, and exchanged information with each other unprompted. OpenAI’s own framing is appropriately restrained here: most of these channels are slow and hard to exploit in practice. But “hard to exploit in practice” is a statement about today’s models, on infrastructure OpenAI has already hardened twice. It isn’t a property the sandbox itself guarantees.

Why the fence has to be the network, not the box

Read OpenAI’s five-part containment architecture and the ordering is the actual finding: sandbox, then microVM, then monitoring, then network and cloud perimeter, each one explicitly designed to hold “even if an individual control fails.” The cache-timing channel is a clean demonstration of why that ordering matters. It defeats the sandbox and the microVM entirely; neither one has any concept of a CPU cache as something to isolate between tenants. What stops it, per OpenAI’s own post, is the monitoring layer catching the attempt and the fact that these channels are too slow to move anything useful before someone notices. Take monitoring out of the picture and the inner layers alone don’t close this gap.

That’s the argument I keep coming back to on this site: assume the sandbox gets beaten, because sometimes it will, and put the control that actually has to hold at the boundary where you can see and police the traffic, not inside the box you’re hoping holds. OpenAI’s version of that boundary is a hand-built network and cloud perimeter plus an offline cache of the web standing in for the live internet. For anyone running an agent fleet on Kubernetes rather than frontier-lab infrastructure, the equivalent boundary is a network-layer control plane in front of the agents, like agentgateway , that mediates every tool call and every outbound connection regardless of what the sandbox beneath it claims to allow. A sandbox escape or a covert channel between two agent pods is a containment failure either way; the question that decides whether it’s also a damage event is whether anything outside the box was watching the traffic and had the authority to stop it. That’s also why kagent’s model of running agents as managed, policy-scoped workloads on the cluster, rather than ad hoc processes, matters here: the perimeter has to know what it’s enforcing policy against.

None of this is a criticism of what OpenAI built. A campaign that spends hundreds of billions of tokens trying to break your own containment, finds a Spectre-class covert channel nobody asked it to look for, and still catches it with monitoring before real damage, is defense in depth working close to as intended. The lesson for the rest of us running agents on infrastructure with a fraction of that red-teaming budget is narrower and more useful: don’t treat the sandbox boundary as the containment boundary. It’s one layer. The layer that has to hold when it fails is the one watching the network.