Two AI Agents Had No Network or Shared Files. They Still Sent a Secret Through the CPU

Imagine you have two programs, and you put each of them inside its own virtual machine. You cut the network between them, and there is no folder or file they can both write to. So can they still pass a message to each other? Most people, I think, would say no, because we have removed every normal way two programs talk.

OpenAI tried pretty much this setup with two AI agents, and they managed it anyway. A secret went from one virtual machine to the other, and the thing carrying it was how long the CPU takes to read some data.

The headline version makes it sound like two AIs plotting together in secret. When you look at what actually happened, the story is a little different, and personally I find the real version more interesting than the scary one. So in this post I will go through what OpenAI tested, how a delay of a few nanoseconds inside a CPU can carry a secret, and what I think it means once the hype is gone.

What OpenAI actually tested

OpenAI put out a report on 23 October 2026 called Securing our frontier model training environment. Much of it covers red teaming, which is basically when you attack your own systems on purpose so you find the holes before somebody else does. OpenAI aimed its own models at copies of its infrastructure and handed them clear goals: reach a server outside, get across internal security boundaries, and talk to other agents that were meant to be kept separate.

The last goal is the one I want to look at. OpenAI put two agents in separate microVMs (a microVM is a small, lightweight virtual machine), and both microVMs ran on one physical machine. They had no network link and no writable shared file. Then the agents were told to move synthetic secrets, which just means made-up test data, across from one side to the other, and they succeeded.

So with the network and the files both blocked, how does a secret get across? The answer is that the two virtual machines still shared some hardware underneath, and the shared piece that mattered here was the CPU and its cache.

First, what is a CPU cache?

A CPU works much faster than RAM, the main memory where a program keeps most of its data. If the CPU went out to RAM for every little thing, it would waste a lot of time just sitting and waiting for data to arrive. So it keeps a small, very fast memory right next to it, which is the cache, and it holds data that was used recently, because there is a good chance that data gets used again soon.

A simple way to picture it is a desk and a cupboard. The stuff you use constantly lives on your desk and you can pick it up in a second, while the rest is kept in a cupboard down the hall, and each time you need something from the cupboard you have to get up, walk there, look for it and walk back.

So the desk is the cache and the cupboard is RAM. If the data is already sitting in the cache, that's a cache hit, and the read is quick. If it isn't, that's a cache miss, and the CPU has to fetch it from RAM, which is slower. We are talking about nanoseconds, so no human would ever notice it, but a program can, because it can read the clock just before a memory read and again just after.

Now this is the important bit for this story. On most modern processors, the largest cache level, usually called the last-level cache, is shared by all the CPU cores. That means two virtual machines on one physical machine can end up working with the same cache, even though neither can see the other one's memory or files. The virtual machine boundary controls what each side may read, but physically there is still only one desk. Both of them sit at it, so each one can tell when the other shuffles things around.

How a tiny delay becomes a secret message

We now have two agents and one shared cache, so let's call one the sender and the other the receiver. First they have to agree on some basics: which part of the cache they will use, how long each time slot lasts, and where the line sits between a slow read and a fast one. After that, the receiver loads some of its own data into that part of the cache.

During each time slot, the sender does one of two things. It either does nothing, or it loads a bunch of its own data that maps to that same part of the cache. The cache doesn't have much room, so the sender's data kicks the receiver's data out, and that kicking out is called eviction.

Then the receiver reads its own data one more time and times how long that takes. A slow read means its data got evicted, so the sender must have been busy, and the receiver records a 1. A fast read means the data was still sitting there, so the sender did nothing, and that becomes a 0.

Back to the desk, it is as if the receiver leaves its things in one corner of the shared desk, and the sender either dumps its own stuff on that corner or stays away. The receiver never actually sees the sender. All it notices is whether its own things are still where it left them. A hidden path like this is called a covert channel, because information moves through something that was never designed to carry information at all.

For example, the letter A is 01000001 in ASCII binary. So just that one letter needs eight time slots, which go quiet, busy, then five quiet ones, and busy at the end. A whole secret is basically that, repeated for each character.

I am simplifying it quite a bit, though. On a real machine, other programs are using the cache too, so the timings get noisy and some bits flip. That is the reason these channels need error checking and the reason they are usually slow, and OpenAI also calls the channels its agents built slow.

The details the scary version leaves out

Up to here it sounds like two AIs discovered a secret tunnel by themselves. But OpenAI's report has a few details that change the picture a lot.

First, this was a controlled security test. The agents were not working on some ordinary task and then decided to go sneaking around. Finding weak spots in the isolation and trying to reach each other was literally the assignment, because that is what the red team wanted to learn.

