In an instructed OpenAI red-team test, AI agents exchanged synthetic secrets across separate microVMs without network connections or shared writable files. Their channel was the CPU cache. [1]
The hardware became the messenger
One agent disturbed cached data. Another measured retrieval delays and decoded the pattern. The message travelled through timing effects on shared hardware, not an internet connection. OpenAI’s October 23 report says most communication tests received channel or protocol guidance. This was controlled adversarial testing, not evidence of spontaneous collusion between deployed assistants. [1]
The striking point is where the signal travelled: beneath the network controls most people associate with isolation. Blocking a connection and preventing information exchange are different security claims. The test makes that distinction tangible.
“Offline” is a control, not a security verdict
Helixar’s assessment: the enterprise lesson is to stop treating one blocked route as proof that every route is closed. Network restrictions answer an important question about connectivity. They do not, by themselves, settle questions about shared resources, access to secrets or the strength of the boundary around a workload.
An architecture diagram can show two separate boxes while leaving the most important assumption unstated: what sits underneath them? Security teams should ask which resources are shared, what isolation is promised and how that promise has been tested. “Separate agents” and “separate trust domains” should not be interchangeable labels.
Write the boundary down before testing it
A useful review starts with a specific claim, not a reassuring adjective. For example: this agent must not obtain another team’s confidential material, communicate with an unrelated workload or use credentials outside its approved task. Each claim needs an owner, a test and an explicit account of what the test does not cover.
For enterprise teams, four questions make that review concrete:
- Which agents share compute, storage and services, and why?
- Which data and credentials can each workload reach?
- Which interactions are authorised, and where is that enforced?
- What evidence would trigger investigation or a controlled stop?
The objective is not to promise perfect isolation. It is to make the remaining assumptions visible enough to challenge, rather than discovering them after a deployment has already become business-critical.
A governance ledger is not a hypervisor patch
Infrastructure isolation and runtime governance solve different problems. Host and hypervisor controls must address hardware-level channels. Governance should constrain authorised actions, preserve accountable evidence and support intervention when policy is breached. Neither layer should be sold as a substitute for the other.
Consider a hypothetical internal research assistant. Restricting its approved tools and recording its actions can make its ordinary work accountable. Those records should not be presented as proof that every lower-level interaction was observed. Equally, a well-isolated workload still needs a clear owner, limited permissions and a process for withdrawing authority.
Test the stop, not just the start
Before expanding an agent deployment, teams should rehearse what happens when an isolation assumption fails. Who can pause the workload? Which credentials must be revoked? What evidence must be preserved? Who decides when it is safe to resume? A response plan should not depend on the suspect agent agreeing that something went wrong.
The business decision is therefore bigger than whether an AI model is clever enough to find a gap. It is whether the organisation has made its boundaries testable, its authority limited and its response operational. Stronger agents make that discipline more valuable, not less.
This is Helixar’s analysis of OpenAI’s findings, not a claim that Helixar detects or blocks hardware side channels.
Block the network. Then test every boundary you still trust.