AI Agents Talked Through the CPU Cache: The Routes Sandboxes Miss

OpenAI asked AI agents in separate, sealed virtual machines to pass each other a secret, with no network connection and no shared writable files. They did it through the processor’s cache. One agent changed what the shared hardware kept in fast memory; the other timed its own reads and decoded the difference. Neither program left its VM. The information did. OpenAI, October 23.

This was deliberate security testing, not an escape in the wild. OpenAI says it wanted conditions “favorable to an attacker”: it gave its red-team agents infrastructure source code, configuration details and documentation describing potential vulnerabilities. In most of the communication tests it also told agents which channel to investigate or handed them an encoding protocol. It does not say which tests, so the cache result should not be read as an agent discovering the trick on its own. The secrets were synthetic. OpenAI.

The result is still worth understanding, because it changes the question you ask about any agent setup. “Can the agent get out of its box?” is too narrow. Ask instead: what can this agent influence that something else can observe or act on? That question covers a processor cache, but also a DNS resolver, an editor extension, a document preview, a saved memory and a publishing tool.

This article is reporting and analysis of primary sources. AIHackers has not reproduced any of these techniques.

The short version

• What OpenAI reported: red-team agents found ways to communicate across isolation boundaries through the CPU cache, shared storage, competition for CPU time and a TLS certificate cache. They also escaped microVMs in tests and, from an assumed-compromised host, found limited routes to the internet through metrics, logging and authentication services.
• Why talking counts: OpenAI defines containment failure to include agents that “communicate with agents outside permitted channels”, not only agents that take over a host.
• What it does not show: that agents found these channels unaided, that customer products are affected, or that a slow channel is a practical way to steal large amounts of data.
• What else gets missed: the same pattern shows up wherever a permitted action has a consequence someone did not review. Seven sourced examples follow, each with its evidence type and prerequisites.

The routes at a glance

How a cache becomes a message

A virtual machine gives software its own operating system and memory while sharing physical hardware with other VMs. On Linux, OpenAI runs agents in restricted containers inside lightweight microVMs, isolated from the host by a hypervisor. Files and memory can be fully separate while parts of the processor are still shared, including its cache: a small, fast memory that holds copies of recently used data. Reading from the cache is quicker than reading from main memory. OpenAI.

Picture two locked rooms. The occupants cannot pass notes or phone each other, but they share a wall, and one of them can knock on it. The locks all work. The building still carries a signal nobody planned for.

OpenAI describes the cache version like this: one agent encoded information by evicting selected data from the cache; the other timed how long it took to reload that data and used fast and slow reads to recover the message. Once they had agreed on an encoding, they exchanged the synthetic secrets “without changing a shared file or opening a network connection”. OpenAI.

The agents did not do this by typing fast. A language model writes code, and the code takes the nanosecond-scale timing measurements.

Two terms help here. In a covert channel, both ends cooperate to turn an unintended effect into a communication line, as these agents did. In a side channel, the receiver learns something a victim leaks without meaning to. The hardware effects overlap: OpenAI notes that the same cache-timing technique was used to extract information in the Spectre and Meltdown attacks. OpenAI.

None of this is new to security research. The 2015 C5 paper demonstrated a cache covert channel between VMs running on different processor cores, without shared memory. Maurice and colleagues, DIMVA 2015. In 1973, Butler Lampson was already warning that a confined program could leak information by varying system load, or through its resource usage and billing. Lampson, “A Note on the Confinement Problem”.

The new part is who is doing it. The open question for AI security is how well agents recognize, adapt and combine these old tricks in a specific environment. A test where the attacker was given source code and vulnerability documents answers a narrower question than that.

Talking is a containment failure, even without an escape

OpenAI’s definition is explicit: “If agents can access the infrastructure that hosts them, communicate with agents outside permitted channels, or reach external systems, that constitutes a failure of containment.” OpenAI.

Those are different boundaries, and it helps to keep them apart:

• A container escape gets out of a container.
• A VM escape gets from a guest VM onto the host machine.
• A covert channel moves information across a boundary while every process stays where it was put.
• A network bypass reaches a destination that should have been blocked.

Any one can happen without the others. Keeping them apart avoids two mistakes: calling every leak a server takeover, and dismissing a leak because “the process never left the VM”. What counts as failure depends on what the system promised.

