Agent-to-Agent Authentication Guide: Proving Identity Between AI Agents

When one AI agent calls another, the receiving agent has to decide who is calling, on whose behalf and with what rights, and a static shared API key answers none of those questions well. Agent-to-agent traffic is service-to-service traffic with two extra problems: requests often carry a human user's authority through several hops, and agents discover each other dynamically from published descriptions rather than fixed configuration. This guide covers how the Agent2Agent (A2A) protocol handles authentication, how to choose between API keys, OAuth client credentials, mutual TLS, DPoP and SPIFFE identities, how to carry user context safely across a chain with token exchange, and how to verify Agent Cards and callbacks. It is for architects, identity engineers and platform teams building or connecting backend agents. Broader multi-agent risks such as trust boundaries and orchestration are covered in the Multi-Agent and A2A Security Guide; this page stays on proving identity.

Key takeaways

• A2A does not invent its own identity layer. The specification puts identity at the transport and HTTP layer: the server declares schemes in its Agent Card, the client gets credentials out of band, and the server must authenticate every request.
• Prefer proof of possession over bearer secrets. RFC 9700 recommends sender-constrained tokens (mTLS under RFC 8705 or DPoP under RFC 9449) and asymmetric client authentication, so a stolen token cannot simply be replayed.
• Two identities usually travel together. The calling agent's workload identity and the user it acts for should be separate, verifiable claims, for example an mTLS or SPIFFE identity plus an exchanged token with an act claim.
• Audience restriction stops token forwarding. A token minted for agent B must be rejected by agent C. Mint one token per hop with a single audience instead of passing the original token down the chain.
• Agent Cards and webhooks are attack surface. Verify JWS signatures on Agent Cards, require authentication for the extended card, and authenticate and SSRF-check push notification callbacks.

What agent-to-agent authentication has to prove

A single call between agents raises four separate questions. Mixing them up is the root of most designs that look secure but are not.

Authentication only establishes identity. What the caller may do is a separate decision the receiving agent must make on every request, based on the authenticated identity, the requested skill and the data involved. See the AI Agent Authorisation Guide.

How A2A handles authentication

The A2A specification (latest released version 1.0.0) treats agents as standard enterprise applications. The enterprise guidance states that A2A payloads such as JSON-RPC messages do not carry user or client identity; identity is established at the transport or HTTP layer.

• Transport: production deployments must use encrypted communication (HTTPS for HTTP bindings, TLS for gRPC), with TLS 1.3 or later recommended in the specification. Clients should validate the server's TLS certificate against trusted CAs.
• Discovery of requirements: the client reads the server's securitySchemes and securityRequirements from the Agent Card, normally served at https://{server_domain}/.well-known/agent-card.json.
• Out-of-band credentials: the client obtains credentials (for example an OAuth token) through a process outside A2A and sends them in protocol headers on every request, such as Authorization: Bearer.
• Server duties: the server must authenticate every incoming request. The enterprise guidance says to return 401 Unauthorized with a WWW-Authenticate header for missing or invalid credentials and 403 Forbidden when valid credentials lack permission.
• Authorisation: implementation specific, and may consider the requested skill, the actions attempted, data access policies and OAuth scopes. The guidance suggests scopes that grant some skills and not others.
• Versioning: clients send the A2A-Version header; an empty value is interpreted as 0.3. Pin the version you have reviewed rather than allowing silent fallback.

Choosing a credential for the calling agent

Decision guidance

• Inside one platform you control: use mTLS with SPIFFE X.509-SVIDs for agent identity. An X.509-SVID must contain exactly one URI SAN, and validators must reject certificates with more than one, so the authorisation decision keys on a single spiffe://trust-domain/path value. See the SPIFFE and SPIRE Guide and the mTLS Guide.
• Across organisations: use OAuth at the receiving organisation's authorisation server with asymmetric client authentication (private_key_jwt or tls_client_auth) and sender-constrained access tokens. RFC 9700 names mTLS and DPoP as the two sender-constraining methods.
• When TLS terminates at a gateway: certificate binding is lost at the proxy unless the gateway forwards and the backend trusts the client certificate. DPoP survives this because the proof travels in the DPoP header.
• When the caller acts for a user: add token exchange on top of whichever workload credential you choose; do not try to encode the user in the workload credential.
• Small versus large organisations: a small team with a few agents can run OAuth client credentials with private_key_jwt, tokens of minutes not hours, and a gateway that checks audience. A large estate should invest in a workload identity platform (SPIFFE or cloud-native workload identity) so no agent holds a long-lived secret. See the Cloud Workload Identity Guide and the Machine-to-Machine OAuth (Client Credentials) Guide.

