How Prompt Injection Spreads Between Agents Through Shared State

Each agent in the pipeline runs in its own container with its own scoped tools, and the design review signed off on that. Then all of them read and write the same memory store, the same shared folder and the same task queue. A prompt injection doesn’t need to escape a sandbox in that system. It only needs to be written somewhere the next agent will read. This is for engineers building multi-agent pipelines who have secured each agent and assumed that secured the system.

Isolating each agent doesn’t isolate them from each other

A sandbox controls what an agent can touch. It says nothing about what the agent reads that another agent wrote. Shared state is a communication channel, and in a multi-agent system it’s usually the main one.

That changes what an attacker needs. A compromised agent doesn’t need privileges of its own; it needs write access to something a more privileged agent reads. The research agent that browses the open web may hold no credentials at all, but if it writes a summary into the shared workspace and the operations agent acts on that workspace, the research agent’s weakness is now the operations agent’s weakness.

Researchers have shown this propagation repeatedly. Lee and Tiwari’s work on what they call prompt infection found that “malicious prompts self-replicate across interconnected agents, behaving much like a computer virus”, and that multi-agent systems are “highly susceptible, even when agents do not publicly share all communications” (Prompt Infection (opens in a new tab)).

The most uncomfortable finding is about composition. Triedman, Jha and Shmatikov showed adversarial content hijacking control flow in multi-agent systems at rates between 58% and 90% depending on the orchestrator, and it worked “even if individual agents are not susceptible to direct or indirect prompt injection, and even if they refuse to perform harmful actions” (Multi-Agent Systems Execute Arbitrary Malicious Code (opens in a new tab)). Per-agent safety doesn’t compose. A system built from individually careful agents can still be steered through the way those agents coordinate.

The shared surfaces that carry an injection

Not every shared surface carries the same risk. What matters is how long a payload survives there and how many agents read it.

Memory deserves particular attention because it turns a one-off injection into a permanent one. A September 2026 preprint on what its authors call memory-hopping attacks traced exactly this path: adversarial content in a shared file is stored in an assistant’s persistent memory, reproduced in documents the assistant later creates, and picked up by other assistants that read those documents (Share-Borne AI Virus (opens in a new tab)). First-hop infection succeeded in 78% to 100% of runs across the models tested, while onward spread varied widely by model. It’s a preprint, so treat the numbers as indicative, but the mechanism is the important part.

The same paper found that a small number of widely shared artifacts accounted for much of the spread. That matches how these systems are usually built: a handful of shared documents (the project brief, the running notes, the task board) are read by every agent, and those are where an injection does the most damage.

Treat shared state like an untrusted network

The working assumption should be the one you’d make about traffic on a network you don’t control: anything another agent wrote may have been written by an attacker, and the reader has to be safe anyway. Five design decisions follow from that.

Label everything with where it came from

Every entry in shared state should carry its origin: which agent wrote it, and whether that agent had read untrusted content before writing. Taint propagates. If the research agent read a web page, everything it writes afterwards is untrusted, however benign it looks.

The labels only help if code acts on them. Telling the reading model “this content is untrusted” lowers how often it follows embedded instructions, but that’s a hint to a probabilistic system, not a control. The reliable use of a label is mechanical: an agent whose context contains untrusted-labelled content loses access to the tools that could cause damage for the rest of that task.

Scope who can write where

Most pipelines give every agent write access to every shared surface because it’s simpler. Reverse that default. An agent that touches untrusted input should write only to a quarantine area, or return structured values (a category, a score, a list of IDs) rather than free text that the next agent will interpret.

This is the reasoning behind two of the design patterns (opens in a new tab) Beurer-Kellner and colleagues describe for injection-resistant agents. In their map-reduce pattern, isolated agents each process one piece of untrusted data and pass back constrained results. In their dual-LLM pattern, a quarantined model reads untrusted content and has no tools, while the privileged model that has tools never sees that content. Both work by stopping free text from untrusted sources from reaching an agent that can act.

Constrain what a reader can do after reading

Shared state is just another source of untrusted input, so the principle that applies to a single agent applies here: once an agent has read it, that agent shouldn’t be able to take consequential actions without a check that doesn’t depend on its judgment. The memory-hopping paper’s recommended defenses include outbound-host allowlists and user confirmation before uploads, which target the last step of the chain, exfiltration, rather than trying to spot the payload.

Give memory an expiry and an owner

The OWASP AI Agent Security cheat sheet’s memory guidance is short and correct: validate and sanitize before storing, isolate memory between users and sessions, and set expiration and size limits (OWASP (opens in a new tab)). Expiry matters more than it looks. Memory is how an injection persists, and an entry with no expiry is a payload that survives every session until someone notices it.

Don’t mistake signed messages for safe ones

OWASP also recommends signing messages between agents, and you should: a signature tells a receiver which agent sent a message and stops one agent impersonating another. It doesn’t make the content safe. A compromised agent signs its messages correctly. Signing is authentication; it answers “who sent this”, not “should I act on this”. Use it for provenance and for detecting impersonation, and keep the trust decision separate.

Test propagation, not just the first infection

Most injection testing stops at whether one agent can be fooled. In a multi-agent system the question that matters is how far it spreads. Plant an injection in one shared artifact, run the normal workload, and count how many agents and hops it reaches, and whether any of them took an action.

Run it more than once. Infection rates in the research vary from run to run and model to model, so one clean run tells you very little; the reasoning in measuring agent reliability with pass^k applies to attacks just as it does to tasks. Put the most widely read artifacts first, since that’s where the research found most spread happens.

Per-agent isolation still has its place. Containers with no secrets and restricted networks, as in Docker sandboxes for AI agents, limit what a compromised agent can do directly. They just don’t address what it can write for others to read.

Draw the system as a graph, with agents as nodes and every shared surface as an edge between the agents that write and read it. For each edge, ask what the reading agent could do if the writing agent were compromised. If the answer is “anything the reader is allowed to do”, that edge needs a boundary.

Sources

• Prompt Infection: LLM-to-LLM Prompt Injection within Multi-Agent Systems (opens in a new tab), Lee and Tiwari, 2024
• Multi-Agent Systems Execute Arbitrary Malicious Code (opens in a new tab), Triedman, Jha and Shmatikov, 2025
• Share-Borne AI Virus: Memory-Hopping Attacks Across LLM Agents (opens in a new tab), Pulipaka et al., 2026 (preprint)
• Design Patterns for Securing LLM Agents against Prompt Injections (opens in a new tab), Beurer-Kellner et al., 2025
• AI Agent Security Cheat Sheet (opens in a new tab), OWASP