MCP (Model Context Protocol) and A2A (Agent-to-Agent) are two distinct protocols that address different communication problems in agentic systems. MCP is a standard for connecting an agent to external tools and data sources. A2A is a pattern for letting one agent delegate work to another agent. They are complementary, not competing, and understanding where each protocol starts and stops helps you reason about the security controls each one requires. For a deeper look at MCP specifically, see what the Model Context Protocol is and why it matters.
What MCP Does
MCP defines how an AI agent discovers and calls tools exposed by external servers. The protocol specifies how a client (typically an agent or an orchestrating model) connects to an MCP server, receives a manifest of available tools, and then invokes those tools with structured arguments.
From the agent's perspective, an MCP server is a capability endpoint. It might expose a web search tool, a code execution sandbox, a database query interface, or a file system. The agent does not need to know the implementation details of any tool; it reads the manifest, selects the appropriate tool for the task, and sends a call. The MCP server executes the operation and returns a result.
The value of a standard protocol here is consistency. Instead of hand-rolling bespoke integrations between every agent and every external service, MCP gives both sides a common contract. An agent built by one team can call an MCP server built by another team without custom glue code.
What A2A Does
A2A addresses a different problem: how does one agent hand off a sub-task to another agent and receive the result? In a multi-agent system, you often have a coordinator or orchestrator agent that decomposes a goal into subtasks and routes each subtask to a specialist. The specialist might be a different model, a different deployment, or a purpose-built agent running in a separate environment.
A2A communication defines the messaging contract for this delegation: how the orchestrator identifies and addresses the target agent, how it passes context and parameters, how the target agent reports progress or returns results, and how errors propagate back up the chain.
The critical distinction from MCP is the type of entity on the receiving end. MCP servers expose deterministic, scoped tools. A2A targets are themselves autonomous agents that make decisions, consume LLM tokens, and can initiate further downstream calls. That autonomy changes the risk profile substantially.
How They Fit Together
A realistic multi-agent architecture uses both protocols at once. Consider an orchestrator agent tasked with generating a market analysis report. It might:
- Delegate the data-gathering subtask to a researcher agent via A2A.
- The researcher agent calls a web search MCP server and a database query MCP server to gather raw data.
- The researcher returns structured findings to the orchestrator over A2A.
- The orchestrator delegates the writing subtask to a writer agent via A2A.
- The writer agent calls a document storage MCP server to save the draft.
In this flow, A2A carries the inter-agent coordination and context propagation. MCP carries the tool calls that ground each agent's actions in real data and real side effects. Removing either layer collapses the architecture: without MCP the agents cannot act on the world; without A2A the system cannot scale beyond a single monolithic agent.
The Security Considerations Are Different
Because the two protocols serve different purposes, the controls they require diverge in important ways.
MCP security centers on tool scoping and call-level authorization. The key questions are: which agents are allowed to call which tools, with what arguments, and within what rate limits. An agent that should only be able to read documents must not be able to invoke a tool that writes or deletes them. Principle of least privilege applies at the tool level. You also need visibility into every tool invocation — the tool name, the arguments passed, the identity of the calling agent, and the result — so you can detect anomalous patterns and reconstruct what happened during an incident.
A2A security centers on agent identity, delegation chains, and trust propagation. The key questions are: is the calling agent who it claims to be, is it authorized to invoke this target agent, and how far can delegation cascade. When agent B is invoked by agent A, and agent B then invokes agent C, each hop needs verifiable identity and scoped authority. A2A architectures are vulnerable to privilege escalation if a downstream agent inherits more authority than the original caller held — sometimes called the confused deputy problem applied to agents. This is explored in depth in the A2A delegation abuse threat model.
Both protocols share some common requirements: mutual authentication, encrypted transport, structured audit logging, and the ability to revoke access without redeploying agents.
Authentication Patterns for Each Protocol
For MCP, authentication typically flows from the agent to the MCP server. Common patterns include API keys scoped to a specific agent identity, OAuth 2.0 client credentials grants where the agent presents credentials to obtain a short-lived token, or mTLS where the agent's certificate asserts its identity. The MCP server validates the credential and enforces the tool-level policy for that identity.
For A2A, the authentication surface is wider. The orchestrator needs to prove its identity to the target agent. The target agent needs to prove its identity back to the orchestrator when returning results. When a governance platform acts as the intermediary, each agent authenticates to that platform rather than directly to its peers, and the platform enforces authorization policy and logs the exchange. This intermediary model simplifies credential management significantly: agents don't need to hold credentials for every other agent they might ever call; they hold credentials for the platform.
A well-designed A2A system also tracks the full delegation chain. If orchestrator A delegated to agent B which delegated to agent C, the audit record for agent C's actions should reflect the entire ancestry, not just the immediate caller. This matters for incident response and for enforcing policies like "no delegation chain longer than two hops."
Tool Scope vs Agent Trust
One practical tension that emerges when operating both protocols is the mismatch between static tool scope definitions and dynamic agent trust.
MCP tool permissions tend to be configured at registration time: when you connect an MCP server to your platform, you declare which agent identities are allowed to call which tools. This is straightforward to reason about and audit.
Agent trust in A2A is more dynamic. An agent's trustworthiness depends on its recent behavior, its deployment provenance, whether its model version or system prompt has changed, and whether it has behaved anomalously in prior runs. Static allow-lists capture the identity dimension but miss the behavioral dimension. More mature programs layer a dynamic trust signal on top of static identity verification, so a misbehaving agent can be downgraded or quarantined without waiting for an administrator to manually revoke credentials.
This is one of the more nuanced aspects of securing multi-agent systems: you are not just authenticating fixed software components, you are governing autonomous actors whose behavior can change in ways that a credential alone does not capture.
What a Governance Layer Needs to Handle
Whether you are securing MCP calls, A2A delegation, or both, a few capabilities consistently matter:
| Requirement | Why it matters for MCP | Why it matters for A2A |
|---|---|---|
| Verifiable agent identity | Attribute tool calls to a specific agent | Authenticate orchestrators and delegates |
| Scoped credentials | Limit which tools an agent can invoke | Limit which agents a caller can invoke |
| Immutable audit logs | Reconstruct tool call history | Reconstruct delegation chains |
| Real-time revocation | Deny a compromised agent's tool access | Stop a misbehaving agent from accepting new tasks |
| Content inspection | Detect prompt injection in tool responses | Detect payload manipulation between agents |
| Spend controls | Cap token and API costs per agent | Cap cascading spend across delegation chains |
A unified governance approach applies the same identity, policy, and audit infrastructure to both MCP interactions and A2A communication, giving you a single place to set policy, a single audit trail to query, and a single revocation mechanism that works across both protocols. For a broader look at what this means in practice, see what an AI control plane does and how it differs from a simple API gateway.
Common questions
Does an agent need both MCP and A2A, or can it use just one?
That depends entirely on what the agent does. A simple single-agent system that calls external tools needs MCP but not A2A. A multi-agent pipeline that routes tasks between specialists needs A2A for the inter-agent layer. Many real deployments use both: specialists communicate with external services over MCP while an orchestrator coordinates specialists over A2A.
If an orchestrator delegates to a sub-agent via A2A and that sub-agent calls an MCP tool, whose identity appears in the MCP tool call?
This is an important design question. In a naive implementation the MCP server sees the sub-agent's identity and has no knowledge of the orchestrator that initiated the chain. In a governance-aware implementation, the sub-agent forwards the delegation context — a signed token or chain assertion that includes the orchestrator's identity — along with the tool call. The MCP server can then enforce policy at both the immediate caller level and the origin principal level.
How do I prevent an A2A delegation chain from running up an unbounded bill?
Budget controls need to track spend across the entire delegation chain, not just per agent. A per-agent budget catches individual overconsumption but misses coordinated spend across a chain where each agent individually stays within limits while the total exceeds what you intended. The right control is a hierarchical budget that applies to the originating workflow or task, deducting from a shared envelope as each agent in the chain consumes tokens or makes API calls.