A2A Protocol Security: Authenticating Agent-to-Agent Communication

Agent2Agent (A2A) is a protocol that allows AI agents to talk with each other seamlessly. It offers a cleaner means for agentic interaction, but was made with communication, not security, in mind. That means things like credential provisioning, establishing trust, and agent identity verification are outside its scope.

In organizations around the world, multi-agent AI systems are being deployed faster than their security models are being defined, and that gap is where attacks live. This guide covers A2A protocol security, including what agent cards are and how discovery works,  how authentication is currently handled, and which threats the current model leaves unaddressed. We’ll also look at how A2A compares to the MCP security model, and what approaches, like certificate-based mutual authentication, can close the remaining gaps.

What Is the A2A Protocol?

The Agent2Agent protocol is an open standard for communication between AI agents. It can be built on various frameworks, run by different vendors, or operate across organizational boundaries. Google announced A2A in April 2025 alongside more than 50 industry partners. Today, the Linux Foundation stewards the project.

The protocol defines how agents discover each other, negotiate capabilities, exchange tasks, and return results over standard HTTPS using JSON-RPC 2.0. It is explicitly complementary to the Model Context Protocol (MCP), which governs how an agent accesses tools and context. Using the A2A protocol an agent acting as an orchestrator delegates subtasks to specialist agents, while each of those specialist agents may use MCP internally to call tools.

The A2A design philosophy is deliberate. Rather than defining a new identity system, it aligns with OpenAPI authentication schemes (OAuth 2.0, OpenID Connect, API keys, mutual TLS) and lets agents declare what they support in their agent card. This keeps the protocol lightweight and integrable with existing enterprise identity infrastructure. That also means the AI security of any given A2A deployment depends entirely on what implementers choose to put in place.

How A2A Agent Discovery and A2A Protocol Authentication Works

Understanding A2A protocol security starts with the agent card and the four-stage interaction model the protocol defines.

1. Agent Card Discovery

Every A2A server publishes an agent card. This JSON document describes the agent’s name, capabilities, supported skills, endpoint URL, and the authentication schemes it accepts. The client agent fetches this file before initiating any communication.

The agent card’s security field maps directly to OpenAPI security scheme objects. An agent might declare that it accepts Bearer tokens via OAuth 2.0, that it requires mutual TLS, or that an API key header is sufficient. The client reads this declaration and obtains credentials through the appropriate out-of-band process.

2. Credential Acquisition (Out of Band)

A2A explicitly states that credential provisioning is outside its scope. A client agent that needs to authenticate against a remote agent using OAuth must complete an OAuth flow separately — whether that is a client credentials grant for machine-to-machine authentication, or a token delegated from a human user’s session. Credentials are never embedded in the agent card itself. Instead, they are passed in the Authorization HTTP header with each request.

This keeps the protocol from reinventing identity management, but it also shifts the security burden to the integration layer.

3. Task Request and Response

Once credentials are in hand, the client sends a tasks/send or tasks/sendSubscribe JSON-RPC call to the endpoint advertised in the agent card. Each task carries a unique task ID. The remote agent processes the task and returns a result, a streaming update via Server-Sent Events, or an artifact (file, structured data).

For long-running tasks, the server can push webhook notifications back to a URL provided by the client. Webhook security is a separate concern, and the client URL must itself be authenticated and protected.

4. Authorization and Least Privilege

A2A does not define an authorization framework. The specification acknowledges that authorization logic — which agents can access which skills, what data they can read, what actions they can trigger — is the responsibility of each implementation. The recommended approach is to scope OAuth tokens to specific agent skills, enforcing least privilege at the token level rather than relying on the protocol to do it.

Agent Card Security: The Discovery Attack Surface

The agent card is both the protocol’s strength and its primary attack surface. Because client agents rely on the card to determine which remote agent to trust and what authentication it requires, a tampered or spoofed card undermines the entire interaction.

What Can Go Wrong in A2A

Card tampering via DNS or CDN compromise: If an attacker can redirect the endpoint, they can serve a modified agent card that declares weaker authentication requirements or redirects the agent’s endpoint URL to an attacker-controlled server.

Agent-in-the-Middle impersonation: Security researchers at Trustwave SpiderLabs demonstrated this attack in 2025: a rogue agent presents an inflated agent card with a description designed to manipulate the host agent’s LLM-based selection logic into choosing it for all tasks. Because the host agent evaluates cards using a language model, injecting persuasive text into the card’s description field could hijack task routing. 

Agent card shadowing: An attacker clones a legitimate agent’s card, registers the rogue agent at a similar-looking domain or IP, and waits for misconfigured client agents to discover it. Without cryptographic verification of the card’s origin, clients have no reliable way to distinguish the real agent from the copy.

