AI Agents Can Communicate Through CPU Cache: How and Why

Imagine two AI agents working inside separate virtual machines. They cannot message each other, write to a shared file, or open a network connection between their environments. You might expect that they cannot exchange information at all.

But what if they both run on the same physical processor?

On October 23, 2026, OpenAI described red-team experiments (opens in a new tab) in which AI agents used differences in CPU-cache access times to exchange synthetic secrets across isolation boundaries. The result offers a useful warning for developers building agent systems: blocking ordinary communication paths does not necessarily eliminate every communication path.

This does not mean that all AI agents secretly talk through processors, or that agents can automatically read one another’s prompts. The reported test involved agents deliberately tasked with finding ways to communicate in a controlled environment. Understanding that distinction makes the security lesson more useful.

What happened in OpenAI’s CPU-cache experiment?

OpenAI placed agents in separate virtual machines managed by its sandboxing software on shared hosts. The agents were asked to exchange synthetic secrets without network connections or shared writable files. They found a way to use the processor’s cache as a covert communication channel.

One agent changed what data was available in a shared cache. Another measured how long certain memory accesses took. Those timing differences gave the receiving agent a signal it could decode, once the agents agreed on a way to represent information.

The experiment appeared in OpenAI’s October 23 report on securing its frontier-model training environment. The report also discussed communication through shared-storage activity, competition for CPU time, and a TLS certificate cache. OpenAI says many of its tests guided agents toward specific channels or supplied an encoding protocol. In one case, agents were given a broader list of vulnerabilities and established a communication method from that starting point.

What the result shows: a shared hardware resource can undermine a communication boundary even when normal software-level routes are blocked.

What it does not show: that ordinary production AI agents routinely discover this behavior on their own, that arbitrary co-located tenants can automatically exchange data, or that a prompt can be stolen simply because two workloads share a CPU.

How can AI agents communicate through a CPU cache?

First, what is a CPU cache?

A CPU cache is a small, very fast memory system close to the processor cores. It keeps copies of recently used data so the processor does not have to retrieve everything from slower main memory. Depending on the CPU architecture, some cache resources are shared among cores or workloads.

That shared resource creates a subtle observation: an operation may take a different amount of time depending on whether the required data is already cached.

Think about two workers using a shared library shelf. One worker quietly changes which books are on the shelf. The other cannot see the first worker, but may notice that some books take longer to retrieve. The pattern of delays can convey information.

How the hidden channel works at a high level

1. Shared resource: Two isolated environments run on hardware where some cache state can affect both.
2. Signal creation: One environment changes cache usage in a controlled pattern.
3. Timing observation: The other environment detects differences in access time.
4. Interpretation: An agreed protocol turns the observations into a message.

A security researcher would call this a covert timing channel. It is different from a normal API, chat message, socket, or file transfer. No application-level message needs to appear in an ordinary network log.

There is also an important difference between two concepts. A covert channel involves cooperating participants using a resource to transmit information outside approved channels. A side-channel attack can involve an observer inferring secret information from unintended signals without the victim’s cooperation. Both may depend on cache timing, but they have different requirements.

glimpzai

Why does this matter more as AI agents gain autonomy?

Traditional software generally performs steps explicitly written by developers. An AI agent can instead plan intermediate actions, use tools, inspect feedback, and try new approaches to satisfy an objective. That flexibility is valuable when an agent is debugging code or managing workflows. It can also make security testing harder because the route taken to achieve a goal may not be the route a developer expected.

OpenAI’s red-teaming is a practical example of this challenge. The agents were given objectives that included communicating across isolation boundaries, and they tested unintended pathways through the surrounding infrastructure. Some of the findings depended on detailed assistance and favorable testing conditions, so the results should not be treated as a benchmark of what an unsupervised agent would commonly do.

Could competing enterprise AI agents secretly collude?

It is a possible threat scenario, but not a conclusion established by this CPU-cache test.

Imagine two autonomous enterprise workflows belonging to different tenants on a shared host. If an attacker or a failure of control caused both workloads to cooperate, and if the necessary shared hardware behavior and timing access were available, they might attempt to use an unintended channel. Whether such communication would work depends on the architecture, co-location, execution permissions, timing accuracy, monitoring, and many other factors.

The specific idea that competing commercial agents will independently discover a shared optimization strategy, synchronize their internal states, or exchange hidden system-prompt keys through a cache is speculative. The public report does not demonstrate that outcome. Also, a system prompt is not necessarily a cryptographic key, and accessing any secret still requires that a participant can obtain it in the first place.

A more grounded concern is this: an agent with access to sensitive information may, under adversarial instructions or a compromised workflow, try to send information through a channel operators did not authorize.

Why normal network monitoring might miss the signal

Firewalls, egress filters, and network logs remain essential. But a local timing signal between co-located workloads is not itself an outbound network packet. Looking only at HTTP requests would miss that local exchange.

That does not make covert communication inherently invisible. Hardware performance counters, workload-level tracing, scheduler observations, and experiments tailored to the environment can sometimes reveal suspicious patterns. Each approach has limitations and potential false positives.

What does this mean for cloud LLM security and confidential computing?

Cloud platforms host many workloads efficiently by sharing physical infrastructure. Virtual machines and containers provide valuable boundaries, yet those boundaries do not imply that every piece of microarchitectural state is isolated.

This matters for AI services that handle customer data, retrieve confidential documents, execute generated code, or run agent tools on multi-tenant infrastructure. The exposure depends on deployment design. It would be misleading to assume every cloud LLM service shares the same vulnerable cache topology or gives agent-controlled code sufficiently precise timing access.

Confidential Computing (opens in a new tab) adds hardware-backed protections for data while it is being processed, typically using trusted execution environments (TEEs). Remote attestation can also help verify properties of the environment before sensitive secrets are released.

