Google A2A Protocol Capability Negotiation and Trust Model

Google A2A protocol capability negotiation and trust turn on a simple distinction. An Agent Card tells a client what another agent claims it can do, while authentication and deployment controls set the rules for what happens next. Reading the card makes collaboration possible across vendors and frameworks, but it does not make that collaboration trustworthy. A2A gives agents a common language, but organizations must enforce the boundaries.

What the A2A protocol is trying to solve and why capability negotiation is the hard part

Agents cannot collaborate until they discover what each other can do, and that is harder when they share neither a framework nor a security model. Traditional approaches, including Contract Net Protocol and FIPA standards, assumed homogeneous environments and predefined interaction patterns. Those assumptions break down when LLM-powered agents, specialized domain agents, IoT-enabled agents, and cloud-native services from different organizations meet. Their capabilities may also change or depend on context. ACNBP’s authors identify collaboration without those shared assumptions as the central unsolved challenge.

Google introduced A2A in April 2025 to standardize discovery, capability negotiation, and user experience negotiation across these environments. Its design now matters beyond the specification. Google Cloud, AWS Bedrock AgentCore Runtime, and Microsoft Azure AI Foundry have built native A2A support into their infrastructure. ServiceNow, Salesforce, and SAP use it to connect workflows, with Atlassian among the broader launch partners. Capability discovery now has to work in production, beyond exercises in teaching hypothetical agents to introduce themselves.

How the Agent Card makes capability negotiation a read operation rather than a handshake

Before a task begins, the client fetches a JSON metadata document called the Agent Card, published by the remote agent. The card supplies the agent’s identity, capabilities, skills, service endpoint, and authentication requirements. Capability negotiation is a read operation, with no live exchange in which agents bargain over the features they support. The client learns the remote agent’s declared interface before deciding how to interact with it.

The card’s securitySchemes field declares the required authentication schemes, including OAuth 2.0, OpenID Connect, API keys, HTTP auth (Basic/Bearer), or mTLS. It contains requirements, never credentials. A2A-compliant agents publish their cards using the well-known URI pattern defined by RFC 8615, the IETF proposed standard for domain-level metadata. Discovery is consequently a stateless, cacheable HTTP fetch.

That document also supports separate levels of disclosure. A public Agent Card is available to any client for initial discovery, while an extended Agent Card can provide richer capability detail after authentication. The extended card is available only if AgentCard.capabilities.extendedAgentCard is true. This separates what any prospective collaborator can see from what authenticated partners can learn. Agents can stay opaque and share enough to work together while keeping their internal logic and proprietary capabilities to themselves.

How authentication and scoped delegation are layered on top of discovery

Once the client has read the card, authentication follows the requirements it declares. The client reads securitySchemes, acquires credentials out of band, and sends them in protocol-appropriate headers or metadata on every request. A2A neither specifies nor mediates credential issuance, so this process depends on arrangements outside the protocol. Built-in support includes JWT and OIDC authentication, encryption, and fine-grained authorization. None of this is a real-time negotiation between agents over whom to trust.

Authentication is also strictly hop-by-hop. Each leg of a delegation chain authenticates independently, rather than inheriting a verified identity for the original principal. For task coordination, A2A supports asynchronous event streams through WebHooks and gRPC, allowing a delegatee to push status updates to the delegator. These include TASK_STATE_INPUT_REQUIRED and TASK_STATE_WORKING. Such updates communicate progress, but they do not establish the limits of the delegatee’s authority.

Google DeepMind’s intelligent delegation framework makes that distinction clear by treating delegation as a transfer of authority, responsibility, and accountability. Its model also calls for clear roles and boundaries, clarity of intent, and mechanisms for establishing trust. A2A’s transport-layer enforcement covers only part of that model, so the party implementing it must set the scope of access that a delegated token carries. Signed Agent Cards can add cryptographic verification to discovery, but agents do not have to sign them. Even with a signature, the client needs a reason to trust the verification key.

Why optional signing and hop-by-hop identity create structural gaps in the trust model

In Stage 1 (Discovery), the Agent Card serves as the sole trust anchor for subsequent interaction, yet it can be a self-asserted JSON document with no required cryptographic verification. An attacker can therefore publish a fake card and redirect agents through a card forgery attack. This is not necessarily an implementation failing to follow the rules. The rules allow unsigned cards.

Signing narrows that problem but does not close it. The A2A v1.0 specification does not define how the public key used to verify an AgentCard signature is itself trusted. Researchers call this the “JWS Key Trust Model Gap,” a spoofing-category vulnerability affecting confidentiality at Discovery. A signature proves little about the intended agent if the client cannot establish whose key it is checking. Cryptographic verification and trust in the signer are different questions.

Because identity exists at the transport layer and does not propagate across delegation hops, downstream agents and credential providers cannot verify the original principal. A malicious intermediary can silently harvest forwarded credentials, creating the credential harvesting vector identified in multi-hop chains. Scope granularity is another weakness, because a token issued for one action may also give access to resources unrelated to that action. Self-declared agent identities have no global uniqueness enforcement either, making collisions across deployments possible.

