Multi-Agent Prompt Injection

What Is Multi-Agent Prompt Injection?

Multi-agent prompt injection describes what happens to injected influence once a system consists of several cooperating agents. One agent reads external content, summarises it, delegates a subtask, or returns a result, and that material becomes the input of another agent that has a different context, a different task framing and often a different set of capabilities.

The interesting property is not that a model can be influenced. That is already covered by indirect prompt injection and, for a single agent loop, by AI agent prompt injection. What is specific here is propagation: influence that entered at one place in the system can travel across agent boundaries, lose its provenance on the way and arrive somewhere with more reach than the point where it started.

Propagation, Not a Third Entry Variant

Entry into a multi-agent system is still direct or indirect. A user can supply competing instructions through an intended input channel, or external content can carry them in through a website, an email, a document, a retrieved passage, a repository file or a tool result. There is no separate third entry mode that only exists because more than one agent is involved.

Treating this as propagation rather than as a new entry class keeps the analysis honest. The question to answer for a given system is not whether agents talk to each other, but which edges are influenceable, how far content actually travels, and which authority decision is made at each arrival point.

Scope and Neighbouring Classes

Insecure inter-agent communication deserves particular care. Signing, mutual authentication and schema validation address transport and message integrity. They do not decide whether the text inside a well-formed, correctly signed message should be allowed to steer another agent.

The Multi-Agent Pipeline and Its Trust Boundaries

Orchestrator, policy engine, authorization service and the agent runtimes are operator-controlled. External content is untrusted by default. Everything an agent produces from that content, including messages to peers, summaries and plan proposals, is variable: its security meaning depends entirely on how the receiving side classifies and gates it.

Inter-Agent Output Is Data by Default

When agent B receives a message from agent A, that message is an observation. It reports what another component produced; it does not report a verified fact, an authorized instruction or a sanctioned goal change. If agent A consulted external sources, its output inherits that exposure, and the receiving agent has no way to see which parts of the text originated where unless provenance travels with it.

Microsoft's shared responsibility guidance for AI agents states the same point for orchestration: in multi-agent setups one agent's output becomes another agent's instruction, which creates a new trust boundary, and agent, tool and retrieval outputs should be treated as untrusted with actions gated accordingly.

Authentication Is Not Instruction Authority

Mutual TLS, signed envelopes, workload identity and a registry of approved agents are valuable. They establish who sent a message and that it arrived intact. None of them establishes that the sender was entitled to expand the task, that the content inside is free of external influence, or that the receiver may act on it.

The failure pattern to avoid is an implicit rule of the form "internal message, therefore trusted input". Internal origin is a property of the transport path, not a property of the text. Research on output attestation and delegation ancestry explores cryptographic evidence for where an output came from and which delegation chain produced it; that evidence strengthens accountability and forensics, but attestation of an output does not prevent the output from having been influenced in the first place.

Delegation Is an Authorization Problem

The security question in a multi-agent system is rarely "can these agents talk". It is "what may a called agent do because it was called". Delegation is the mechanism by which authority moves, and it needs the same rigour as any other authorization decision.

1. 01
   Explicit

   Delegated scope is stated, not inferred from the fact that one agent can reach another.

2. 02
   Task-bound

   The scope refers to the current task and intent, not to the callee in general.

3. 03
   Non-amplifying

   A child receives at most a subset of the authority currently held for that task.

4. 04
   Time-limited

   The delegation expires with the task or sooner, and is not reusable in later runs.

5. 05
   Externally enforced

   The decision is made by a policy component outside the model, not by the wording of a message.

6. 06
   Auditable

   Who delegated what to whom, for which task and under which policy version, is recorded.

The Zero Trust guidance for least privilege with AI agents describes the operational side of this: revalidate identity, role and scope at every hop, preserve on-behalf-of context, issue task-scoped and just-in-time permissions, require downstream authorization, and keep the decisions auditable. Research on bounded delegation in multi-agent systems argues for the same direction conceptually, with delegated scope, accumulated session state and external authorization as the design primitives; those are research proposals, not settled standards.