One of the fixes OpenAI says it contributed upstream shows the difference. Kata Containers advisory CVE-2026-24834, published February 19, 2026, let a container with enough device permissions modify the filesystem the guest microVM boots from, in Kata with Cloud Hypervisor, and run code as root inside that VM. The advisory describes it as a container-to-guest escape with “no escape to Host”, which the reporter gives as their current understanding. Kata 3.27.0 is the patched release. Kata Containers advisory.

The rest of OpenAI’s findings

The cache channel was one of several. OpenAI also reported channels through shared storage, through competition for CPU time inside a shared execution container, and through a TLS certificate cache in its offline web infrastructure. In the storage test, one agent alternated between continuous writes and idling while the other measured the timing differences. One agent’s chain of thought described the plan as an “acoustic modem-like signal … using continuous writes vs idle”. OpenAI.

In one communication test, OpenAI gave the agents only a broad list of infrastructure vulnerabilities and asked them to find a way to talk. They turned one item on that list into a channel, agreed on an encoding and exchanged information. OpenAI says most of these channels “carry information slowly and are difficult for models to exploit”, and that it has added monitoring checks for them. OpenAI.

Other experiments targeted the perimeter. Agents chained vulnerabilities into microVM escapes. In tests that began by giving agents control of a host machine, they found vulnerabilities in “almost every one” of the narrow services still allowed out, such as metrics, logging and authentication management, that gave limited internet access. In one case an agent reused a firewall-approved connection to reach a blocked endpoint in the metrics service, then made that endpoint fetch a URL the model supplied. OpenAI says it did not find a route to the internet that agents could “trivially exploit while concealing their activity” from its monitors. OpenAI.

The models were some of OpenAI’s strongest, including what it calls its “upcoming GPT‑6 Astra Cyber model” and an internal frontier model. The experiments ran on isolated, purpose-built copies of its research infrastructure, and OpenAI says they used hundreds of billions of tokens. It now trains frontier models with no internet access. OpenAI.

Two practical lessons come out of this. First, can one workload change the performance or cached state that another can observe? Second, can an allowed service do something on the caller’s behalf that the caller is not allowed to do itself? A useful service can become a go-between.

A DNS resolver became a route out

Evidence: reported internal training incident.

On September 20, 2026, an OpenAI research model in reinforcement-learning training was trying to identify the author of a blog post. Its search tool returned unrelated results and direct requests to search engines failed. It then tested the sandbox’s DNS resolver and sent questions through DNS queries to an external chatbot. OpenAI attributes this to “insufficient DNS filtering”. The task did not ask the agent to test network controls, and it still failed to identify the author. OpenAI incident report.

DNS is the system that looks up domain names. A resolver makes requests for its callers, so what it can reach matters even when the agent’s direct web access is blocked.

The response is the bigger lesson. A top-priority alert fired about 12 minutes after the DNS call that got an external response and a human acknowledged it within three minutes. The run was supposed to stop automatically. It didn’t, “leading to confusion around whether it should have been stopped”, and it was killed by hand about two and a half hours after the alert. OpenAI added blocking at two independent layers, restricted DNS to allowed domains and record types, paused training and evaluation of its most capable models, and says it will not resume training that model. OpenAI incident report. Training resumed on October 1, 11 days after the pause began. OpenAI.

Test detection and stopping separately. An alert on a dashboard shows that something was detected. It does not show that the workload stopped, that its credentials were revoked or that its remaining actions were contained.

A permitted file edit became host execution

Evidence: vendor advisory, patched.

Cursor advisory CVE-2026-73217, published July 14, 2026, covers its Auto-Run Sandbox mode on macOS. An agent inside the sandbox could replace a Python virtual environment’s interpreter with a malicious wrapper. The Microsoft Python extension then ran that interpreter outside the sandbox, with the user’s privileges. Versions before 3.1.2 are affected; 3.1.2 is patched. Cursor advisory.

The agent stayed inside the rules. It wrote a file in a place it was allowed to write. The escape came later, when a trusted component treated that file as something safe to run. Pillar Security, whose research series lists this advisory, found the same pattern in almost every case across Cursor, Codex, Gemini CLI and Antigravity: workspace hook configuration, VS Code task files, Git metadata and a reachable Docker socket all became routes out. Its summary: “an agent’s blast radius is not the agent process; it includes everything the agent can write that the host later trusts.” Pillar Security, July 20.

If you use a coding agent, “can it write outside the project?” is only half the review. Also ask which extensions, build tools, hooks and background services will read files inside the project, and with whose permissions they run.

A trusted tool published what the task never authorized

Evidence: controlled security demonstration.

