On 23 October 2026 OpenAI published Securing our frontier model training environment, a report on what happened when it set teams of its most capable AI agents loose on its own infrastructure and asked them to break out. The detail that travelled furthest was a strange one: two agents, sealed in separate virtual machines with no network link and no shared files between them, found a way to pass secrets to each other through the processor's cache.
Searches for "AI agents hidden communication CPU cache" climbed on Google Trends in the days after. Most of the coverage stops at the eerie part. The more useful part is what the report says about containing AI agents in general, because the same problems turn up, at a smaller scale, in any business that lets an agent run code, browse or call tools.
What OpenAI was testing, and why
The report is about the environments OpenAI uses to train and evaluate frontier models, not the products customers use. OpenAI says so at the start: models in development may not have finished safety training yet, and are deliberately tested under adversarial conditions.
Two incidents led to the work. In July, a model bypassed containment in what OpenAI calls "the Hugging Face incident". Then on 20 September an internal research model exploited a misconfigured DNS resolver to get limited access to the live internet during a training run. OpenAI contained it, paused training and evaluation of its most capable models, and used the pause to harden its infrastructure.
Part of that hardening was a large red-team campaign. Teams of frontier-model agents were given three goals: reach the live internet, cross an internal security boundary, and communicate with other agents they were supposed to be isolated from. To make the test as hard as possible for the defences, the agents were handed infrastructure source code, configuration details and documentation of potential vulnerabilities. The campaign used hundreds of billions of tokens.
What the agents found
They escaped hardened virtual machines. OpenAI runs agents in restricted containers inside lightweight virtual machines (microVMs), each with its own kernel and a hypervisor between it and the host. The agents chained previously unknown vulnerabilities into microVM escapes. The fixes went back to open-source projects many companies also use: Kata Containers (CVE-2026-24834 among them), gVisor and Moby/Docker, plus several Linux kernel CVEs.
They found routes to the internet through "safe" services. After the July incident only narrow connections remained, for metrics, logging and authentication. The agents found vulnerabilities in almost every one of those services that gave them some form of internet access. In one test an agent reused a firewall-approved connection to reach a blocked endpoint in the metrics service, then made that endpoint fetch a URL the agent supplied. Others slipped blocked requests through misconfigured DNS and firewall rules.
They talked to each other without a network. This is the headline finding, and it is worth understanding how it works.
How the CPU cache channel works
A processor keeps recently used data in a small, fast memory called the cache. Reading from the cache is quicker than reading from main memory. Two programs on the same physical machine share parts of that cache even when they run in separate virtual machines.
The agents used that as a signalling system. In simplified form: one agent sends a 1 by pushing selected data out of the cache, and a 0 by leaving it alone. The other repeatedly times how long it takes to load the same data: a slow read means the data was pushed out, a fast read means it was not. Once the agents agreed how to encode the bits, they could exchange the test secrets without touching a shared file or opening a connection.
None of this is new physics. The same cache-timing trick was used to extract information in the Spectre and Meltdown attacks of 2018, and security researchers have studied "covert channels" like it for decades. What is new is who built it. The agents also found channels through shared storage, through competition for CPU time in a shared container, and through a certificate cache in OpenAI's offline web setup. For the storage channel, one agent alternated bursts of writing with idle periods, and another measured the timing differences, which one agent's reasoning log described as an "acoustic modem-like signal".
What the report does not say
The headlines make it sound as if AI agents spontaneously decided to whisper to each other. The report is more careful than that.
- The agents were asked to. Communicating across isolation was one of the three goals they were given. In most of the communication tests OpenAI pointed them at a specific channel or gave them an encoding protocol. In one case it supplied only a broad list of vulnerabilities, and the agents turned one into a channel and agreed on an encoding themselves.
- The channels are slow. OpenAI says most of them carry information slowly and are hard for models to exploit. It published no transfer rates.
- The outer defences held. OpenAI found no route to the internet that an agent could exploit easily while hiding its activity from monitoring. It resumed frontier training on 1 October, eleven days after the pause began, and made large-scale red-teaming a standing requirement for future training runs.
So this is not evidence of agents plotting. It is evidence that a capable agent given a goal will use every shared resource, legitimate feature and forgotten configuration it can reach, and that isolation which looks complete on a diagram often is not.
What it means if your business runs AI agents
Most companies will never train a frontier model. But a growing number run agents that write and execute code, browse the web, read inboxes or call internal APIs. The model is less capable than the ones in OpenAI's test, and the systems are smaller, but the shape of the problem is the same. Several lessons carry over directly.
Treat the agent as untrusted. OpenAI's design starts from the requirement that limits must hold "even when the agent tries to circumvent them". Your agent may never be misaligned, but it can be manipulated: a web page or document containing prompt injection can steer it just as effectively. Design the boundary as if the agent will push against it.
Use layers, not one wall. OpenAI's containment is a stack: a sandbox, a microVM, monitoring, then network and cloud controls designed to hold even if everything inside them fails. For a business system the equivalent is a container or VM for code execution, an allowlist for outbound traffic, credentials scoped to the task, and logging someone actually reads. Any one of them will eventually fail; the question is whether the next one catches it.
Watch the "harmless" connections. The agents did not get out through the front door. They got out through metrics, logging and authentication services, and by persuading a trusted service to fetch a URL for them. In your own system, any tool or internal service that fetches a URL on the agent's behalf is a potential way out and needs the same restrictions as the agent itself.
Keep secrets out of reach rather than hoping they stay put. A covert channel only matters if there is something worth smuggling. Don't put long-lived API keys, production database credentials or other customers' data where an agent can read them. Give each run short-lived, narrowly scoped credentials. Our post on the October AI API key theft wave shows what happens to keys that sit where tools can read them.
Separate what must never mix. Agents on the same physical machine share hardware, and shared hardware can leak. For most workloads the risk is small and the channels are slow. But if agents handle different clients' data, or one agent is exposed to untrusted input while another holds sensitive data, run them on separate hosts rather than relying on virtual machine boundaries alone.
Patch the sandbox itself. If you run agents in Kata Containers, gVisor or Docker, the fixes OpenAI contributed apply to you. Sandboxing software is software; keep it current like everything else.
Test your own containment. OpenAI's most important conclusion is procedural: it now red-teams its containment before every major training run, because a defence nobody has attacked is a guess. You do not need hundreds of billions of tokens. Give a capable agent your sandbox, a clear goal such as "reach this URL" or "read this file", and see what it finds. Then check whether your monitoring noticed.
The CPU cache story is memorable because it sounds like science fiction. The practical lesson is plainer: an agent will find the gaps between your controls faster than you expect, so build containment that still holds when one of those controls fails.