A2A Protocol Authentication: Signed Agent Cards, Credentials, and Spend Limits

Short answer: A2A protocol authentication is deliberately thin. An agent declares what credentials it expects in its Agent Card, and callers pass those credentials in ordinary HTTP headers, kept separate from A2A messages themselves. Version 1.0, released April 9, 2026 under Linux Foundation governance, added Signed Agent Cards so a card can be cryptographically verified across an organizational boundary. That answers identity. It does not answer authorization to spend money, because nothing in A2A carries an amount, a budget or a running total. If your agents pay each other, the spend layer is yours to build.

Why authentication and authorization split apart here

Most protocol designers would have bundled these. A2A did not, and the reasoning holds up. The spec treats a remote agent as opaque, a black box that accepts work and returns results without exposing its tools or memory. Under that constraint the protocol can only reason about the envelope, not the contents. It can say who is knocking. It cannot say whether the job they are about to commission is worth 4 cents or 4,000 dollars, because that value lives inside a system the protocol is not allowed to see.

The consequence is practical rather than philosophical. You can be fully compliant with A2A, pass every conformance test, verify every signature, and still have an agent that quietly runs up an invoice nobody approved. Identity and budget are separate controls and A2A only ships one of them.

How does A2A protocol authentication work?

The Agent Card is the whole mechanism. It is a JSON metadata document that acts as an agent's business card: its identity, its service endpoint URL, its A2A capabilities, its skills, and the authentication it requires. A client fetches that card during discovery, reads the declared scheme, and attaches the matching credential to its HTTP requests. Because teams increasingly assemble systems from peers they did not write, discovery often starts from a directory of ready-made agents rather than from a hand-maintained list of endpoints, which makes the card the only thing standing between you and an unknown counterparty.

Two design details matter when you implement this. First, A2A explicitly relies on standard web security practices rather than inventing its own: OAuth tokens and API keys are the normal cases. Second, and this is the part people get wrong, credentials travel in HTTP headers and stay outside the A2A message payload. Your authentication middleware never has to parse JSON-RPC to decide whether to let a request through, and rotating a secret does not touch protocol-level code.

What are Signed Agent Cards?

Before version 1.0 an Agent Card was a JSON file you fetched and believed. That is fine inside one company and unacceptable between two. Signed Agent Cards, one of the four headline additions in v1.0, let the publisher cryptographically sign the card so a client can verify the identity and capability claims instead of trusting them on sight. The v1.0 release also brought multi-protocol transports, multi-tenancy and a more web-aligned architecture, and it arrived with more than 150 organizations participating and production deployments inside Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime.

If you are going to allow an outside agent to commission paid work, the signed card is the artifact your records should pin to. Store the verified key identifier alongside every task you accepted from that agent, because when someone asks in November which counterparty authorized a charge in August, a signature you verified and logged is a real answer and a user agent string is not.

What A2A authentication proves and what it leaves open

Where money enters, and why it does not help with limits

Payment reaches A2A through the extension mechanism. An agent declares extensions in its card as AgentExtension objects inside AgentCapabilities, each carrying a uri, a description, a required flag and optional params. A client activates one by sending an A2A-Extensions header listing the URIs it wants, and the agent echoes back what it enabled. Extension data then rides in the request metadata field under namespaced keys.

The two extensions that matter for money are a2a-x402, maintained by Google Agentic Commerce under Apache 2.0 and still at specification v0.1, which defines the payment-required, payment-submitted and payment-completed states for on-chain settlement; and AP2, announced September 16, 2025 with more than 60 partners and donated to the FIDO Alliance on April 28, 2026, which handles signed mandates on card rails. Both work. Neither remembers. Extensions negotiate per request, so a2a-x402 sees one payment at a time and has no idea whether this is the first charge today or the four hundredth. That is the gap, stated as precisely as I can put it. For the full picture of how these layers stack, see our breakdown of the A2A protocol and agent to agent payments.

Does A2A protocol authentication support OAuth?

Yes. A2A does not define a bespoke auth scheme, it defers to existing web standards, and OAuth 2.0 bearer tokens are the common production choice alongside API keys. The agent states its requirement in the card and the client complies. Because the credential is a header, everything you already run for API security keeps working: token introspection, short expiries, rotation, per-client scopes and rate limits at the edge. The upside of a thin spec is that you are not asked to abandon infrastructure that works.

How do you revoke one agent without breaking the rest?

Issue credentials per agent, never per fleet. This sounds obvious and is skipped constantly, usually because the first integration used one shared service token and nobody went back. The problem shows up the day one agent misbehaves: with a shared credential your only options are tolerate it or take everything down. With per-agent credentials, revocation is a single delete.

Extend the same logic to the payment instrument. A single company card behind every agent has exactly the failure mode a shared token has. Scoped virtual cards give each agent its own instrument with its own ceiling, so revoking one agent's ability to spend is independent of the others, and a runaway loop is capped by the card rather than by how fast someone notices.

What to build on your side of the line

Assume A2A handles identity and transport well, and that everything cumulative is yours. Four controls cover most of it:

• A per-agent ledger. Every task, its verified caller, and what it cost, in one place that outlives the task lifecycle. A2A gives you task history with no amounts, so you are joining protocol records to payment records yourself.
• Budgets that are checked before signing, not after settling. The check has to happen while you can still refuse. Once a payment is submitted, on any rail, you are reconciling rather than controlling.
• An approval threshold. Pick a number, route anything above it to a person, and log the decision. See approval workflows for how this behaves when an agent is mid-task and waiting.
• Reconciliation that finance will accept. Tasks can stay open for hours across polling, SSE streams and webhook callbacks, so a charge and the work that caused it often land in different reporting periods. An audit trail built for month-end close is what makes that survivable.

None of this is a criticism of A2A. It is an interoperability standard that did its job and stayed small, which is precisely why it got to 150 organizations and version 1.0 in a year. But a protocol that was scoped not to see inside your agents was never going to tell you what they are spending. If you are running agents that commission paid work from each other, agent-to-agent payments is the shape of the problem, and per-agent spend controls are the part you cannot get from the spec.