These weaknesses come from the architecture. Research on federated trust perimeters finds that existing IAM approaches still struggle with trust between non-human entities that cross organizational boundaries and have no pre-established trust anchors. A2A standardizes the interaction without fully establishing that wider trust perimeter. Closing the gaps calls for deployment architecture and policy that go beyond patching a faulty implementation.

The attack surface that emerges when LLM-based agents process Agent Cards

Agent Cards create another kind of exposure when clients place their contents in an LLM’s reasoning context. In Agent Card Poisoning, a malicious remote agent embeds adversarial instructions in card fields. Without strict boundary enforcement, the model can treat those instructions as commands. The reader can read the JSON but gives the text authority it was never meant to have.

Trustwave SpiderLabs demonstrated a distinct attack on agent selection in 2025. A rogue agent presents an inflated Agent Card whose description manipulates the host agent’s LLM-based selection logic. Persuasive text can then hijack task routing, winning work for the attacker’s agent. The attacker wins the audition without breaking the cryptography.

A2ABreak’s September 2026 findings give more evidence of these risks at the protocol level. Its systematic analysis identifies vulnerabilities exploitable by a specification-compliant adversary without an implementation flaw, and the findings have been reported to A2A project maintainers under the Linux Foundation. A2A specifies metadata structure and authentication declarations, but it does not specify how LLMs should interpret that metadata, how identity persists across hops, or how capability claims are verified. Those are different boundaries, and defending one does not defend the others.

How A2A reached its current governance and specification state, and what remains unresolved

A2A’s institutional development has been rapid since Google launched it as an open standard in April 2025. The competing Agent Communication Protocol (ACP), initiated by IBM Research (BeeAI), merged with A2A by August 2025. Cisco separately led AGNTCY’s Agent Connect Protocol effort, which also merged with A2A by then. These moves brought separate approaches to agent communication under a common standard. These mergers brought the protocols together but left some trust questions open.

The Linux Foundation launched the Agentic AI Foundation (AAIF) in December 2025 to provide neutral, open governance for agentic AI projects including MCP, goose, and AGENTS.md. Google formally transferred A2A to the AAIF on August 20, 2026. That governance context distinguishes the current standard from a Google-owned early draft. It also makes the remaining omissions important to assess against the production specification.

A2A v1.0 does not mandate short-lived tokens, granular scopes, strong customer authentication, explicit consent orchestration, or direct data flow control. Researchers have proposed these controls as necessary within a structured threat model, but the specification leaves them unspecified. Signing remains optional, and the JWS Key Trust Model Gap remains unaddressed. The Agent Card also has no standard schema for details about the host, including OS platforms and resource availability, which limits how it handles device-level heterogeneity. Governance has matured faster than the specification has closed these gaps.

What the A2A vs. MCP distinction clarifies about where A2A's trust model applies

A2A and MCP address different relationships. A2A works horizontally between peer agents that negotiate tasks while keeping their internals opaque. MCP works vertically between a model and tools or data, using a client-server relationship in which the model invokes tools. The distinction is not a ranking of sophistication.

The strongest developer objection to A2A is nevertheless reasonable. Developers who need a straightforward tool connection may get immediate utility from MCP’s developer-first approach without needing a broader agent collaboration model. At the grassroots level, that simplicity is a substantive advantage. It does not, however, answer the requirements of enterprise orchestration across supply chains, financial services, and mobile platforms. In those settings, authentication declarations, scoped delegation, and an audit-ready structure address a different problem.

Tyson Foods and Gordon Food Service piloted collaborative A2A systems and were making plans to bring them to production, while major SaaS platforms already use it in workflows. Connecting a model to a file system through MCP does not require hop-by-hop identity in the way an A2A chain executing a financial workflow does. The Survey of the Web of Agents frames the wider challenge as generation-invariant, with standards bodies, regulators, and commercial payment networks more determinative than protocol design alone. The protocol matters, but so does the infrastructure that makes its promises enforceable.

What organizations operating A2A agents in production need to enforce that the specification leaves to them

For production operators, the first task is to turn optional trust features into explicit policy. That includes deciding whether to require signed Agent Cards and establishing a key trust infrastructure that makes those signatures meaningful. Token scopes also need limits that prevent authority for one task from opening unrelated resources. Organizations must instrument principal identity across delegation hops themselves or accept the credential harvesting risk. These controls supply guarantees that protocol conformance does not.

The agent-behavior monitoring layer must detect and block Agent Card Poisoning and attacks on agent selection at runtime, because A2A provides no mechanism for this. That layer needs to discover every agent running inside the organization, monitor approved AI traffic, detect anomalous behavior and policy violations, enforce rules, and produce complete audit logs. Human-oriented access models do not constrain agents acting on their permissions at machine speed.

The timing of that enforcement matters as much as its coverage. Runtime monitoring that recognizes a TASK_BLOCKED or RESOURCE_WARNING event in context can support intervention before a policy violation completes and record evidence afterward. Researchers’ proposed controls, including short-lived tokens, granular scopes, strong customer authentication, explicit consent orchestration, and direct data flow control, are available to deployers even though v1.0 does not mandate them. ACNBP offers a parallel structured 10-step framework that includes capability attestation, digital signatures, and comprehensive threat mitigation. Organizations need not wait for A2A to require controls they can enforce now, because external governance is structurally necessary to make its interoperable interactions controllable.