Context That Must Survive Every Hop

Most practical failures are losses of this context rather than dramatic breaks. A summary drops the source label; a message bus carries only the text; a nested call replaces the initiating principal with a service account. After two or three such losses, a downstream authorization decision is made on information that no longer describes the real request.

Trust Transitivity Must Fail Closed

That agent A may call agent B says something about the call graph. It says nothing about B's data. Trust in a component and trust in the content that component returns are different relations, and the second must not be derived from the first.

Fail-closed means that when the receiving side cannot determine provenance, delegated scope or intended authority, the content is handled as untrusted data and the requested action is denied rather than allowed by default.

Confused Deputy and Over-Broad Delegation

The classic confused-deputy shape appears clearly in agent systems: a more-privileged agent performs an action on behalf of a less-privileged requester without checking whether the requester was ever entitled to that action. The privileged agent is not compromised. It is simply being used as an instrument.

Propagation Surfaces Between Agents

Each surface should have an owner, a schema, a provenance contract and a stated trust level. A surface that any agent may write and any agent may read without labels is the most efficient propagation path a system can offer.

Orchestration Topologies and Reach

Topology does not determine whether influence occurs, but it determines how many contexts one influenced item can reach and how many independent decision points stand between that item and an effect.

Cross-Agent Contamination of Derived State

Derived state is where multi-agent propagation becomes durable. A summary written by one agent, a note placed in shared memory, an entry added to an index or a status written to a ticket can be read much later by a different agent, for a different user, in a different task.

This overlaps with memory and context poisoning, which is its own class with its own controls. The multi-agent aspect is that the writer and the reader are different components with different privileges, so contamination can also move authority-relevant framing, not just content.

The Multi-Agent Success Chain

1. 01
   Influenceable edge exists

   An attacker or user can control content that some agent in the system will consult.

2. 02
   Content enters agent A context

   The material becomes model-visible for the first agent.

3. 03
   Agent A output is influenced

   A message, summary or recommendation measurably reflects the injected content.

4. 04
   Content crosses the edge

   The influenced output is transmitted to another agent through a propagation surface.

5. 05
   Agent B treats it as authority

   The receiving agent lacks provenance or classifies the content as an instruction rather than data.

6. 06
   Relevant capability is reachable

   Agent B holds or can request a capability that could produce the intended effect.

7. 07
   Proposal reaches authorization

   A concrete action with resource and parameters is submitted for a decision.

8. 08
   Delegation or policy fails

   The scope was over-broad, not re-checked, or no rule covered the case.

9. 09
   Effect occurs

   An unauthorized access, modification, transmission or persistent change actually happens.

Every hop repeats the later stages. A chain can therefore be cut many times over, and in a well-built system it usually is.

Competing Constraints Across Hops

Early constraints can mean there was never any model exposure; late ones mean influence is observable while no security-relevant effect occurs. Recording which constraint held, and at which hop, is the actual result of an assessment.

Authorized Offensive Assessment

Multi-agent testing belongs in an authorized engagement with written scope, bounded permissions or a non-production environment, synthetic data and reversible effects. The goal is to map edges and gates, not to prove that a language model can be influenced.

Worked Scenario

A synthetic support organisation runs two agents. A triage agent reads incoming issues, including comments submitted through a public portal, and may hand a structured briefing to an operations agent. The operations agent may update the status and summary of the one ticket named in the briefing. Neither agent may read unrelated customer records, and neither holds an outbound messaging tool.

Re-Authorization at Every Edge

An authenticated message never transfers authority on its own, and an approval given earlier in a workflow is not an approval for a later, differently parameterised action. If parameters, target or the underlying state change between decision and execution, the decision must be made again.

Downstream Authorization and Credentials

The resource owner is the last place where the request can be judged against reality. A downstream service that accepts a call because the orchestrator approved it has effectively delegated its access control to a component that does not know its data model.

Monotonic, Non-Amplifying Delegation

