Agent-to-agent protocol security — what A2A adds beyond MCP

The clearest way to see why A2A needs its own threat model is to name what is different about the relationship. An MCP tool call crosses an agent-to-tool boundary: the agent is invoking a described, bounded capability with a fixed input/output schema. The tool does not reason. It does not decide whether to comply, does not have its own goals, and does not sub-delegate. Whatever damage a compromised tool call can do is bounded by the tool's own scope.

An A2A delegation crosses an agent-to-agent boundary: the receiving agent is itself a reasoning system, with its own tool access, its own context, and — critically — its own capacity to further delegate. When Agent A asks Agent B to “research supplier X and draft an outreach email,” Agent B might call three tools, consult a knowledge base, and delegate a sub-task to Agent C, all before returning a result to Agent A. The delegating agent has handed off not just a task, but a slice of trust, to a system it does not fully control and whose downstream actions it cannot fully see.

An MCP tool call is bounded by what the tool can do. An A2A delegation is bounded by what the receiving agent — and everything it, in turn, decides to delegate — can do. The second boundary is much harder to draw.

A2A does not replace MCP in a typical deployment — most agent-to-agent systems still use MCP (or an equivalent) for the agent-to-tool leg of each individual agent's work. What A2A adds is a second layer above that: discovery of other agents' capabilities, negotiation of a task, transfer of context and authority, and handling of the result. Five threats live specifically in that added layer, and none of them map cleanly onto an MCP tool-poisoning or transport-security control.

Agent discovery typically works through some form of published capability descriptor — an “agent card” advertising what the agent can do, what skills it exposes, and how to reach it. This is structurally identical to the MCP tool-descriptor trust problem covered in tool poisoning, and it inherits the same failure mode: nothing about the descriptor format guarantees the agent behind it actually does what the card claims, or is who it claims to be.

The added danger at the agent layer is that a spoofed capability card does not just mislead a human integrator — it can mislead an orchestrating agent's own reasoning at run time, if the orchestrator selects a delegation target dynamically based on advertised capabilities rather than a pre-approved registry. An orchestrator that discovers and delegates to agents based on live capability advertisement, without an allow-list, is delegating trust to whichever agent presents the most convincing card.

When Agent A delegates to Agent B, what travels with the task? In a naive implementation: a natural-language instruction and maybe a context blob. What should travel with it: a signed record of who originated the task (which human, or which upstream agent, ultimately authorised this), what scope of authority is being delegated, and when that authorisation expires.

Without that provenance chain, Agent B has no way to distinguish a legitimately delegated task from one injected by a compromised upstream agent, a man-in-the-middle on the delegation channel, or a prompt-injection payload that caused Agent A to originate a task it should not have. And critically, neither can an auditor reconstruct after the fact who actually authorised an action three delegation hops downstream — which is precisely the audit-trail requirement covered in agentic-ai-audit-trail, extended across an agent boundary instead of within a single agent's tool calls.

This is the threat that most concretely distinguishes A2A review from MCP review, and the one we see missed most often. Agent A has been granted tool access X, Y, Z through careful, reviewed, least-privilege scoping — exactly the discipline described in tool-use-permissions-agentic-ai. Agent A delegates a task to Agent B. If Agent B executes that task under Agent A's full tool grant rather than a scoped sub-identity, the careful scoping done for Agent A has been silently extended to an agent nobody scoped permissions for.

Worse, this can chain. Agent B delegates part of its sub-task to Agent C. If each hop inherits the previous agent's full grant rather than a narrower delegated scope, the effective tool access at the end of a three-hop delegation chain can be the union of every agent's permissions in the chain — a privilege-escalation path that exists purely because of how delegation is implemented, with no single compromised component required to trigger it.

The review question is direct: when Agent A delegates to Agent B, does Agent B execute under its own scoped identity with only the specific capabilities the task requires, or does it inherit Agent A's ambient permissions? If the system cannot answer that question with a specific mechanism — not a policy statement, an actual enforcement point — treat transitive access as unbounded until proven otherwise.

A result returned from a delegated agent is not a return value from a function call. It is content produced by an autonomous system that may itself have ingested untrusted input during its work — a poisoned document, a manipulated tool response, an injected instruction from somewhere in its own execution. If Agent A treats Agent B's returned artefact as trusted context and acts on it directly, any compromise anywhere in Agent B's execution chain propagates straight back into Agent A's reasoning.

This is the same insecure-output-handling problem covered for LLM outputs generally, applied one level up: the “output” here is an entire delegated agent's worth of reasoning and tool use, compressed into a result the receiving agent is tempted to trust because it came from a system explicitly asked to do the work. Trust should scale inversely with how much autonomous reasoning produced the artefact, not the other way round.

The most consequential deployments of agent-to-agent delegation cross organisational boundaries entirely — your procurement agent negotiating with a supplier's sales agent, your logistics agent coordinating with a carrier's dispatch agent. Here, the delegating and receiving agents are operated by different organisations with different security postures, different incentives, and no shared administrative control.

Identity federation across that boundary needs to be explicit and bounded. An agent from another organisation authenticating successfully proves it is who it claims to be; it does not prove its organisation's security posture is adequate, that its own tool-scoping discipline matches yours, or that a task you delegate to it will not be further sub-delegated to a fourth party you have never assessed. Cross-organisation A2A is, in effect, a vendor relationship conducted at agent speed, and it deserves the same third-party assessment rigour as any other AI vendor relationship — with the added wrinkle that the “vendor” here is a live decision-making system, not a static API.

Consolidated, the five threats and the controls that close each one:

None of these controls require abandoning MCP for the agent-to-tool leg of the system. They sit above it, at the agent-to-agent layer, and a system that has both layers needs both threat models applied — the MCP threat model for how each individual agent uses its tools, and this one for how agents use each other.

For any system where the architecture diagram shows an arrow between two agents rather than an agent and a tool, a review should be able to answer each of these before clearing the system for the lifecycle gate in question:

• Is agent discovery constrained to an allow-list, or does the orchestrator select delegation targets from live, unverified capability advertisements?
• Does every delegated task carry a verifiable provenance chain — origin, scope, expiry — that the receiving agent checks before acting?
• Does a delegated task execute under a scoped sub-identity, or does it inherit the delegating agent's full tool grant?
• Are returned artefacts from a delegated agent re-validated before being acted on, or fed to a further agent, rather than trusted as-is?
• For cross-organisation delegation, has the receiving organisation's agent been through the same third-party assessment rigour as any other AI vendor with equivalent access?

A system that can answer all five with a specific mechanism — not a policy intention — has an agent-to-agent boundary that has actually been reviewed. A system that can only answer the MCP-layer questions has reviewed half of its own architecture.