{"id":665009,"date":"2026-10-25T15:14:16","date_gmt":"2026-10-25T15:14:16","guid":{"rendered":"https:\/\/www.newsbeep.com\/ie\/665009\/"},"modified":"2026-10-25T15:14:16","modified_gmt":"2026-10-25T15:14:16","slug":"openais-isolated-red-team-ai-agents-built-a-hidden-cpu-cache-channel-to-talk-with-no-network-or-shared-files-exploited-cpu-cache-timing-to-bypass-microvm-sandboxes","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/ie\/665009\/","title":{"rendered":"OpenAI’s isolated red-team AI agents built a hidden CPU cache channel to talk with no network or shared files \u2014 exploited CPU cache timing to bypass microVM sandboxes"},"content":{"rendered":"

blog post<\/a>. The containment was intended to stop that kind of secret-swapping, but the agents found multiple ways around it when asked. Security<\/a> researchers already showed that a covert cache channel can move data between cloud virtual machines (VMs); a hijacked agent on a shared cloud server could, in theory, exchange data on the same physical machine, and do so undetected by network monitoring.<\/p>\n

the interesting thing here is that the isolation wasn\u2019t necessarily broken at the software level.the agents were running in separate vms with no permitted network or shared-file channel, but they still shared underlying hardware. and shared hardware means shared microarchitectural state. that\u2019s enough to create a covert communication channel.you can isolate processes, restrict syscalls, block network access, and still have information leaking through timing differences.a pretty remarkable demonstration of why secure agent containment is such a difficult problem.October 24, 2026<\/a><\/p>\n

The agents in question were set up in separate microVMs, on shared hosts, with OpenAI\u2019s sandboxing software, and were asked to swap synthetic secrets without a network connection or shared writable files. One agent evicted select data from the CPU\u2019s cache while another timed the reloading, enabling the two to communicate with fast and slow reads using a protocol they agreed on first. The same cache-timing technique was used to extract data in the Spectre and Meltdown attacks<\/a>; but unlike in those cases, the covert channel here needs two willing parties.<\/p>\n

One X user, tech commentator Ryan Orhan, wrote that the isolation \u201cwasn\u2019t necessarily broken at the software level,\u201d calling it \u201ca pretty remarkable demonstration of why secure agent containment is such a difficult problem.\u201d<\/p>\n

Latest Videos FromTom’s Hardware<\/p>\n

\n

\"Diagram\n<\/p>\n

(Image credit: OpenAI)<\/p>\n

The company\u2019s concern is that models might \u201cfind unauthorized ways to communicate with agents in other sandboxes,\u201d with communication outside permitted channels constituting a failure of containment. A 2017 paper at the NDSS security conference demonstrated a covert cache channel between two Amazon<\/a> EC2 VMs, fast enough to carry an SSH connection, but now agents can build one themselves when asked, including the encoding process. In principle, such a channel could be weaponized, with the sender being code an attacker controls or directs, for example, a prompt-injected agent in a cloud sandbox. The receiver could be a process on the same physical machine, and the data would then leave without any network traffic for monitoring to catch.<\/p>\n

<\/p>\n

The agents turned up three other channels, too: shared storage, where one agent alternated bursts of writes with idle time while the other timed the difference; competition for CPU time in a shared execution container; and a TLS certificate cache in OpenAI\u2019s offline web setup. In most of these tests, OpenAI pointed the agents at the channel or gave them a protocol, and most of the channels are slow and hard for models to exploit.<\/p>\n

You may like<\/p>\n

The red-team testing involved teams of frontier-model agents that worked in parallel and cooperatively toward three objectives: to reach the live internet, to cross an internal security boundary, and to talk across isolation boundaries. Extra tests assumed the inner protections had already failed, with an agent out of its sandbox, past the monitors and in full control of its host machine, to see whether it could still reach the live internet.<\/p>\n

The agents came from some of the company\u2019s most capable models, including the \u201cupcoming GPT-6 Astra<\/a> Cyber model and an internal frontier model,\u201d and were given infrastructure source code, configuration details, and documentation describing potential vulnerabilities, so the defenses were tested under conditions favorable to an attacker. The tests ran on isolated, purpose-built copies of the company\u2019s research infrastructure and used \u201chundreds of billions of tokens\u201d in total.<\/p>\n

Get Tom’s Hardware’s best news and in-depth reviews, straight to your inbox.<\/p>\n

The post comes after several cybersecurity incidents involving OpenAI\u2019s agents, including the July Hugging Face breach<\/a> and a Sept. 20 DNS episode<\/a> that led to an 11-day pause in training. With training resumed Oct. 1, the company continues to disclose vulnerabilities across \u201cseveral microVM projects\u201d and has made red-teaming with its most capable models part of the safety cases that decide whether training and evaluation go ahead. The company believes future models will be able to find vulnerabilities not yet known about.<\/p>\n

<\/p>\n

\n

\"Google\n<\/p>\n

<\/a><\/p>\n

Follow Tom\u2019s Hardware on Google News<\/a>, or add us as a preferred source<\/a>, to get our latest news, analysis, & reviews in your feeds.<\/p>\n