Signed Agent Cards vs mTLS: what each one proves

A signed Agent Card is for proving that an A2A card’s content is intact and was produced by whoever holds a particular signing key, wherever the card has travelled. Mutual TLS (mTLS) is for proving, during the TLS handshake, which certificate holder is at each end of a connection, so that client and server are both authenticated before the first request.

They protect different things. A card signature protects a document, and the protection stays with the document when it is cached or relayed. mTLS protects a live connection, and the protection ends when the connection does. Most of the confusion between them comes from asking one to answer the other’s question.

Status as of September 26, 2026. Card signing is defined in section 8.4 of the A2A specification, version 1.0 (a Linux Foundation project). It is optional: cards MAY be signed, and clients SHOULD verify at least one signature before trusting a card. Mutual TLS is client certificate authentication in TLS, specified for TLS 1.3 in RFC 8446 (August 2018). A2A lists it as one of five security schemes an agent can require, and RFC 8705 (2020) defines how OAuth 2.0 uses it.

What a signed Agent Card proves

The publisher removes the signatures field and default-valued fields from the card, canonicalizes the rest with RFC 8785, and signs the bytes as a JSON Web Signature (RFC 7515). The protected header must carry alg and kid, should set typ to JOSE, and may carry jku, a URL for the JSON Web Key Set holding the public key. The result goes into the card’s signatures array. Illustrative fragment, with a placeholder signature:

{
  "name": "Example Freight Quotes",
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJjYXJkLWtleS0yMDI2LTA5Iiwiamt1IjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9rZXlzL2FnZW50LWNhcmQtandrcy5qc29uIn0",
      "signature": "PLACEHOLDER_BASE64URL_ES256_SIGNATURE"
    }
  ]
}

A client rebuilds the same bytes from the card it received and checks the signature with the key named by kid, fetched from jku or from a trusted key store. The specification says keys should come over HTTPS and that expired or revoked keys must not be used.

A valid signature proves two things: the signed fields have not changed, and the holder of that key produced them. Endpoints in supportedInterfaces, skills and security requirements are all covered. What it binds the card to depends on where you got the key. A key from a JWK Set on the provider’s own domain ties the card to whoever controls that domain. A key from an unknown URL ties it to nobody in particular. Signed Agent Cards walks through signing and verification in full.

What mutual TLS proves

In ordinary TLS, only the server presents a certificate. In mutual TLS, the server also sends a CertificateRequest, and the client answers with its own certificate and a CertificateVerify message: a signature over the handshake that proves it holds the certificate’s private key. The server then decides whether to accept that certificate, either by validating its chain to a certificate authority it trusts (RFC 5280 path validation) or by matching a certificate registered in advance, which RFC 8705 calls the self-signed method.

After the handshake, both ends know who the other is, and every byte on that connection is encrypted and integrity-protected. RFC 8705 adds certificate-bound access tokens: an OAuth token that is only valid when presented over a connection using the matching client certificate, so a stolen token alone is useless.

In A2A, an agent declares mTLS in its card. Illustrative fragment:

{
  "securitySchemes": {
    "partnerMtls": {
      "mtlsSecurityScheme": { "description": "Client certificates issued to contracted shippers" }
    }
  },
  "securityRequirements": [{ "schemes": { "partnerMtls": { "list": [] } } }]
}

As with every A2A scheme, the client obtains its credential, here a client certificate, out of band.

Side by side

	Signed Agent Card	Mutual TLS
Purpose	Prove a card’s content is intact and came from a key holder	Authenticate both ends of a connection and protect the traffic
Layer	Application data: a JWS over a JSON document	Transport: the TLS handshake
Who talks to whom	A publisher signs once; any client, registry or cache verifies	One client and one server, per connection
Transport	Independent of transport; survives caching and relaying	Tied to a TLS connection; ends at the TLS terminator
Discovery	Public key via kid plus jku, or a trusted key store	Certificates exchanged in the handshake; trust anchors configured in advance
Auth	Authenticates the card’s publisher key; says nothing about requests	Authenticates the client certificate and the server certificate
State	Static; re-verified on each fetch or cache refresh	Per connection; nothing remains afterwards
Governance and status	A2A 1.0, section 8.4; optional	TLS 1.3 (RFC 8446); OAuth binding (RFC 8705); one of A2A’s five schemes

What each one answers

Question	Signed Agent Card	Mutual TLS
Was this card changed after the publisher produced it?	Yes, it detects changes	No; it only protects the card during one transfer
Is the server I’m connected to the host in the URL?	No; ordinary server-side TLS answers this	Yes, through the server certificate
Which client is calling me?	No; clients do not present cards	Yes, through the client certificate
Can a registry pass the card along and keep it verifiable?	Yes	Not applicable
Is the organization behind it trustworthy?	No	No

When to use each

Sign your Agent Card when your card will be read anywhere other than straight from your own domain: registries, directories, partner catalogs, or client caches. Signing also helps if a web server or CDN is compromised and rewrites the card, provided clients get the verification key from somewhere the attacker does not control, such as a trusted key store.

Require mutual TLS when you know your callers in advance, such as contracted partners, internal systems or regulated counterparties, and you can issue or register their certificates. It authenticates the client before any application code runs.

Using both

They fit together as a chain of evidence. Illustrative flow:

1. The provider publishes its card signing key in a JWK Set on its own domain and signs its Agent Card, which declares an mTLS requirement.
2. A client finds the card, perhaps through a registry, and verifies the signature with the provider’s key.
3. The client connects to the endpoint listed in the verified card, checks the server certificate against that host, and presents its own client certificate.
4. The server validates the client certificate, maps it to a known partner, and applies its own authorization policy.
5. If the agent also uses OAuth, tokens can be bound to the client certificate under RFC 8705.

The signature tells the client which endpoint and requirements the provider meant. TLS tells it that it reached that endpoint. The client certificate tells the server who is calling.

Common misconceptions

“mTLS makes card signatures unnecessary.” TLS protects the card only while it moves from your server over one connection. Once a registry or cache holds it, only a signature lets a reader detect changes.

“A signed card authenticates the agent calling me.” A card describes the server. In A2A, clients authenticate with the schemes the server’s card declares, and mTLS is one of them.

“A valid signature or certificate means the counterpart is trustworthy.” A signature proves control of a key. A certificate proves whatever its issuer checked before issuing it. Neither says whether the business is reputable or whether the agent is authorized to do what it asks.

“The application automatically knows the client certificate.” Only the TLS endpoint does. If a load balancer or proxy terminates TLS, the application learns the client identity only if that component passes it on in a way the application can trust.