Primer

A2A

Agent-to-Agent (A2A) communication is the property that agents talk to each other directly, not just to users. The vocabulary is now standardizing: Google's A2A protocol provides a public specification for discovering capabilities, sharing tools, delegating tasks, and negotiating consent between agents. OWASP and MAESTRO both treat A2A as one of the four agentic factors that distinguish agentic systems from conventional software.

How agent A actually talks to agent B

Stripped to essentials, an A2A interaction is seven steps: mutual auth, capability discovery, task delegation, authorization handoff, possibly some tool invocation (often through MCP servers), a response back, and a memory commit. Each step is a place where threats trigger. The interactive sequence view lives in the fintech reference scenario on the canvas. Click into the Orchestrator and look at its llm-interagent seam.

The seven steps

Two swimlanes (Agent A on top, Agent B on the bottom) with seven labelled arrows for the named steps. Each step has its OWASP threat badge linked to the relevant threat page.

What's actually crossing the wire

1. Mutual authentication. Typically OAuth or mTLS. Establishes that A is talking to the B it expects, and vice versa. T9 Identity Spoofing targets this step; agents can be impersonated even with cryptographic auth if the principal binding is weak.
2. Capability discovery. A asks B "what can you do?" B returns a capability card listing tools, scopes, and constraints. T16 Insecure Inter-Agent Protocol Abuse targets this step: a malicious B can list overly broad or misleading tool descriptions, which A's planner will reason over as if they were trustworthy.
3. Task delegation. A sends B a task with a goal, scope, and consent context. The content of this message becomes input to B's reasoning. T12 Agent Communication Poisoning targets the message content; channel auth is necessary but not sufficient.
4. Authorization handoff. A's user authorization is converted into something B can act on. The two patterns are OAuth on-behalf-of (B acts as the user) and service account (B acts as itself, trusting A's request). T14 Human Attacks on Multi-Agent Systems targets this step: chained authorization is where confused-deputy patterns compose.
5. Tool invocation via MCP. B calls external tools through MCP servers. T2 Tool Misuse applies: B's selection of which tools to call (and with what parameters) was never directly authorized by A's user. See the MCP primer.
6. Response. B returns data, reasoning trace, and audit metadata. The reasoning trace and audit metadata are the only way A can later reconstruct what happened; T8 Repudiation applies if they're absent or unsigned.
7. Memory commit. A commits B's response to its own memory for future use. T1 Memory Poisoning applies: if B's response was poisoned, the poisoning now persists in A.

Why this is qualitatively different from a service call

A conventional service returns data the client routes. An agent reasons over the response. The response is content, not just a payload. That changes the threat surface. Standard request/response auth defends the channel; agentic threat models have to defend the content the receiver will reason over.

A2A can amplify risks involving delegation, shared state, and transitive trust. MAESTRO's cross-layer scenarios include Cascading Trust Failures, Inter-Agent Data Leakage Cascade, Misconfigured Inter-Agent Monitoring, and Malicious Agent Diffusion. Multi-agent variants can broaden blast radius unless communication, authorization, and state sharing are explicitly bounded.

The seams that fail in practice

Authorization propagation. Step 4 above. OAuth on-behalf-of and service-account flows answer the "whose identity" question differently, and the difference is exploitable. MAESTRO walks through this in its chained-authorization treatment.
Trust scoring. Once agents establish coordination, individual agents stop independently verifying upstream claims. Reputation-based trust is efficient and exploitable.
Consent boundaries. Did the user consent to this action, or to a goal that this action is one possible step toward? In a multi-step delegation the original consent gets paraphrased on every hop, often weakening as it travels.
Monitoring gaps. Most logging tools are designed for user → service interactions, not agent → agent. The detection surface for inter-agent anomalies is immature.

Where the OWASP catalog lands here

T12 Agent Communication Poisoning, T13 Rogue Agents, and T14 Human Attacks on Multi-Agent Systems are the threats explicitly created by A2A. T9 Identity Spoofing takes on a different shape in A2A because agents authenticate to each other and inherit trust transitively. T16 Insecure Inter-Agent Protocol Abuse overlaps directly with the protocol surface itself. The MAS Threat Catalogue extends this surface further: T30 Insecure Inter-Agent Communication Protocol addresses cases where the built-in inter-agent transport lacks encryption, authentication, or integrity protection, making messages vulnerable to eavesdropping, tampering, or spoofing in transit. In Web3 and cross-chain contexts, T37 Cross-Chain Bridge Attack applies where agents coordinate across blockchains: the bridge itself becomes an inter-agent seam that an attacker can exploit to steal assets or disrupt coordination.

Where to go next

T12 Agent Communication Poisoning: the threat that poisons task delegation messages in transit or at the receiving agent.
T13 Rogue Agents: what happens when a peer agent is itself compromised or fabricated.
T14 Human Attacks on Multi-Agent Systems: chained authorisation and confused-deputy attacks across agent boundaries.
T9 Identity Spoofing: mutual-auth failures at the handshake step.
SPIFFE workload identity: cryptographic agent identity that survives delegation hops.
Intent attestation: signing task messages so receivers can verify what the originating user actually authorised.
Cross-system audit: logging that spans agent boundaries so inter-agent anomalies are detectable.
MCP primer: tool invocation (step 5) connects the A2A surface directly to the MCP trust model.
Agents primer: the single-agent anatomy that multi-agent topologies replicate at each peer.

Sources: OWASP Agentic AI: Threats and Mitigations v1.1 (Dec 2025), §Multi-agent Architecture and §T16; MAESTRO v1.0 (Apr 2025), §1.2 Multi-Agent Pattern; OWASP MAS Threat Modelling Guide v1.0 (Apr 2025), §T30, §T37.