A delegation chain should be monotonic in the direction of narrowing. Each hop may hand on a subset of the authority currently held for the task, and never more. Being delegated to is not itself a reason to hold more.

Research on bounded delegation for multi-agent systems formalises this as keeping the blast radius non-amplifying across delegation, together with external authorization and explicit handling of accumulated session state. That is a research design direction rather than an established standard, and it is cited here as such.

Loop, Cascade and Fan-Out Containment

Multi-agent systems fail in patterns single agents do not: two agents reinforcing each other's conclusions, a briefing that fans out to many workers, a delegation cycle that never terminates, a faulty result that propagates through every dependent task.

OWASP's agentic risk list treats cascading failures as its own concern for good reason: the damage pattern can arise from an ordinary fault as easily as from an injection, and the containment controls are the same either way.

Detection and Telemetry

Useful signals include content appearing in an agent that never had a legitimate reason to see it, goal or scope drift after a handoff, an unexpected new delegation edge, repeated denied cross-agent proposals, a proposal that does not match the executed operation, growing fan-out within one task, and writes to shared state from agents that normally only read.

Defensive Architecture

The additional controls that matter most between agents are message schemas that separate system control fields from externally authored text, per-edge policy rather than one global allowance, memory isolation between agents and tasks, sandboxed execution without standing credentials, egress control, and the loop and fan-out limits described above.

Controlled Testing and Metrics

Each metric needs its own explicit denominator and must be reported separately. A composite cross-agent score hides which edge leaked and which gate held, and makes results incomparable between architectures.

Benign task utility belongs alongside these as a separate dimension, never merged into them: a system that blocks every handoff scores perfectly on containment and fails at its purpose. Without that separate measurement, a control can look strong simply because it prevents useful work.

Incident Response

Classification discipline matters more here than in a single-agent case, because a chain produces many intermediate states. An influenced briefing, a denied cross-agent proposal and an executed out-of-scope action are three different outcomes with three different remediations.

Standards and Research Context

OWASP LLM01:2026 defines prompt injection as the mechanism by which inputs alter model behaviour, and LLM03:2026 describes excessive agency as the enabling design risk. The OWASP Top 10 for Agentic Applications 2026 provides the agent-specific classes used here: insecure inter-agent communication as the boundary, identity and privilege abuse as the amplifier, memory and context poisoning as a propagation surface with its own controls, and cascading failures as the systemic effect pattern. NIST AI 100-2e2025 supplies the terminology for prompt injection and adversarial machine learning.

The Microsoft shared responsibility model for AI agents is the clearest published statement of the core idea in this article: in multi-agent orchestration one agent's output becomes another agent's instruction, which creates a new trust boundary, so agent, tool and retrieval outputs are treated as untrusted and actions are gated. The Zero Trust guidance on least privilege for AI agents adds the operational expectations: revalidate identity, role and scope at every hop, preserve on-behalf-of context, grant task-scoped and just-in-time authority, require downstream authorization and keep the chain auditable. These are product-level recommendations and are cited as such.

Two NIST items describe direction rather than settled requirements. The 2026 NCCoE concept paper on accelerating adoption of software and AI agent identity is an initial public draft whose comment period has closed; it addresses identity, authentication, authorization, delegation and on-behalf-of context, auditing and non-repudiation, and prompt-injection mitigation. The NIST programme page on AI research, security and resilience states that control-overlay work covering single-agent and multi-agent systems is under development. Neither should be read as completed guidance.

On the research side, work on bounded delegation for multi-agent systems develops delegated scope, accumulated session state, external authorization and non-amplifying blast radius as design concepts; work on attesting outputs and delegation ancestry explores cryptographic evidence for output origin and delegation chains, which supports accountability without preventing injection; and a study of prompt injection in multi-agent robotic systems reports empirical cross-agent propagation in that specific domain, which should not be generalised to other architectures. All three are research contributions, not standards. Related site material covers the single-agent loop under AI agent prompt injection, the response side of a tool call under tool output injection, retrieval paths under RAG prompt injection, and the control architecture in the defense area.

Frequently Asked Questions