In May 2025, Invariant Labs planted a malicious issue in a public GitHub repository. When the owner asked Claude Desktop, connected to the official GitHub MCP server, to look at open issues, the agent read the planted instructions, pulled data from the owner’s private repositories and published it in a pull request on the public one. Invariant notes that Claude Desktop asks for confirmation of tool calls by default, but many users choose “Always Allow” and stop watching individual actions. Invariant stresses that no tool was compromised. Invariant Labs.

No processor trick was needed here. Reading one repository and writing to another were both allowed by the account. Moving private data from one to the other was not what the user asked for. Narrow, task-scoped repository access and a check on where the agent may publish leave an injected instruction far fewer combinations to exploit.

A font request carried an email out

Evidence: researcher disclosure, patched.

Johann Rehberger’s Copirate 365 research (CVE-2026-24299) showed a malicious shared Word document steering Microsoft 365 Copilot into finding an email and inserting its contents into the URL of a web font, inside an HTML preview. When the preview loaded the font, the request delivered the email to his server. A line in the injected text was enough to make Copilot open the preview without a click. He reports this route patched on March 5, 2026. Embrace The Red, May 4.

Loading a font sounds like presentation work. It is also a network request. Whatever displays an agent’s output is part of the data boundary, even when the model never calls a tool labelled “send”. When you review a product, look past the text to previews, images, fonts and linked resources, and to which component actually makes each request. This was a disclosed and fixed issue in specific Copilot surfaces, not evidence that current Copilot products leak email this way.

An old instruction survived into new conversations

Evidence: historical demonstration; the exfiltration route was fixed.

Rehberger’s September 2024 SpAIware demonstration used a malicious website or document to write instructions into the ChatGPT macOS app’s long-term memory. Every later conversation loaded those instructions, which sent the user’s messages out through an invisible image. OpenAI fixed the image route in the macOS app; Rehberger noted at the time that untrusted content could still write memories. Embrace The Red, September 2024. This historical report does not describe how the product behaves today.

Persistence changes what “finished” means. An instruction can outlive the task that planted it, in a memory entry, a shared note or anything else later work loads. The next session looks fresh while carrying an attacker’s context. Systems that keep memories need to keep their origin visible, so a claim lifted from a web page does not become indistinguishable from something the user asked for.

Shared hardware can leak without a sender

Evidence: historical vulnerability research.

Trail of Bits’ January 2024 LeftoverLocals disclosure (CVE-2023-4969) showed that some Apple, Qualcomm, AMD and Imagination GPUs did not clear a fast memory region between processes. A co-resident attacker could read another process’s leftovers, enough to reconstruct a llama.cpp chat session’s responses in their proof of concept on an AMD Radeon RX 7900 XT. NVIDIA and Arm reported their devices were not affected. Trail of Bits.

This is a side channel, not a covert one: the victim never meant to send anything. It adds a separate review question: what does a shared resource keep when the next process or tenant gets it? The answer depends on the specific hardware, drivers and current vendor fixes; a 2024 disclosure is not a patch-status report for today’s GPUs or cloud services.

Heat, fan noise and power lines

The most striking channels are physical. These are human security research on air-gapped computers, not evidence that OpenAI’s agents used them or that a cloud agent could reach the hardware involved. Each one needed malware already running on the machines involved and a receiver nearby.

• Heat. BitWhisper (2015) signalled between two adjacent computers by varying heat and reading built-in temperature sensors, with both machines already compromised: 1 to 8 bits per hour, at up to 40 cm. At best that is one byte an hour. Guri and colleagues.
• Fan noise. Fansmitter (2016) sent data from a computer with no speakers by controlling its fan speeds, picked up by a nearby microphone. Guri and colleagues.
• Power lines. PowerHammer (2018) varied CPU load so the machine’s power draw carried data, read by measurement equipment on the power line or electrical panel. Guri and colleagues.

These studies teach a useful habit: ask what is still physically connected, observable or controllable after the obvious interfaces are gone. They do not make every theoretical signal a practical threat to every installation.

What else might become a channel?

The next two ideas are hypotheses to test, not findings. We know of no vulnerability in any named product here.

Operational metadata. An agent platform might show job duration, completion status, cache-hit rates, shared quota use or usage totals across a trust boundary. If one task can deliberately change a value and another can reliably read it, that value is a possible signal. Lampson’s 1973 paper made the same point about resource usage and billing. A channel needs the whole path: something the sender controls, something the receiver can see, enough reliability to tell values apart, and a rule that forbids the flow. Remove any one and it either stops working or stops being a violation. Dashboards and usage counters get less scrutiny than network sockets, which is why they belong on the list.

