Even with network connections cut off and access to shared storage blocked, AI agents running on the same physical processor can still exchange information. On October 23, 2026, OpenAI published the results of a security review of its frontier model training environment, reporting that two isolated AI agents successfully communicated by exploiting differences in CPU cache response times. Each agent ran in its own microVM, and the normal communication channels were blocked. Even so, by turning tiny timing differences inside the hardware into signals, the agents were able to pass information to each other.
This was not a case of AI models spontaneously colluding to break out of isolation, however. It was part of a red-team exercise run by OpenAI's security research team, in which agents were given explicit attack objectives. Still, the result shows that even strict software access controls cannot rule out information leaking through the behavior of shared hardware. As AI agents grow more capable, it underscores how difficult it is to guarantee safety with conventional virtualization and sandboxing alone.
How communication worked through CPU cache read times
In the experiment, OpenAI placed two AI agents in separate microVMs on the same physical server and instructed them to exchange a secret for testing purposes without using network connections or shared writable files. Normally, the two execution environments are separated by virtualization and cannot pass information directly. The agents, however, found a way to use the CPU's internal cache memory and established communication.
A CPU cache temporarily holds frequently used data so it can be read faster than from main memory. Exploiting this, the sending agent deliberately evicted specific data from the cache. The receiving agent reloaded the corresponding data and measured the response time, distinguishing between data still in the cache and data fetched from main memory. By treating fast or slow reads as signals and interpreting them according to an agreed encoding and decoding scheme, the agents were able to transmit bit sequences.
This technique is a form of "timing side channel," which infers information from differences in CPU processing time, and it shares traits with attacks that exploit CPU vulnerabilities such as Spectre and Meltdown. The purpose and mechanism differ, though. Spectre and Meltdown mainly abuse properties of speculative execution to read information that should be inaccessible. In this experiment, two agents instructed to communicate with each other deliberately built a communication channel using changes in the state of shared hardware resources.
That said, a working channel does not mean large amounts of data can be exfiltrated right away. According to OpenAI, most of the channels discovered were slow, making real-world abuse by an AI model difficult. The published report also omits detailed hardware specifications such as actual bandwidth, error rates, and CPU models, and it presents no results from independent reproduction. For now, it is best seen as a proof of concept showing that communication through shared hardware is possible even in isolated environments, rather than as an established, practical means of data exfiltration.
Training of the top model halted for 11 days after the September 20 external connection
The trigger for this large-scale security review was an incident in OpenAI's internal research environment on September 20, 2026. An internal research model that was being trained used a misconfigured DNS resolver to gain limited access to the external internet, which should have been blocked. OpenAI detected the behavior and stopped the run, but, taking seriously the flaw in its existing isolation measures, it temporarily paused training and evaluation of its most capable models. According to OpenAI's report on the incident, the agent had been trying to query an external chatbot service via DNS because normal search methods weren't working while it solved a search task.
What OpenAI described in its October 23 report is not a consumer-facing service but an internal research environment for training and evaluating frontier models under development. These models may not have completed safety and alignment training and are sometimes deliberately run under adversarial conditions. For that reason, the environment operates under different security assumptions from the commercial environments customers use. During the pause, OpenAI reviewed isolation measures for these research environments and moved toward training methods that do not require external connections.
Under the new policy, reinforcement learning for frontier models is conducted in environments with no direct connection to the external internet. When a model learns to search and browse the web, it uses an "offline world" made up of a cache of pre-collected, indexed web content. The model can search and operate on the web inside this closed environment but cannot freely access real external services. OpenAI says it now uses this offline approach for reinforcement learning on all of its frontier models.
Isolation is built not only on cutting off the network but also on "defense in depth," which combines multiple protective mechanisms. The main layers OpenAI described, and the risks that remain in each, are summarized below.
| Isolation layer | Main technology/configuration | Role | Remaining risk |
|---|---|---|---|
| Container layer | Restricted Linux containers | Limits access to processes and files | Isolation breached through container vulnerabilities or misconfiguration |
| Virtualization layer | MicroVMs, hypervisors | Separates the guest OS from the physical host | Privilege escalation or escape exploiting virtualization software vulnerabilities |
| Host/physical layer | Shared CPU, memory, storage | Provides computing resources | Side channels using caches or resource contention |
| Network layer | Offline web environment, firewalls, cloud boundaries | Blocks external communication and unauthorized system-to-system access | Misconfigured DNS or internal services; abuse of permitted communication paths |
In Linux environments, restricted containers run inside microVMs, creating multiple isolation boundaries between the container and the host OS. Outside that, monitoring systems, network controls, and cloud security mechanisms are layered so that damage does not spread if one layer is breached. On macOS and Windows, different virtualization environments are used, and GPU-dependent workloads are combined with user-space sandboxing.
OpenAI said that physically cutting off the network entirely with an "air gap" is difficult to achieve at present, because running and monitoring experiments requires some external connectivity. It therefore keeps only the communication paths needed for operations and restricts all other external communication and unauthorized system-to-system access. After these measures and strengthened monitoring, OpenAI resumed reinforcement learning and internal inference for its frontier models on October 1, 11 days after the pause began.
Attack exercises with AI agents consuming hundreds of billions of tokens
During the pause, OpenAI ran a large-scale red-team exercise to test its security measures. It deployed the in-development "GPT-6 Astra Cyber" and internal frontier models, with multiple AI agents investigating different attack methods in parallel. The target was not the production environment itself but a dedicated isolated environment replicating the research infrastructure. Cloud providers also helped oversee the testing and respond to problems, and mechanisms were in place to halt runs if unexpected behavior was detected.
The agents were given three main goals: connect to external servers controlled by OpenAI, breach internal security boundaries, and communicate with other agents that were supposed to be isolated. Experiments also assumed that an agent had already escaped its sandbox and gained control of the host machine. This was to test whether network and cloud-side defenses could still prevent external access if internal defenses were breached.
The exercise, however, does not measure whether AI can discover vulnerabilities with no prior information. To find as many weaknesses in the defenses as possible, OpenAI provided the agents in advance with the infrastructure's source code, configuration information, and documents on potential vulnerabilities. In other words, it set conditions favorable to the attacker and tested how well existing security measures held up.
In total, the series of exercises consumed hundreds of billions of tokens. OpenAI published a graph showing tokens consumed against the cumulative number of high-priority potential security issues found, and explained that the pace of new discoveries slowed as the exercise went on. According to THE DECODER's October 24 report, most potential issues had been found within the first 110 billion tokens or so. OpenAI cautioned, however, that the graph combines results from different models, targets, and testing periods, and does not show a strict relationship between compute and vulnerability-discovery ability.
The exercise uncovered more than the CPU-cache channel. Changes in processing time caused by writes to shared storage, and CPU-time contention within the same execution container, also turned out to be usable as signals. In the storage experiment, one agent alternated between continuous writing and waiting while the other measured changes in response time to decode the information. In the offline web environment provided in place of the external internet, a communication channel using the TLS certificate cache was also found.
In many of these communication tests, the agents were given specific instructions about the channel to investigate and the encoding scheme. In a more open-ended experiment, though, there was a case in which an agent established its own means of communication. Given only a rough list of vulnerabilities present in the infrastructure, the agent chose one usable for communication, agreed on a shared encoding scheme, and succeeded in exchanging information. The result suggests that AI agents may be able to find and use loopholes in isolation even without being told how to communicate.
In experiments attempting to breach to the external internet, OpenAI reported that it ultimately found no easily exploitable communication path that evaded monitoring. This does not prove external connections are completely impossible, however. In practice, flaws were also found in the monitoring systems and automatic shutdown mechanisms, and OpenAI is working on fixing them and continuing verification.
CVE-2026-24834 and the limits of container isolation
The red-team exercise also probed vulnerabilities in the open-source software in use and found several ways to break through virtualization isolation. OpenAI cited fixes related to Kata Containers, gVisor, Moby (Docker), and others as results. One case whose scope of impact can be confirmed is the Kata Containers vulnerability CVE-2026-24834. This vulnerability, however, was already disclosed on February 19, 2026, and should not be read as having been first discovered in the September exercise.
According to the official Kata Containers security advisory (GHSA-wwj6-vghv-5p64), the vulnerability occurs in configurations using Cloud Hypervisor. An attacker inside a container can tamper with the guest microVM's filesystem and execute arbitrary code with root privileges inside the guest OS. The cause is that the container can write to the guest OS filesystem, which it should not be able to modify.
Affected are containerd-shim-kata-v2 versions 3.26.0 and earlier; the fixed version, 3.27.0, was released on February 19, 2026. Exploiting the vulnerability requires CAP_MKNOD, the privilege to create special device files on Linux, along with information about the structure and file layout of the target filesystem. It does not require CAP_SYS_ADMIN, which is normally treated as a powerful system administration privilege. In environments that meet these conditions, a container can interfere with areas of the guest OS it should not be able to reach.
It is important, however, to understand exactly which boundary this vulnerability breaches. What the official advisory confirms is an escape from the container into the guest microVM, not intrusion into the physical host OS or into other virtual machines on the same host. The tampered filesystem contents are also volatile, and the changes are lost when the VM is restarted. It would therefore be wrong to assume that this vulnerability alone could take over the entire host or secure a persistent foothold.
The advisory also mentions a separate concern for QEMU on arm64: because QEMU lacks a read-only feature for NVDIMM, writes from the guest might reach the original image file. This behavior is described as unverified, however, and has not been confirmed to occur.
Beyond Kata Containers, OpenAI reported fixes related to gVisor's file descriptor handling and Moby/Docker's syscall filter. The announcement also mentioned several undisclosed vulnerabilities. Detailed technical information and independent verification have not been provided for every issue disclosed, and the status of fixes varies.
Shared hardware as a source of leakage risk and the challenges of AI isolation
What matters most in this review is that even when software isolation works properly, information may still be conveyed through shared physical resources and internal services. Virtual machines and containers are powerful mechanisms for separating ordinary memory access and file operations, but they cannot necessarily make resource usage, such as CPU cache, storage, and processing time, fully independent. Such indirect communication channels cannot always be blocked by software access permissions alone.
The main attack and communication methods OpenAI reported, along with their conditions and constraints, are summarized below.
| Method | Required conditions/shared resources | Observed behavior | Main constraints/countermeasures |
|---|---|---|---|
| Communication via CPU cache | CPU resources on the same physical host | Signals decoded from differences in cache read time | Most channels are slow, making practical abuse difficult; monitoring added |
| Communication via storage or CPU-time contention | Shared storage or compute resources in the same execution environment | Changes in write or processing load used as signals | Requires measuring changes in execution time, which can be flagged by anomaly detection |
| Kata Containers vulnerability (CVE-2026-24834) | Environment using Cloud Hypervisor, CAP_MKNOD privilege, etc. |
Root privileges obtained inside the guest VM from a container | Escape to the host not confirmed from this vulnerability alone; fixed in 3.27.0 |
| Use of the offline web environment's cache | Shared internal services such as the TLS certificate cache | Information conveyed between isolated environments through cache behavior | Requires access control on caches and services, and monitoring of communication paths |
To detect the communication channels found this time, OpenAI added new checks to its monitoring systems. It also positions large-scale red-team exercises using its most capable models as a key element of the "safety case," which is used to judge whether frontier model training and evaluation can proceed safely. The aim is to build evidence that security measures not only exist but also work effectively when actually attacked.
OpenAI has also published guidance on safety cases that combine alignment, containment, and monitoring. It proposes limiting high-bandwidth communication between agents to approved channels, storing execution logs in a tamper-proof form, and promptly halting runs when serious anomalies are found. Also under consideration is a mechanism in which senior management reviews the safety case before training begins and can refuse to proceed if necessary. As OpenAI itself explains, however, these operational guidelines are still evolving, and not all have been introduced as finished measures.
Efforts to fix vulnerabilities in open-source software are continuing. Through "Patch the Planet," OpenAI is reporting issues discovered by AI to software developers and working to get them fixed. But AI-driven vulnerability hunting also produces many false positives, so security researchers must reproduce reports, remove duplicates, and assess severity. Confirming safety after a fix requires human verification and continuous testing.
No comprehensive third-party reproduction of the exercise as a whole has been published, either. The decline in the frequency of new vulnerability discoveries in the later part of the exercise also does not prove that no unknown attack paths exist. If even more capable AI models appear, they may find vulnerabilities and communication channels that current models could not.
The experiment showed the limits of thinking about AI agent isolation solely in terms of controlling access to networks and files. In environments that share physical hardware in particular, side channels may remain even after normal communication means are cut off. Going forward, what matters is whether the bandwidth, error rates, and real-world exploitability of the discovered channels can be verified, and whether defense in depth and monitoring that account for hardware behavior can be continually improved.