Securing A2A Protocol Communication: Mutual TLS and Signed Agent Cards

An Agent Card tells a receiving agent what another agent claims to be able to do and where to reach it. Nothing in the base A2A spec forces that card to be cryptographically tied to the agent that issued it, and nothing forces the transport carrying task exchanges to authenticate both sides of the connection. In a single-team deployment where every agent runs on infrastructure you control, that gap is easy to overlook, because network-level trust does most of the work implicitly. It stops being implicit the moment a second team's agent, or a third-party vendor's agent, needs to talk to yours. At that point an unauthenticated or one-way-authenticated connection creates two concrete risks: agent impersonation, where something other than the real agent answers at the expected endpoint or publishes a lookalike Agent Card claiming capabilities it does not have, and replay, where a captured task request or response gets resent later without the receiving agent having any way to tell it is not a fresh, legitimate exchange. Neither risk is hypothetical once you have agents from different trust boundaries interacting; both are exactly what identity and transport security exist to close, and closing them is left entirely to the implementer.

The controls in this guide assume two pieces of infrastructure are either already in place or are things you are prepared to stand up. Get these settled before writing any agent-side code.

Every agent instance needs its own verifiable identity before anything else in this guide is possible. You have two realistic starting points: stand up a dedicated root and intermediate CA for agent identities, or extend an existing SPIFFE trust domain if your organization already runs SPIRE for service-to-service identity elsewhere.

With a root in place, the next step is getting a certificate onto every running agent instance, kept fresh automatically rather than issued once and left alone.

A certificate authenticates the transport connection. It does not, on its own, protect the Agent Card document itself, which is often fetched and cached separately from any given connection. Signing the card closes that gap by letting a receiving agent verify the capability manifest it is relying on has not been altered since the issuing agent published it.

With per-instance certificates issued and Agent Cards signed, the remaining piece is making sure the actual A2A connection itself authenticates both sides, not just the server the way ordinary TLS does by default.

Short-lived certificates only work as a security control if rotation is fully automated and monitored. A manual or fragile rotation process turns your short validity window into a recurring outage risk instead of a security benefit.

Configuration that looks correct on paper is not the same as configuration that actually behaves correctly under a live handshake. Run each of these checks before treating the deployment as done.

These are the specific ways this setup goes wrong once it is running against real traffic, not hypothetical edge cases.

None of this is free, and the honest comparison is not short-lived certificates against nothing, it is short-lived certificates against a long-lived shared secret, which is what most ungoverned A2A deployments default to in practice. Issuing and rotating a certificate per agent instance at fleet scale adds real operational load: automation has to exist for issuance, rotation, and revocation, monitoring has to catch rotation failures before they cause outages, and clock synchronization becomes a dependency your team now has to actively manage rather than ignore. A long-lived shared secret avoids essentially all of that overhead in the short term. It also has no way to distinguish one agent instance from another holding the same secret, cannot expire itself on a schedule that limits exposure, and turns a single leak, from a log file, a config repository, or a compromised host, into full impersonation of every agent that shares it, with no revocation path short of rotating the secret everywhere at once and hoping nothing was missed. The operational cost of PKI-backed identity at scale is real and worth budgeting for honestly rather than underselling. The blast radius of the shared-secret alternative, once agents cross team or vendor boundaries, is the larger and less controllable risk of the two. Our enterprise AI agent threat model covers where this identity work fits alongside the other machine-identity decisions a multi-agent deployment forces, and the confused deputy patterns in our MCP server authentication audit are worth reviewing in parallel, since an agent that is properly authenticated at the A2A layer can still be tricked into misusing a downstream MCP tool call if that separate authorization boundary is not equally well defended.