Stale capability claims: If an agent card is not kept current — for example, advertising deprecated skills, outdated endpoint URLs, or revoked authentication schemes — client agents may route tasks incorrectly or attempt authentication that silently fails, creating unpredictable behavior at scale.

How To Protect the Agent Card Endpoint

The A2A specification and a Red Hat security analysis both point to several safeguards that implementers should treat as non-negotiable in production:

• Serve agent cards over HTTPS with TLS 1.3 or higher: Certificate validation must be enforced on the client side. Reject any card served over HTTP or from an endpoint with an invalid certificate.
• Apply access controls intelligently: For internal agent deployments, restrict the endpoint to authenticated callers or specific IP ranges. Not every agent card needs to be publicly discoverable.
• Sign agent cards cryptographically: Digital signatures are a recommended but not mandated control in A2A. Signing the card with the agent’s private key lets clients verify authenticity before reading the contents. You may consider Certificate Transparency logging for agent cards — treating them analogously to TLS certificates.
• Validate cards before use, not just at startup: Client agents should re-fetch and re-verify agent cards periodically or before high-value task delegations. A card that passed verification at initialization may have been modified since.
• Do not trust card contents for security decisions without verification: The agent card’s description and skills fields are processed by language models; treat them as untrusted input. Capability claims should be validated against a trusted registry, not accepted at face value.

How Certificate-Based Mutual Authentication Strengthens A2A Security

Token-based authentication, whether OAuth bearer tokens or API keys, has a structural weakness: the credential is a secret that can be exfiltrated. A token stolen from memory, a log file, or a network intercept grants access until it expires. For agent-to-agent communication, where there is no human to notice anomalous behavior and respond, that window is often long enough to cause significant damage.

Mutual TLS (mTLS) addresses this vulnerability by replacing shared secrets with cryptographic identity. Each agent holds an X.509 certificate issued by a trusted Certificate Authority. When two agents establish a connection, both present their certificates. The connection only completes if both certificates are valid, unexpired, issued by a trusted CA, and match the expected identity. There is no secret to steal. There’s only a private key that never leaves the agent’s environment.

For A2A deployments, this means:

• Agent identity is cryptographically bound to the agent’s certificate: As opposed  to a token that could be reused by any process that obtains it.
• Certificate revocation provides immediate access termination: If an agent is compromised, revoking its certificate cuts off all connections instantly. There’s no need to wait for token expiry or rotate a shared secret.
• The CA becomes the trust anchor.: Rather than each agent independently deciding whether to trust another agent’s self-reported identity, all agents trust certificates issued by the same CA hierarchy. The agent card still advertises supported auth schemes, but identity proof is handled at the TLS handshake, below the application layer.
• Digital certificates reduce the blast radius of compromise: Certificates can be issued with short validity periods. For example, certificates can last hours or days rather than months. They can also be automatically renewed, giving agents strong identity without creating long-lived credentials.

The PKI infrastructure required to support mTLS at scale — CA management, certificate issuance, OCSP or CRL-based revocation, automated renewal — is the same infrastructure that organizations already use for device certificates in 802.1X network authentication. The operational patterns are well understood; the challenge is extending them to cover AI agent workloads.

The SecureW2 Dynamic PKI platform handles automated certificate issuance and revocation for machine-to-machine workloads, including A2A agent mTLS deployments.

PKI Infrastructure for Agent Identity at Scale

Agent-to-agent communication is fundamentally machine-to-machine communication. And machine identity at scale is a solved problem in enterprise PKI. The same certificate lifecycle management, automated enrollment, and revocation infrastructure that manages device certificates for network access can manage agent certificates for A2A authentication.

Most organizations already understand certificate lifecycle management conceptually. The operational gap is extending that infrastructure to cover AI agent workloads. Managing certificates manually does not scale beyond a handful of agents. Automating issuance, renewal, and revocation across dozens or hundreds of agents running in containers, cloud functions, or Kubernetes pods requires a PKI platform designed for high-volume certificate workloads.

Extend Certificate-Based Identity to Your AI Agent Infrastructure

Certificate-based mutual authentication can secure your A2A agent deployments without adding operational complexity.

Our Dynamic PKI platform is built for this workload. Organizations already using our JoinNow Cloud RADIUS platform for 802.1X device authentication can extend the same CA hierarchy to issue identity certificates for AI agents — giving both human users and autonomous agents a consistent, certificate-backed identity model under a single trust anchor. For a deeper look at how mTLS fits this model, see our guide on mutual TLS authentication.

Schedule a demo or contact us to see how the SecureW2 Dynamic PKI platform can extend strong machine identity to your AI agent infrastructure.