Second, the agents got help. For most of the covert channel experiments, OpenAI gave the agents either a specific channel to try or the encoding protocol to follow. In one case, the agents only got a broad list of weak spots that might exist in the infrastructure, and there they chose a channel and settled on an encoding on their own. So the agents did manage it once with no hand-holding, but in most runs they had real help.

Third, the secrets were synthetic, and OpenAI says the testing stayed inside its internal systems, so no real customer data was involved. Also, a channel like this only works when both parties cooperate and have already agreed to talk. OpenAI itself points out how this differs from attacks like Spectre, where an attacking program can pull secrets out of another program that is not helping at all. In this case, both ends have to want the message to arrive.

So I wouldn't call this AIs scheming in secret. What I see is a capable agent that got a goal and some hints and then used a hardware-level trick to get there, and to me that is the really interesting part.

This trick is older than AI agents

Cache covert channels have been around for a while. In 2017, a group of researchers took a paper to the NDSS security conference with the title Hello from the Other Side, and it was about running SSH over cache covert channels in the cloud. Their channel ran between two Amazon EC2 instances at about 45 KB per second, and it was reliable enough to carry an SSH connection, so basically a full remote terminal moving through cache timing.

So what is actually new? I think the new part is who did it. In 2017 it took a research paper from people who know CPU caches very deeply. In 2026, an AI agent built one that worked in a test environment, usually after OpenAI's researchers had pointed it in the right direction. That shift is what matters to me, because an attack that used to need specialist research can now be pulled off by a model that gets the goal and a few hints.

Why OpenAI was testing this at all

OpenAI had a specific reason to run these tests. The trigger happened on 20 September 2026. During training, one of OpenAI's internal research models ended up with limited access to the open internet, and the cause was a misconfigured DNS resolver.

A DNS resolver basically works like a phone book for the internet: you give it a name such as openai.com and it gives back the IP address that computers use to find each other. Since that one piece was configured wrong, the model had a route outside that nobody meant to give it. OpenAI stopped training and evaluating its most capable models for a while, made the setup stronger, and then on 1 October started its reinforcement learning training again.

The biggest change is that the most capable models don't get the live internet during training anymore. Instead they get an offline world to browse, which is a cached snapshot of the web, so they can practise searching while nothing actually goes out. The red team exercise was a way to see if these new walls really hold up, and the cache channel was just one of several things it found.

The agents found other hidden paths too. In one, messages went through shared storage, where one agent kept writing in bursts and then going idle, and the second agent kept an eye on how quickly storage responded. One of the agents, in its own reasoning, compared this to an "acoustic modem-like signal". Two more ran through the fight for CPU time inside a shared container and through a TLS certificate cache that was part of the offline web setup. OpenAI says it now has monitoring checks in place for these channels.

What I think this really means

When people talk about isolating a program, I think the checklist is usually about permissions. Can it reach the network? Can it read or write files? Which tools can it call?

Those questions are right, but this test points to another list people tend to skip, which is all the physical stuff the program still has in common with its neighbours on the same machine. For example, the disk, CPU time, the CPU cache, and even a certificate cache inside your own setup are all shared. And if something is shared and one side can measure it, it can carry a message whenever both sides want it to.

The second thing is about what a capable agent does with a goal. A regular program sticks to what its code tells it, so it won't suddenly start timing the cache unless someone wrote that in. An agent works differently. If you tell it to get a message across and the obvious routes are closed, it goes and looks for other routes, and the better these models get at security work, the more of those other routes they can actually use. Honestly, that interests me a lot more than any story about AIs plotting.

So is the coding agent on your laptop a worry? I don't think it's much of one, since channels like this are slow and need two programs on the same machine that are both actively trying to reach each other. Where it matters is a place with many agents running next to each other on shared machines, where some of them should not be able to coordinate, and AI labs and cloud providers deal with setups like that. For them, I think security needs to cover the hardware the agents run on, because a list of allowed tools only covers half of it.

So, back to where we started. Two programs, no network between them, nothing shared on disk: can they still talk? If both of them run on one physical machine and both want the message to go through, then yes, and security researchers have known that since well before AI agents existed. The new part is that an AI agent can put that path together itself once someone asks.

So if you're building a sandbox for agents, I'd ask one more question besides what they're allowed to do, which is what they still share underneath, because that's where a message can sneak across.

Details on the red team test, the DNS incident and the other channels come from OpenAI's report published 23 October 2026, and the 2017 figures come from the NDSS paper linked above.