AI Systems Atlas

S-13Agent-to-Agent Trust

/security/agent-to-agent-trust

One agent’s output is another agent’s untrusted input — and internal provenance is not trust.

Step-by-step walkthrough2 variants · 12 steps

Attack

  1. A read-only research agent fetches a page. Low risk — it holds no dangerous scope.
  2. The page carries instructions aimed at whatever reads it next.
  3. The researcher summarizes. The payload survives the summary, now in the agent’s own voice.
  4. The digest crosses to the implementer — which holds write and deploy scope.
  5. Nothing marks the boundary. Internal provenance reads as trust.
  6. The privileged agent acts on text an attacker wrote. The trust boundary was never drawn.

Defended

  1. Same fetch, same payload. The attack has not changed.
  2. The page still carries instructions. You cannot prevent this half.
  3. The researcher emits structured fields, not prose — and every field records its source.
  4. The implementer’s prompt treats the digest as data to reason about, never as instructions to follow.
  5. Even when persuaded, the implementer can only propose. It does not hold the deploy authority.
  6. The action is authorized against the requesting user’s permissions — not the agent’s.
Key insight

Multi-agent systems quietly launder taint. Text an attacker wrote arrives at the privileged agent in a teammate’s voice, and “it came from our own agent” is exactly the reasoning that makes it dangerous.

Failure mode

Drawing the trust boundary only at the system’s edge. Inside a four-agent pipeline every handoff is an injection point, and the agent holding the write scope is usually the last one.

Further reading
RelatedHierarchicalSingle vs Multi-AgentConfused deputy

Elsewhere in the atlas

Harnesses →Evals →Context →Coding Agents →Tools →Ops →