A2A Security
Agent Capability Negotiation in Agent-to-Agent (A2A) Security
Agent capability negotiation is the process by which one AI agent declares its identity, permissions, and available skills to another, typically through a discoverable metadata document, before a task or tool access is granted. In current A2A and MCP implementations, this exchange happens at discovery time and relies on self-reported data, meaning the actual trust decision (whether to grant access based on that declaration) occurs outside the protocol itself and must be enforced by the implementing system.
The Technical Steps of a Negotiation Exchange
-
1
Agent Card Publication
An agent publishes its identity, endpoint, and declared skills for discovery.
-
2
Authentication Reference
The card points to an external scheme such as OAuth2 or API keys, handled outside the protocol.
-
3
Capability Grant
A receiving agent evaluates the declaration and decides whether to proceed with a task.
-
4
Enforcement Gap
Neither A2A nor MCP mandates revalidation of that grant during an ongoing session.
What Capability Negotiation Actually Is
In multi-agent systems, capability negotiation refers to the exchange that determines what one agent is permitted to ask another agent to do, and what tools or data it can subsequently access. Google's Agent2Agent (A2A) protocol, now developed as a vendor-neutral project under the Linux Foundation, formalizes part of this exchange through an Agent Card: a metadata document describing an agent's identity, endpoint, declared skills, and supported authentication schemes. Other agents use this card to discover capabilities before initiating a task. Anthropic's Model Context Protocol (MCP) addresses a related but distinct surface, defining how an AI application connects to external tools through declared schemas that a model can invoke. A2A governs agent-to-agent task delegation; MCP governs agent-to-tool access. Enterprises running both protocols in the same workflow are managing two separate negotiation and trust boundaries, not one.
Security Risks When Verification Is Missing
Because Agent Cards and tool manifests are self-reported, the accuracy of a capability declaration is not guaranteed by the protocol. OWASP's agentic AI guidance identifies excessive agency, unauthorized tool or function invocation, and insufficiently monitored inter-agent trust relationships as core risk categories in this environment. In practice, this means an agent can declare capabilities it does not actually possess or is not authorized to use, and a receiving agent may grant access based on that declaration without independent verification. Privilege escalation risk arises when a negotiated grant persists across a long-running session without reverification, allowing an agent's effective permissions to drift from what was originally authorized. Capability spoofing risk arises from the absence of a protocol-native guarantee that a declared identity or skill set is accurate. Unauthorized tool access risk arises when MCP-style tool invocation is treated as implicitly trusted because it followed a valid A2A task delegation, even though the two protocols do not share a single authorization model.
A2A and MCP: Where Standardization Ends
Both protocols define how capabilities are declared, but neither defines how a declaration is verified or how trust is re-established over time. The two negotiation surfaces are summarized below.
| Protocol | Governs | Key artifact | Maintained by |
|---|---|---|---|
| A2A (Agent2Agent) | Agent-to-agent task delegation | Agent Card (identity, endpoint, declared skills, auth reference) | Linux Foundation (originated at Google) |
| MCP (Model Context Protocol) | Agent-to-tool access | Declared tool schemas | Anthropic |
Controls That Close the Gap
Neither protocol specifies a mandatory runtime policy enforcement point that revalidates a negotiated capability after the initial handshake. Closing this gap requires architectural components external to the agents themselves. A policy enforcement point (PEP) separate from the negotiating agents should evaluate declared capabilities against least-privilege rules at request time, rather than trusting the Agent Card or tool manifest directly. Agent identity verification, distinct from the human or service account that deployed the agent, needs to be established independently of the protocol's referenced authentication scheme. Where long-running sessions are involved, session-level reverification should be considered to prevent privilege drift beyond what was granted at handshake. Centralized audit logging of negotiation requests, grants, and subsequent tool or task invocations is necessary since no such logging is built into current specifications. When A2A and MCP are both in use, a mapping layer reconciling agent-level permissions with tool-level permissions is required to avoid inconsistent enforcement between the two negotiation surfaces.
Implementation Considerations for Production Systems
- Treat Agent Card and tool manifest data as untrusted input requiring validation against an independent policy source, not as a trust guarantee.
- Position a policy enforcement point outside the negotiating agents