Agent-to-agent authentication: what each pattern proves

What is agent-to-agent authentication?

Agent-to-agent authentication is the process by which one software agent establishes the identity of another before exchanging data or delegating work. The glossary entry for agent-to-agent authentication gives a short definition. In practice it happens in multi-agent systems inside one company, in cross-company workflows such as procurement and travel booking, and in agentic commerce, where a buying agent and a selling agent may never have met.

The problem is harder than service-to-service authentication in one important way: agents often act across organizational boundaries with no prior relationship, no shared identity provider and no pre-exchanged credentials. The receiving side needs an identity it can check without first becoming a customer of the caller's platform.

What exactly is being authenticated: the connection, the agent or the operator?

Three different subjects hide behind the phrase authenticate the agent. Keeping them apart is the single most useful habit when comparing mechanisms.

• The connection or request: this TLS session or this HTTP message came from a holder of a particular credential or key, now.
• The agent: the caller is a specific, persistent agent identity, the same one it was yesterday and on another platform.
• The operator: a specific person or organization runs this agent and answers for it.

API keys and OAuth client credentials

The most common pattern today is also the simplest. The receiving service issues an API key or registers an OAuth 2.0 client, and the calling agent presents the key or obtains an access token through the client credentials grant defined in RFC 6749. The receiver then knows the request comes from a registered client.

This works well inside one ecosystem. Its limits appear across ecosystems. The credential is issued per receiver, so an agent that talks to fifty services holds fifty credentials and has fifty identities. A bearer token or API key authenticates whoever holds it, so a leaked credential is a working identity. And the client registered with the authorization server is often a platform, not the specific agent or the operator accountable for it.

For delegation, RFC 8693 OAuth 2.0 Token Exchange defines an act claim that records which party is acting on behalf of another, which is one of the more mature ways to represent a delegation hop inside an OAuth deployment.

Mutual TLS

Mutual TLS has both sides of a connection present certificates, so the server authenticates the client at the transport layer. RFC 8705 extends this to OAuth, allowing clients to authenticate with certificates and binding access tokens to the client certificate so a stolen token cannot be replayed by someone else.

mTLS gives strong proof that a connection comes from the holder of a private key. What identity that proves depends entirely on what the certificate names and who issued it. It works best where both parties already share a PKI, such as within an enterprise or a closed partner network, and is harder to use between agents that have never met. It authenticates the connection; any link from the certificate to a specific agent or operator is a policy decision of the issuing CA.

HTTP Message Signatures and Web Bot Auth

RFC 9421, HTTP Message Signatures, defines how to sign and verify components of an HTTP message, so authentication travels with the request rather than with the connection. That makes it usable through proxies and across hops where TLS terminates.

Web Bot Auth builds on it for automated traffic. Under the IETF webbotauth working group's draft protocol, a client signs requests with a key, names where its keys are published in a Signature-Agent header, and publishes a key directory at a well-known URI on its own domain. Cloudflare's description uses Ed25519 keys and signatures with a validity window. The draft is a working-group Internet-Draft, not a finished standard.

This is request-level authentication, which is exactly what the simpler patterns lack. What it identifies is the service that controls the signing key and its domain. It does not, by itself, carry a signed declaration of which agent is acting, who operates it or what it says it is for.

A2A Agent Cards

The Agent2Agent protocol has each agent publish an Agent Card, a JSON document describing its skills, endpoints and the security schemes a caller must use, usually at /.well-known/agent-card.json on its domain. The specification lists API key, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS schemes. Cards may be signed using JWS over RFC 8785 canonical JSON, so a caller can check that a card was not altered and came from the claimed provider.

An Agent Card is discovery and negotiation metadata. It tells a caller how to authenticate, and a signed card tells it the card is intact. The authentication itself is performed by whichever scheme the card names. See agent card and the A2A comparison for how an AgenID identifier can sit alongside a card.

Decentralized Identifiers

Decentralized Identifiers, a W3C Recommendation since 2022, are URIs that resolve to a DID document listing keys and service endpoints. Proving control of a key in the document authenticates the controller of that DID, and verifiable credentials can then attach claims to it.

DIDs are a general framework rather than one system. What a DID proves depends on its method, how the document is anchored and who controls updates. A DID alone says nothing about which organization is accountable for an agent; that comes from credentials issued about it. The decentralized identifier entry and the DID comparison cover the relationship to AgenID.

Where does AgenID fit, and what is its boundary today?

AgenID authenticates an object, not a request. Protocol v1.1.1 gives an agent a permanent identifier and binds it to a manifest its operator signed with an Ed25519 key. Any relying party can resolve the identifier, recompute the manifest digest, verify the signature and fetch the operator key from both the registry and the operator's own domain. That answers which agent this is and which operator key declared it, independently of AgenID's registry. The steps are in how to verify an AI agent.

It does not answer whether the live request in front of you came from that agent. AgenID's own security gap analysis records this as GAP-C1: nothing binds a live HTTP request to a registered agent identity, and there is no proof-of-possession, request signing, nonce or challenge in the protocol. A signed ManifestProof is public; anyone who has seen it can present it. Replay is bounded only by the proof's validity window (GAP-C2).

A challenge-response step, in which the relying party sends a fresh nonce and the agent signs it with its operator key, is a natural way to close that gap. It is a proposed pattern and is not specified in v1.1.1. Some AgenID scenario illustrations show such a challenge to explain the idea; it should be read as the model, not as a deployed feature. Until the protocol defines one, combine AgenID with a request-level mechanism such as HTTP Message Signatures or mTLS, and check that the key or domain on the request matches the operator identity you verified.

The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2_DOMAIN_VERIFIED and every level above it require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.

How do delegation chains and audit work across agents?

Delegation is where authentication gets hard. A user's assistant hands a trip to a travel agent, which hands a seat hold to an airline agent and settlement to a payment agent. Each hop is an authentication decision and an authorization decision, and afterwards someone may need to reconstruct who did what. The agent delegation scenario and the agent delegation entry walk through it.

A persistent, resolvable identity at every hop makes the chain attributable: each participant is named by an identifier anyone can re-check, so the record does not depend on one party's logs. What an identity alone does not express is scope: how far a delegation reaches, what each agent may do and when that authority ends.

Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so the permission decision stays with the relying party and the operator. A v1.2 authorization layer exists only as a draft in development. The draft adds a principal key role, a signed grant naming scopes and a validity window, and a signed revocation, all verifiable offline. It is not normative and nothing in the deployed registry stores or serves grants.

How should you combine these patterns?

No single mechanism covers the connection, the agent and the operator at once. A layered approach uses each for what it proves.

• Transport and request: use TLS everywhere, and add mTLS or HTTP Message Signatures so each request is tied to a key the caller holds.
• Agent identity: resolve and re-verify a persistent identifier such as an AgenID, and record the envelope you checked.
• Binding: check that the request-level key or domain matches the operator identity you verified, for example the manifest's operator_domain.
• Assurance: read the verification level for what it is. Today that is L1_REGISTERED at most, a self-declaration.
• Permission: apply your own policy, scoped to the verified identity, and keep it separate from authentication. What the agent is allowed to do is your decision.
• Audit: log the identifier, the envelope, the request signature and the decision, so the chain can be reconstructed later.