Agent-to-Agent Protocol (A2A)

The Agent-to-Agent Protocol (A2A) standardizes how autonomous agents discover one another, describe their capabilities, and delegate tasks between themselves, addressing the coordination problem that begins where agent-to-tool protocols such as Model Context Protocol end. Where MCP answers how one agent reaches a tool, A2A answers how one agent establishes that another agent is who it claims to be and is authorized to receive a delegated task — a question that becomes pressing as soon as agents operated by different teams, or different organizations, participate in the same workflow. The protocol is governed by the Linux Foundation and reached version 1.0.0 in March 2026.

Identity at Discovery Time

The Agent Card is the one identity mechanism A2A contributes that did not exist before it: discoverable JSON metadata publishing an agent's capabilities, identity requirements, and supported authentication schemes. Agent Cards are what make dynamic discovery possible, and they are also the point at which trust is established or misplaced, because an agent that discovers a peer at runtime has no prior relationship to fall back on.

Cards support signature verification using JWS, so a card can be cryptographically bound to its issuer and verified before any task is delegated. This turns discovery from an act of faith into a verifiable assertion, and it is the property that distinguishes A2A from ad hoc agent integration: an agent can establish what it is dealing with prior to granting anything. Cards remain self-asserted as to capability — a signature proves origin, not competence or honesty — so signature verification is necessary rather than sufficient. Treated as an identity artefact, a signed Agent Card is closer to a self-issued credential than to an authenticated identity: it answers "did this description come from the party it names" and nothing further. Turning that into standing rather than origin requires anchoring the signing key in something accountable, which across organizational boundaries is what OpenID Federation trust chains and trust marks are built to provide.

Authentication Is Borrowed, Not Defined

A2A defines no authentication scheme of its own. It declares which existing ones an agent will accept — OAuth 2.0, OpenID Connect, mTLS, with the flows that presuppose a user at the keyboard excluded — and leaves their semantics untouched. This is the right design decision, and it has a consequence worth stating plainly: almost nothing about how an A2A deployment authenticates is an A2A question. Token issuance, audience restriction, and revocation behaviour remain whatever the identity provider already does, so the properties an organization wants from inter-agent calls have to be configured there rather than in the protocol. Reviewing an A2A deployment means reviewing the authorization server behind it.

The same deferral applies one level up. Authorization scopes are expected to reflect operational context and data sensitivity rather than agent identity alone, and the user context behind a delegated task travels through the mechanisms described in OAuth Token Exchange and Identity Chaining. A2A establishes that agent B may accept work from agent A; it does not establish on whose behalf that work is ultimately being done, and does not attempt to. The identity chain is assembled underneath it, which is why an A2A deployment without token exchange has agents that authenticate to each other correctly while the human origin of a task is lost at the first hop.

Enterprise Deployment

Enterprise A2A deployments typically route inter-agent traffic through API management infrastructure, which provides a single place to enforce policy, apply throttling, collect telemetry, and catalogue which agents may address which others across organizational boundaries. This mirrors how organizations already govern external API traffic and has the practical benefit that agent-to-agent calls become visible to existing monitoring rather than forming a parallel, unobserved network. That visibility is what Identity Threat Detection & Response needs to work on inter-agent activity at all: delegation between agents that each hold valid credentials produces no authorization violation to alert on, so anomalous delegation patterns are only detectable against a behavioural baseline built from traffic something actually observes.

The discovery layer that Agent Cards imply also needs a source of truth. In practice this is supplied by an AI agent registry, which holds the authoritative inventory that cards are published from and validated against — without one, signed cards prove origin but nothing about whether the agent is sanctioned.

Summary

A2A is a genuine standard rather than a proposal, with Linux Foundation governance and a stable release behind it. Its identity contribution is narrow by design: verifiable trust establishment at discovery time, with authentication, delegation context, and inventory all deferred to machinery that already exists. That narrowness is a reason to evaluate it calmly rather than a reason to dismiss it, because the deferral only works where the machinery is actually in place — signed cards, token exchange, and a registry are three separate prerequisites, and a deployment that has the first without the other two has verified who it is talking to and nothing else.

It is also solving a problem most organizations do not yet have: multi-agent coordination across trust boundaries presupposes multiple independently operated agents. The reasonable posture is to require signed Agent Cards and registry-backed discovery from the outset in any deployment that does involve inter-agent delegation, and to treat A2A traffic as external API traffic for policy and monitoring purposes, while recognizing that agent-to-tool authorization is the more urgent problem for most current deployments.