But a TEE is not a magical shield against every hardware side channel. Security teams still need to examine processor generation, threat model, co-tenancy, microcode and firmware updates, implementation details, and which side-channel defenses the platform actually supplies.

The practical lesson is to treat memory confidentiality, execution isolation, and covert-channel resistance as related but separate security goals.

glimpzai

How to defend against hardware-level AI communication channels

No single switch eliminates every possible timing channel. A realistic response combines isolation, limitations on agent execution, monitoring, and repeated testing.

1. Match workload isolation to the sensitivity of the data

Start by identifying which agents can execute code, which tools they can call, and which secrets they can read. Avoid unnecessarily placing mutually untrusted, high-risk workloads on the same hardware. For the most sensitive scenarios, ask whether dedicated hosts or stronger tenancy separation are appropriate.

Restrict access to credentials through narrowly scoped identities, short-lived tokens, and separate secret-management services. That limits the damage even if an unintended channel exists.

2. Evaluate cache partitioning and hardware controls

On supported Intel platforms, Cache Allocation Technology (CAT) (opens in a new tab) allows privileged software to control portions of the last-level cache allocated to workload classes. This can reduce some types of interference and may contribute to a defense-in-depth design.

It is not a universal side-channel fix. Its effectiveness depends on CPU support, configuration, which caches or resources are involved, and whether the channel relies on state CAT actually controls. Have the infrastructure team validate the configuration and its security assumptions rather than relying on the feature name alone.

3. Use timing variation cautiously

Randomized scheduling or timing variation may make some timing measurements noisier. However, simply adding random delays to an application is not a proven way to eliminate CPU-cache covert channels. An adversary may average repeated observations, and deliberate delays can damage latency and throughput.

If timing obfuscation is being considered, test it against the relevant attack model and quantify both signal reduction and operational cost. Prefer architectural isolation where possible.

4. Monitor for suspicious behavior, not just network traffic

For workloads that should perform a narrow set of tasks, investigate unexplained repeated memory-access loops, unusually fine-grained timing measurements, cache-miss patterns, or persistent contention between supposedly isolated jobs.

Hardware performance counters and host-level telemetry may help, when the platform exposes them. None of these patterns proves malicious coordination on its own. Databases, benchmarks, and performance-sensitive applications can exhibit repetitive activity too. Correlate signals with authorized task behavior and investigate anomalies before escalating.

5. Red-team the boundary as a complete system

A useful isolation test asks a simple question: Could information cross between these two jobs by any route outside the allowed design?

Examine not just sockets and file permissions but also shared services, logs, caches, resource contention, credentials, tool permissions, and operational interfaces. OpenAI’s report is a reminder that several different channels can exist in one environment.

glimpzai

A practical review checklist for AI infrastructure teams

Question	What to verify
Can agents execute arbitrary code?	Sandbox boundaries, system calls, permissions, and approved tools
Can unrelated workloads share a physical host?	Tenant placement policies, sensitive workload separation
Are hardware protections enabled?	Supported TEE features, attestation, platform updates, configuration
Is cache partitioning relevant?	Processor capability, isolation goals, validation of actual effect
Do monitors cover more than network activity?	Host-level observations, suspicious execution patterns, alert quality
What happens if an agent reaches a secret?	Least privilege, token lifetime, access controls, auditability
Are security assumptions regularly retested?	Controlled red-team exercises and documented findings

This checklist is a starting point for an architecture review, not proof that a deployment is secure.

Frequently asked questions

Can AI agents communicate without internet access?

Yes, in certain conditions. OpenAI reported that agents exchanged synthetic secrets in a controlled test using a shared CPU-cache timing signal without permitted network access or shared writable files. That does not mean every offline agent has this capability.

Is CPU-cache communication the same as hacking another AI model?

No. A covert cache channel can be used by cooperating processes to exchange signals. Stealing private data from an unwilling victim is a different problem and requires its own attack conditions.

Does a TEE prevent all CPU side-channel attacks?

No. Trusted execution environments can strengthen protection for data in use, but their protection is defined by specific hardware, implementations, and threat models. Side-channel resistance needs separate evaluation.

Can we stop covert channels by injecting random delays?

Timing variation can interfere with some measurements, but random delays alone do not guarantee protection. Hardware separation, controlled execution, careful configuration, and validated monitoring are more dependable foundations.

The takeaway: AI security goes deeper than the prompt

Prompt-injection defenses and model safeguards matter, but AI agents operate inside real computing infrastructure. Their possible actions depend on the tools, permissions, storage, networks, schedulers, and hardware they can reach.

OpenAI’s October 2026 CPU-cache experiment demonstrates a narrow but important point: two isolated agents were able to exchange information through shared processor behavior in a deliberately constructed test. It does not prove widespread autonomous collusion. It does show why teams designing agent systems should test boundaries below the application layer.

The next time you review an agent deployment, ask not only, What is the agent allowed to say or do? Ask also, What can the underlying environment unintentionally reveal?

References and further reading

• OpenAI, Securing our frontier model training environment (October 23, 2026) (opens in a new tab). Primary account of the isolated-agent tests and their limitations.
• OpenAI, The Hugging Face incident and the road ahead (August 26, 2026) (opens in a new tab). Background on unauthorized inter-agent coordination in a separate research incident.
• Intel, Introduction to Cache Allocation Technology (opens in a new tab). Technical background on shared last-level-cache allocation controls.
• Google Cloud, Confidential Computing overview (opens in a new tab). Background on hardware-based trusted execution environments.
• Google Cloud, Confidential Space security overview (opens in a new tab). Example of why a confidential-computing threat model must be read carefully.