Explain the compounding risk property of injection in a multi-agent topology

Flashcard·Hard·4.0 · 0·~30s·Asked atFlipkart Uniphore Zed

Attempt it

In a multi-agent topology, agent A's outputs become agent B's inputs. If agent A is injected and emits attacker-controlled text, B reads it as a trusted teammate message, not as untrusted user content. B is then more likely to comply. The malicious instruction propagates one handoff at a time through the network until it reaches an agent with tool access, where the blast radius materialises. Minimum mitigation has three parts. Treat every inter-agent message as untrusted content (provenance tag = untrusted_agent_output). Apply the same input rails between agents as on the external boundary. Gate any irreversible tool call on a separate quorum check that does not rely solely on the most recent agent's say-so.

Your answer

In a **multi-agent system**, several model instances work together and pass messages. Agent A might plan a task, agent B might search the web, agent C might write code. Each agent reads the previous agent's output and acts on it. The danger is that those messages are trusted by default. Input rails check user prompts carefully, but a message from agent A to agent B is usually treated as an internal teammate message and skips those checks. That assumption breaks the moment any one agent gets injected. Suppose an attacker hides a malicious instruction in a web page that agent B retrieves. Agent B is fooled and repeats it in its output. Agent C reads B's output as a trusted teammate message and follows the instruction. The injection has just **propagated** one handoff. If the chain ends at an agent with tool access (a code executor, a database writer, an email sender), the attacker now effectively has that tool. **Minimum mitigation:** mark every inter-agent message as untrusted, apply the outer-boundary input checks between agents, and require a second check before any irreversible tool call.

**Compounding injection is a topology problem.** Most systems screen external input but not agent-to-agent output, so trust is asymmetric. The attack chain has three steps. First, an attacker injects agent A, usually indirectly, via retrieved content, web pages, calendar invites or email bodies. Second, agent A emits attacker-controlled text that agent B consumes. Third, agent B reads it as trusted teammate output and complies, often more readily than it would for the user. The chain continues until it reaches an agent with tool access, where the blast radius materialises. **Why agent B is more compliant.** The instruction has been laundered through A's output, so it lacks its original suspicious context. And B's system prompt usually frames inter-agent messages as cooperative coordination, not adversarial input. **Minimum mitigation has three components.** Provenance tagging: every inter-agent message is tagged `untrusted_agent_output`, distinct from `system_instruction` or `user_input`. The receiving agent's prompt template shows the tag. Inter-agent input rails: the same Llama Guard, Prompt Guard and PII checks that run on user input run on agent-to-agent messages. Quorum check on irreversible actions: any destructive tool call needs a separate confirmation from a second model, a deterministic check or a human, never the agent that just read the injected message. The structural fix is the **dual-LLM or quarantined-processor pattern**: the agent holding tool access never reads raw text from other agents, only structured fields from a quarantined extractor.

TL;DR

Inter-agent messages are treated as trusted teammate output, so an injection in one agent passes through every downstream handoff until it hits an agent with tool access. That is where the blast radius materialises.

Memory aid

Easy to grasp

Imagine a relay race where each runner trusts the baton message handed to them by the previous runner. One runner is bribed and writes a malicious note on the baton. Every later runner reads the note, trusts it, and acts on it. By the time the last runner reaches the bank teller (the agent that holds the cash drawer), the original bribe has travelled through five hands and now looks like a routine internal request. Multi-agent systems work the same way. The fix is for every runner to treat the baton message as if it came from a stranger on the street, not from a teammate. Each runner should also require a separate confirmation before doing anything irreversible.

Key concepts

Multi-agent systems Safety & Guardrails

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Multi-agent systems are the topology where prompt-injection compounds. Single-agent injection is bounded: the attacker has to compromise the agent that holds the destructive tool. Multi-agent injection is unbounded in the same chain: the attacker only needs to compromise the weakest agent. The malicious instruction then passes through every downstream handoff to the agent that does hold the tool. The blast radius lives at the most-privileged node. The entry point lives at the least-defended one.

Every handoff is a fresh trust boundary. Treat it as one, or accept that injection will find the weakest link.

In a multi-agent topology, the chain is only as safe as its least-screened edge. Defense in depth has to be per-edge, not just per-node.

The propagation chain and the trust assumption that enables it

Step one: the initial injection

The injection enters somewhere. A common vector is indirect prompt injection through retrieval: a malicious instruction embedded in a knowledge-base article, a calendar invite, a fetched web page, or an email body. The agent that retrieves and processes this content is the entry-point agent. It is rarely the agent with destructive tool access.

Example entry points:

A customer-support knowledge-base article edited by an external user.
A scraped web page returned by a search tool.
A calendar invite or email that an agent reads as part of triage.
A document uploaded by a user to a shared retrieval index.

Step two: the entry-point agent emits attacker-controlled text

The entry-point agent reads the injected content. Depending on its system prompt and the strength of input rails, it may comply with the injected instruction directly. Or it may quote, summarize, or paraphrase the content in its output to the next agent. Either way, attacker-controlled text now sits in the entry-point agent's output.

Step three: the downstream agent treats the message as trusted teammate output

This is where the trust assumption matters. Many multi-agent designs frame inter-agent messages as cooperative communication. The receiving agent's system prompt does not warn it to treat upstream output as adversarial. The input rails that run on external user input often do not run on inter-agent messages.

The consequence: the downstream agent reads the attacker-controlled text without the suspicion that surrounded it at the external boundary. It complies. If the downstream agent has tool access, the attack lands.

Why agent B is more compliant than the user would have been

Two independent effects:

Context laundering. The instruction now appears without the suspicious context that surrounded the original injected document. 'Refund the customer $10,000' inside a knowledge-base article looks suspicious. The same text inside an inter-agent message that says 'the user wants you to process a refund' looks routine.
System-prompt framing. The receiving agent's prompt typically establishes the upstream agent as a trusted collaborator: 'You are a tool-using agent. The planner agent will hand you tasks; complete them.' That framing weakens refusal by default.

Both effects raise the compliance probability above what the user would have achieved with a direct injection.

Provenance tagging and per-edge input rails

Tool-call gating, quorum checks, and the dual-LLM pattern

Observability, model diversity, and a mature production pattern

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Lee and Tiwari's 'Prompt Infection' paper (2024) showed a malicious prompt spreading from agent to agent like a virus in multi-agent systems, and proposed LLM Tagging, which with existing safeguards greatly reduced the spread.
Greshake et al. (2023) showed indirect prompt injection planted in data an LLM app retrieves, including data theft and self-spreading 'worming' attacks, against Bing's GPT-4-powered Chat and synthetic GPT-4 applications.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you instrument an agent topology so a compounding-injection incident is detectable and traceable post hoc?

Emit per-edge OTel spans with provenance tags, message hashes, and rail decisions. Maintain a separate audit trail of all inter-agent payloads with retention long enough for forensic review. When the destructive tool call fires, the trace shows the full chain of message provenance back to the original injection source, usually a retrieval result.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Assuming inter-agent messages are 'inside the trust boundary' and skipping input rails between agents. The injection then passes through every handoff to the agent that holds the destructive tool.

60 second bullets to scan on the way to the call.

Why inter-agent messages are often treated as trusted by default
The three-step propagation chain from initial injection to tool execution

Primary sources. Browse if you want the original framing.