Proof-of-possession details that matter

• RFC 8705: with tls_client_auth the server validates the certificate chain and matches one registered subject value, such as tls_client_auth_san_uri, which can hold a SPIFFE ID. With self_signed_tls_client_auth the client registers certificates through jwks or jwks_uri. Servers advertise tls_client_certificate_bound_access_tokens; a resource server that sees a certificate mismatch returns 401 with invalid_token.
• RFC 9449: each request carries a fresh proof JWT with typ dpop+jwt, an asymmetric alg, and claims jti, htm, htu, iat, plus ath (hash of the access token) when a token is presented. Servers can issue a DPoP-Nonce to limit pre-generated proofs, and must reject a DPoP-bound token presented as a plain Bearer token. DPoP does not protect the message body and cannot stop code running inside the client.
• JWT-SVID: aud and exp are mandatory and tokens without them must be rejected. The specification warns that a token with audiences Bob and Chuck lets Chuck impersonate the caller to Bob, so single-audience tokens are strongly recommended.

Carrying user context across agent chains

The riskiest pattern in multi-agent systems is forwarding the user's original access token from agent to agent. Every agent that sees it can use it anywhere its audience allows, and the final service cannot tell which agent made the call.

1. Exchange at each hop: the calling agent sends the incoming token as subject_token and its own credential as actor_token to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, naming the next agent in audience or resource.
2. Record the chain: the issued token's act claim identifies the current actor; nested act claims record earlier actors. RFC 8693 says only top-level claims and the current actor should be used for access control, with earlier actors informational. Log the whole chain anyway.
3. Pre-authorise delegation: use the may_act claim or authorisation server policy so only named agents may act for a subject.
4. Narrow every hop: request fewer scopes than the incoming token held, and use authorization_details (RFC 9396) where the action needs fine-grained limits.
5. Keep lifetimes short: exchanged tokens should live for the task, not the session.

See the OAuth Token Exchange and Delegation Guide.

In-task authorisation in A2A

• TASK_STATE_AUTH_REQUIRED: an agent that needs extra authorisation mid-task (an OAuth token for another API, or human approval) moves the task to this state, and the client can fulfil, negotiate or reject the request, or pass it up its own chain.
• Out of band by default: the specification says agents should receive these credentials out of band over a secure channel. If in-band exchange is negotiated, credentials should be bound to the originating agent and encrypted so only that agent can read them, because in-band credentials are otherwise exposed to every agent in the chain.
• The state is not a grant: agents must not treat the state transition as authorisation, and a credential obtained this way must not be assumed to authorise later messages on the task unless the implementation defines it.

Pair high-impact steps with a human approval. See the Human-in-the-Loop for AI Agents Guide.

Verifying Agent Cards, extended cards and callbacks

• Signed Agent Cards: cards may be signed with JWS (RFC 7515) after canonicalisation with JCS (RFC 8785), excluding the signatures field. The protected header must include alg, typ and kid, and may include jku. Clients should verify at least one signature before trusting a card, fetch keys over HTTPS, and must not use expired or revoked keys. Pin trusted keys per provider rather than trusting any jku the card names.
• Treat card content as untrusted input: skill descriptions flow into a calling model's context, so a tampered or malicious card is an indirect prompt injection route (ATLAS AML.T0051.001). See the Prompt Injection Guide.
• Extended Agent Card: the authenticated card (available when capabilities.extendedAgentCard is true) must require authentication using a scheme from the public card. Do not put anything in the public card you would not publish.
• Push notifications: the agent must include authentication credentials in webhook requests and should validate webhook URLs against SSRF by rejecting 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, localhost and link-local addresses. The receiving client must validate webhook authenticity and should check the task ID matches a task it created. Use a unique, single-purpose token per push configuration and rotate it.

Implementation roadmap