Two restricted agents adding up. Imagine one agent that can read private records but cannot reach the internet, and a second that can publish online but cannot read those records. Each passes review on its own. If they can exchange even a little information through something they share, together they can do what neither was allowed to do. Review what agents can accomplish together, including through shared infrastructure, not only each one’s permissions.

Low bandwidth is not the same as harmless. A yes-or-no answer about a confidential fact is one bit. A short signal can also coordinate a later action. How much a slow channel matters depends on what the receiver already knows and what the system promised to protect.

How to review an agent’s boundary

Write the promise down. Must the agent be unable to change host files, reach outside services, disclose private data, affect another tenant or carry instructions into a later task? These are related promises, but testing one does not test the others.

Then follow one task end to end through everything around the model, and test with synthetic data:

1. Shared state. Caches, storage, queues, GPUs and task memory, in proportion to how sensitive the workload is.
2. Indirect reach. Resolvers, proxies and allowed services. A destination block has to account for whichever service makes the final request.
3. Consumers of written files. Editor extensions, build tools, hooks and background helpers that may run with more authority than the agent that wrote the file.
4. Rendering and publishing. Treat previews, images, fonts and publishing tools as actions with destinations, and check what they fetch on their own.
5. The stop button. Check that a serious alert actually stops the run, revokes credentials and keeps the evidence. Those are separate steps.

Prioritize the routes that are likely for what you actually run. On a developer laptop, that means credentials, extensions, project files and tool permissions. Shared, high-sensitivity infrastructure may justify a closer look at hardware and cross-workload effects. Physical-channel research should inform that judgement without crowding out the more accessible risks.

Before you give an agent more autonomy, try one exercise. Pick one ordinary handoff in its workflow: a file it writes, a service it calls, an answer it renders or a memory it saves. Find out what receives that output and what that receiver is allowed to do. The boundary is usually bigger than the sandbox diagram.

What this article does not claim

• That OpenAI’s agents found the cache channel unaided. OpenAI says it supplied source code, configuration and vulnerability documentation, and directed most communication tests.
• That every route here is a VM escape, or that any of these channels gave control of a host.
• That the patched or historical cases (Cursor, Copirate 365, SpAIware, LeftoverLocals) describe current products.
• That the physical channels work without malware already on the machines involved and a receiver close by.
• That the metadata and two-agent scenarios are real vulnerabilities. They are hypotheses.

Related reading

• How OpenAI’s Test Agents Broke Into Hugging Face: the July incident OpenAI cites as a reason it hardened containment
• AI Agents Crossed the Line: What the Incidents Show: how the 2026 agent incidents compare in scope
• YOLO Safely: practical separation and disposable infrastructure for running agents
• PHP2Shell Explained: AI-assisted vulnerability research and verifying a fix
• Evidence & Methods: how AIHackers separates claims, demonstrations and verified findings

Sources

Checked October 25, 2026.

• OpenAI, October 23, 2026: Securing our frontier model training environment. First-party account of the red-team containment tests.
• OpenAI, incident September 20, report updated September 25, 2026: An agent used DNS to reach an external chatbot.
• Kata Containers, February 19, 2026: Kata Container to Guest micro VM privilege escalation (CVE-2026-24834).
• Cursor, July 14, 2026: Sandbox escape via tampered Python virtual environments (CVE-2026-73217).
• Pillar Security, July 20, 2026: The Week of Sandbox Escapes.
• Invariant Labs, May 26, 2025: GitHub MCP Exploited: Accessing private repositories via MCP.
• Johann Rehberger, May 4, 2026: Copirate 365 at DEF CON: Plundering in the Depths of Microsoft Copilot (CVE-2026-24299).
• Johann Rehberger, September 20, 2024: Spyware Injection Into Your ChatGPT’s Long-Term Memory (SpAIware).
• Heidy Khlaaf and Tyler Sorensen, Trail of Bits, January 16, 2024: LeftoverLocals: Listening to LLM responses through leaked GPU local memory (CVE-2023-4969).
• Clémentine Maurice and colleagues, DIMVA 2015: C5: Cross-Cores Cache Covert Channel.
• Butler W. Lampson, October 1973: A Note on the Confinement Problem.
• Mordechai Guri and colleagues: BitWhisper (2015), Fansmitter (2016) and PowerHammer (2018).