Multi-Agent Prompt Injection: Spread and Tests

How does an injection spread from one agent to another?

It spreads because an agent message is just text: the receiving model has no way to know it carries an instruction of external origin. A web page read by a research agent becomes a summary, the summary becomes the orchestrator's input, and the orchestrator turns it into an order for an agent that holds write tools.

Researchers Lee and Tiwari described a variant in October 2024 that they call "Prompt Infection": a malicious prompt that replicates from agent to agent, like a virus, and can lead to data theft, fraud or system-wide disruption. Their experiments suggest multi-agent systems are highly exposed, even when agents do not share all of their exchanges.

Three mechanisms keep showing up in tests:

• Delegated trust: the orchestrator executes what the sub-agent "found" without reclassifying it as untrusted data.
• Shared memory: one agent writes to a common state (thread, vector store, notes file) that another agent later reads back as a reliable source.
• Privilege escalation: a payload that would do nothing to the exposed agent has an effect on the next agent, which holds broader permissions.

Which attacks have been demonstrated on multi-agent systems?

One academic study gives concrete measurements. Triedman, Jha and Shmatikov (March 2025, revised September 2025) show that adversarial content placed in an untrusted input (web page, file, attachment) can take over communication between agents and trigger arbitrary code execution or data exfiltration. With GPT-4o agents, web-based attacks succeeded in 58 to 90 percent of trials depending on the orchestrator, and up to 100 percent in some configurations. The authors note the attack works even when each agent on its own resists direct or indirect injection.

That finding changes how to test: validating each agent separately is not enough. The assembly, meaning the orchestrator and its routing rules, creates the flaw.

What does the A2A protocol change?

The Agent2Agent (A2A) protocol standardizes discovery and exchange between agents. Each server publishes an "Agent Card", a JSON document describing its identity, capabilities, skills, endpoint and authentication schemes. The specification requires servers to reject requests with invalid or missing credentials and treats authorization separately. So the protocol gives an authentication framework, but says nothing about how trustworthy the content returned by the remote agent is.

That is what Palo Alto Networks' Unit 42 team showed on October 31, 2025 with "agent session smuggling". A2A sessions keep state, so a malicious remote agent can use one as a covert channel to slip instructions between the client's request and the server's response. In their two proofs of concept, a compromised research assistant gradually extracted configurations, tool schemas and session history from a financial assistant, then, in the other scenario, caused an unauthorized stock purchase (10 shares). The chain: legitimate delegation, clarification questions, gradual disclosure, unauthorized action.

How do you test for injection propagation?

You test propagation by placing a single traceable payload at the most exposed entry point, then observing how far it travels. The method has five steps:

1. Map the agents, their tools, their permissions and the channels between them (direct calls, shared memory, A2A, message queues).
2. Pick entry points: anything a third party can write (web page, ticket, email, uploaded document, form field).
3. Seed a marked payload, for example a benign instruction asking to add a unique keyword to the next action. The marker shows which agent followed it.
4. Follow the trace in the logs: does the marker appear in the sub-agent's output, in the orchestrator's order, in a tool call?
5. Raise severity only afterwards, on a test environment: calling a write tool, reading out-of-scope data, sending to an external destination.

The questions that surface flaws:

• Does the sub-agent that reads the web have access to write tools? It should not.
• Does the orchestrator tell data from instructions, or does it paste everything into the same prompt?
• Does a payload written to shared memory fire in a later session opened by a different user?
• Can a remote A2A agent ask clarification questions that lead the client to disclose its configuration?

For test environments, CleanIssue defaults to development or staging. Testing in production happens only at the client's written request.

Which safeguards reduce propagation?

Before choosing controls, decide what each agent is allowed to cause. An agent that only reads and summarizes can be compromised with limited consequences. An agent that can write, send or delete must be treated as the last line of defense, because it is the one a payload is trying to reach. The list below follows that logic.

Effective safeguards sit between the agents, in the code that connects their exchanges. OWASP ranks prompt injection as LLM01:2025: a rule written in a prompt remains an instruction the model can ignore.

• Separate roles: the agent that reads untrusted content has no write tool and no access to secrets.
• Type the messages between agents: a sub-agent result is structured data with a schema, not free text pasted back into a prompt.
• Validate outside the model: actions with effects (send, write, delete, pay) go through a deterministic rule or human approval.
• Limit shared memory: partition by user and session, and record who wrote what.
• Authenticate remote agents: verify the Agent Card identity and limit what an A2A session can ask for.
• Log the whole chain: every delegation with its origin, so you can trace back to the entry.

Why does a manual test complement scanners?

A scanner sends known payloads (we compare the main ones in a separate article) to an entry point and reads the final reply. A multi-agent system requires understanding the routing: which agent decides what, with which data, and where to place the payload so it crosses. That means reading the architecture and then running targeted trials, as described in our method.

The Agent Red Team Express (€1,900, 5 days, start within 48 hours after the quote and authorization are signed) covers one agent and its direct boundaries. For a system with several agents, an orchestrator and A2A exchanges, the scope is quoted individually: see the Custom Red Team. The first step is a free 30-minute discovery call.

Further reading

• Prompt injection: the guide
• AI agent red teaming
• AI agent security
• Indirect injection through RAG
• Human-in-the-loop: approving agent actions