1. Inventory (weeks 1 to 2): list every agent endpoint, its Agent Card, declared schemes, credential type, token lifetime and who issues it. Flag API keys, long-lived secrets and forwarded user tokens.
2. Establish workload identity (weeks 2 to 6): issue SPIFFE IDs or cloud workload identities to agents, with a path convention such as spiffe://example.org/agents/billing. Start mTLS in permissive mode and log which callers would fail.
3. Move to OAuth with constrained tokens: register each agent as a client with private_key_jwt or tls_client_auth, enable certificate-bound or DPoP-bound tokens, and set audience per receiving agent. Run resource servers in dual mode (accept old and new) for a fixed window.
4. Add delegation: introduce token exchange for user-context calls, enforce may_act policy and reduce scopes per hop.
5. Enforce: switch mTLS to strict, reject bearer use of bound tokens, retire API keys. Roll back per agent by re-enabling dual mode at the gateway, not by reissuing long-lived secrets.
6. Sign and pin cards: sign Agent Cards in the release pipeline and configure clients to verify against pinned keys.

Detection and measurement

• Log on both sides: the A2A enterprise guidance recommends logging task IDs, session IDs, correlation IDs and trace context, and propagating W3C Trace Context with OpenTelemetry. Add the authenticated agent identity (SPIFFE ID or client ID), the subject, the full act chain and the token's jti.
• Alert on: 401 and 403 spikes per caller; the same token jti or DPoP proof jti seen twice; tokens presented to the wrong audience; a client certificate or key used from a new network location; Agent Card signature failures; webhook registrations pointing at internal or unexpected hosts.
• Watch the authorisation server: token exchange requests where may_act policy was denied, and new client registrations.

See the AI Agent Observability and Incident Response Guide.

Framework mapping

OWASP LLM06:2025 Excessive Agency lists a malicious or compromised peer agent in multi-agent systems as a trigger, which is why receiving agents must authorise each request rather than trusting the caller. In CIS Controls v8.1 this work sits under Control 5 (Account Management) and Control 6 (Access Control Management); in ISO/IEC 27001:2022 Annex A under A.5.17 (Authentication information), A.8.5 (Secure authentication) and A.8.15 (Logging).

Common failure patterns

• Forwarding the user's token: the orchestrator passes the user's access token to every sub-agent. Any compromised sub-agent can call any service in that token's audience as the user.
• One shared key across agents: every agent in a mesh uses the same API key or client secret, so logs cannot attribute calls and revoking one agent means revoking all of them.
• Multi-audience tokens: a token valid for several agents lets any recipient replay it to the others, exactly the scenario the JWT-SVID specification warns about.
• Trusting the Agent Card URL alone: clients accept any card served over HTTPS, or follow a jku to an attacker-controlled key set, instead of pinning provider keys.
• Treating TASK_STATE_AUTH_REQUIRED as consent: an agent proceeds with a destructive action because the client "answered", without checking what was actually authorised.
• Unauthenticated callbacks: push notification endpoints that accept any POST, or agents that will call internal URLs supplied by a client.

Lessons from incidents

The Salesloft Drift breach was not an agent-to-agent attack, but it shows what bearer tokens held by an integration mean in practice: the attacker took OAuth tokens from the vendor's environment and called customers' Salesforce APIs as the trusted app, so customer MFA and SSO were never tested. Agent meshes concentrate tokens in the same way. Sender-constrained tokens, short lifetimes, audience restriction and network-bound policies are the controls that would have made those stolen tokens far less useful. See the OAuth Token Theft Incident Playbook.

Practitioner checklist

• Inventory every agent endpoint, its declared securitySchemes and the credential each caller uses.
• Give each agent its own workload identity (SPIFFE ID or cloud workload identity) and its own OAuth client.
• Use asymmetric client authentication (private_key_jwt or tls_client_auth) instead of client secrets.
• Issue sender-constrained tokens (mTLS-bound or DPoP) and reject bound tokens presented as Bearer.
• Restrict every token to a single receiving agent's audience and keep lifetimes to minutes.
• Use token exchange with act and may_act for user-context calls; never forward the original token.
• Authenticate every A2A request and authorise per skill and per action, returning 401 or 403 correctly.
• Sign Agent Cards in the release pipeline and verify them against pinned keys in clients.
• Authenticate push notifications both ways and block private, loopback and link-local webhook targets.
• Log agent identity, subject, act chain and trace context, and alert on replay and wrong-audience events.

Standards and references

• A2A Project: Agent2Agent (A2A) Protocol Specification
• A2A Project: Enterprise Implementation of A2A
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• SPIFFE: SPIFFE ID, X509-SVID and JWT-SVID standards
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Multi-Agent and A2A Security Guide · NHI Authentication Guide · Securing Agent Frameworks Guide · Credential Vaulting for AI Agents Guide · AI Agent Tool and Plugin Security Guide