A2A Protocol Security: CISO Guide to Agent-to-Agent Risks

The Agent2Agent (A2A) protocol introduces a new attack surface that most enterprise security programs have not yet mapped. If your organization is deploying multi-agent AI systems, understanding A2A security risks is now a practical requirement, not a theoretical exercise.

A2A went generally available in April 2026 under Linux Foundation governance, with 50+ enterprise partners including Salesforce, SAP, ServiceNow, and Workday already committed to the standard. Your organization's AI stack may already be running it.

This guide covers the A2A threat model, the five highest-priority attack patterns, what the specification deliberately leaves to implementers (and why that matters), and the enterprise control framework your team needs before deploying A2A in production.

What A2A Is and Why CISOs Need to Care Now

The Agent2Agent protocol was announced by Google Cloud in April 2025 and donated to the Linux Foundation for open governance. Version 1.0 is the current release. The protocol's purpose is straightforward: standardize how AI agents from different vendors discover each other, delegate work, and exchange results, without exposing internal state, memory, or tool implementations.

The technical foundation is JSON-RPC 2.0 over HTTPS, with Server-Sent Events for streaming and webhook-based push notifications for asynchronous task updates. Any system that can make HTTPS requests can participate.

The enterprise adoption trajectory is significant. At Google Cloud Next 2025, the announcement included commitments from Accenture, BCG, Cognizant, Deloitte, McKinsey, PwC, TCS, Wipro, and major SaaS platforms. Cisco's agntcy project integrated with A2A to provide discovery, group communication, and identity layers. IBM's Agent Communication Protocol folded into the ecosystem. Multi-language SDKs exist for Python, JavaScript/TypeScript, Java, C#/.NET, and Go.

This is not a research protocol. It is production infrastructure that will carry sensitive enterprise data across organizational boundaries between agents your security team may not control.

A2A Architecture: The Attack Surface Map

Understanding the attack surface requires understanding the three core components of A2A:

Agent Cards are JSON documents published at /.well-known/agent-card.json per RFC 8615. Each card declares the agent's identity, endpoint URL, capabilities (streaming, push notifications, extended cards), skill definitions, and supported authentication schemes. Unauthenticated callers receive the public card; authenticated callers may receive an extended card with additional detail.

This is the primary discovery mechanism. It is also the first attack surface: any entity that controls a domain can publish an agent card, and card signing is optional in the specification.

Task Protocol defines stateful work units with a server-generated task ID and an optional context ID for grouping related tasks. Tasks move through a defined state machine: working, input-required, auth-required (an interrupt state for mid-task OAuth flows), and terminal states (completed, failed, canceled, rejected). Task history, artifacts (outputs), and metadata travel with the task.

The auth-required state deserves attention: it is explicitly designed to pause a task and trigger a credential handoff. This is where credential delegation abuse becomes possible.

Push Notifications use a webhook model. Clients specify a callback URL, an optional validation token, and authentication credentials in the PushNotificationConfig. The A2A server POSTs task status updates to this URL. The specification recommends JWT-signed payloads with JWKS key distribution. What it does not do is enforce this requirement or restrict which URLs clients can register.

Five A2A Attack Patterns Your Team Needs to Model

The primary security research on A2A, published on arXiv in April 2025, applies the MAESTRO threat modeling framework to the protocol. These are the five patterns with the highest enterprise risk:

1. Agent Card Spoofing and Impersonation

An attacker registers a lookalike domain and publishes a forged /.well-known/agent-card.json claiming to be a trusted internal agent or known vendor agent. A client agent that discovers agents dynamically, without verifying card provenance, routes real task payloads to the rogue server.

The protocol supports cryptographic signing of agent cards through trusted certificate authorities. However, signing is optional. In practice, most implementations will not enforce card signing until an incident forces the issue. Before that happens, your A2A deployment should establish a signed-card-only policy and validate signatures before trusting any card.

In production environments, we recommend coupling agent card discovery with DNSSEC to protect the DNS layer and certificate pinning or a private PKI for high-value agent endpoints.

2. Poisoned Agent Card (Prompt Injection via Metadata)

This is a novel attack class specific to A2A's automated card consumption model. When an orchestrator LLM parses an agent card to make routing decisions, the card fields (name, description, skill descriptions) become part of the LLM's input context. Attacker-controlled content in these fields can inject adversarial instructions into the LLM's reasoning chain.

In practice: an attacker who can serve a card (via spoofing, supply chain compromise, or misconfigured agent registry) can craft skill descriptions that redirect the orchestrator agent's behavior. The injected content survives the legitimate task payload and executes in the LLM's context without triggering standard input filters.

This maps to the indirect prompt injection threat class, extended to the agent card layer. Controls include schema-strict card parsing (process fields as data, not as LLM context), card content validation against allowlisted formats, and human-in-the-loop review for new agent card registrations in production environments.

3. Credential Delegation Abuse

A2A's auth-required task state was designed for legitimate mid-task OAuth flows, such as an agent needing user consent to access a protected resource. A compromised or malicious orchestrator can exploit this mechanism to request credential handoffs beyond the scope of the original task.

The specification provides no standardized mechanism for time-bounding delegated tokens, limiting their scope to specific downstream agents, or revoking them when a task completes. An OAuth access token delegated to an orchestrator for one task can persist in the orchestrator's credential store and be reused across unrelated tasks.

Enterprise controls: implement short-lived tokens (TTL under 15 minutes) for all A2A-delegated credentials, enforce scope declarations in agent cards, require explicit re-authorization for each task rather than session-level delegation, and audit credential usage logs across agent-to-agent calls. This connects directly to the non-human identity security problem: agents are not humans, and their credential lifecycle requires different controls than user accounts.

4. Replay Attacks on Task Requests

The A2A specification does not mandate nonce usage, idempotency keys, or replay prevention for task requests. A captured valid JSON-RPC request can be resubmitted, potentially triggering duplicate actions (double payments, duplicate record creation, repeated tool calls) or unauthorized actions if the original requester's credentials are still valid.

For push notification webhooks, the specification recommends using JWT jti claims and timestamp validation to prevent replay. But this is a recommendation, not a requirement, and it only covers the server-to-client notification direction.

Enterprise controls: implement request signing with timestamp and nonce validation at the infrastructure layer, enforce idempotency keys on all task creation requests, set short validity windows on task request signatures (30-60 seconds), and monitor for repeated task IDs or identical payloads from different sources.

5. Server-Side Request Forgery via Push Notification Webhooks

When a client registers a push notification URL in PushNotificationConfig, the A2A server will POST to that URL on task state changes. There is no built-in restriction on which URLs are acceptable. A malicious client can register an internal infrastructure URL (metadata service, internal API endpoint, network scanner target), using the A2A server as an unwitting SSRF proxy.

This is particularly dangerous in cloud environments where instance metadata services (AWS IMDS, GCP metadata server, Azure IMDS) are reachable from application servers. A successful SSRF via push notification webhooks can yield cloud credentials, IAM role tokens, or internal service discovery information.

Enterprise controls: validate all webhook URLs against an allowlist of approved external domains before registering; verify domain ownership via a challenge-response mechanism (the spec recommends this but does not enforce it); block all internal IP ranges, link-local addresses, and metadata service IPs at the network layer from outbound connections made by the A2A server.

What A2A Deliberately Leaves to Implementers

The specification explicitly delegates nine security-relevant decisions to implementations. These are not oversights. They are intentional flexibility points. They are also your responsibility:

Session and context expiration: The spec says agents "MAY implement context expiration" and "SHOULD document any such policies." There are no mandatory TTLs on tasks or context IDs. Without expiration policies, stale contexts accumulate indefinitely.

Rate limiting: Entirely unspecified. No mandatory caps on requests per second, concurrent streaming connections, or push notification registrations.

Artifact storage and retention: How task outputs are stored, encrypted at rest, and purged is not addressed. Sensitive data returned as artifacts persists until implementation-defined cleanup.

Agent card signing enforcement: Signing is supported but optional. The protocol provides no PKI requirement or enforcement mechanism.

Credential rotation: No standardized approach to rotating OAuth tokens or API keys across multi-agent deployments.

History length defaults: When historyLength is not specified in a task request, servers return "implementation-defined" amounts of history. This can expose more conversation context than the client expected.

Push notification delivery semantics: At-least-once vs. at-most-once delivery is implementation-specific. Applications that treat exactly-once as a guarantee will behave incorrectly.

Extension security: Custom extensions can introduce new methods and data types. The spec requires that extensions not bypass primary security controls but provides no enforcement mechanism.

Audit logging completeness: The spec does not define what must be logged. In multi-hop agent chains, this creates gaps where lateral movement leaves no trace.

Each of these becomes a line item in your A2A security architecture review. Where the spec delegates, your security policy must specify.

Enterprise Control Framework for A2A

A production-ready A2A deployment requires controls at four layers:

Identity and Authentication

Mutual TLS is the recommended baseline. A2A's specification lists MutualTlsSecurityScheme as a first-class authentication option precisely because it provides bidirectional certificate verification, not just server authentication. Every A2A endpoint in your environment should require mTLS for production traffic.

For machine identity management, SPIFFE/SPIRE is the current best practice. Issue short-lived x.509 certificates (SVID attestations) to each agent process, rotate them automatically on a short TTL, and use the SPIFFE trust bundle for cross-cluster agent verification. This eliminates the risk of long-lived static API keys that outlive their intended scope.

Agent Card Integrity

Establish a signed-card-only policy: agents that cannot present a verifiably signed card from a trusted CA are rejected. Protect agent card discovery with DNSSEC to prevent DNS-layer spoofing. For high-sensitivity agent endpoints, consider deploying a private agent registry rather than relying on open /.well-known/ discovery.

Parse agent card fields strictly as structured data. Do not pass card content directly into LLM context without sanitization and schema validation.

Network and Infrastructure Controls

Enforce TLS 1.3 minimum on all A2A connections and disable weak cipher suites. Place a WAF in front of A2A endpoints configured to reject malformed JSON-RPC payloads. Block all push notification webhook registrations to RFC 1918 addresses, link-local addresses, and cloud metadata service IPs at both the application and network layers.

Implement rate limiting on SSE streaming connections. A single client should not be able to hold hundreds of concurrent streaming sessions without triggering circuit breakers.

Observability and Audit

The specification's silence on audit logging means you define the requirement. At minimum, log: every agent card fetch and the responding server's identity, every task creation with client identity and declared scope, every auth-required state trigger and the credentials requested, every artifact delivery with size and destination, and every push notification registration.

Use tamper-evident logging (append-only log stores with cryptographic integrity) to prevent logging evasion attacks. In multi-hop agent chains, correlate logs using the task contextId to reconstruct full delegation chains for incident investigation.

See the AI agent security testing guide for how to integrate A2A audit coverage into a formal security assessment program.

A2A and MCP: Securing the Full Agentic Stack

If your organization has already addressed MCP (Model Context Protocol) security, A2A is the logical next layer. They solve different problems:

MCP standardizes how a single agent invokes tools, APIs, and data sources. It is primarily a client-server protocol where the agent is the client and tools are servers. The security focus is on tool permission scoping, input validation, and output filtering.

A2A standardizes how peer agents discover each other, delegate tasks, and collaborate. It is a peer-to-peer protocol with stateful task management and long-lived sessions spanning organizational boundaries. The security focus is on agent identity, credential delegation, and trust across organizational perimeters.

In a real multi-agent deployment, an orchestrator agent uses A2A to delegate to specialist subagents, and each subagent uses MCP internally to call tools. A credential compromise at the A2A layer can result in an attacker-controlled agent making MCP tool calls with the victim agent's permissions. The two protocols share a trust boundary that must be explicitly designed into your security architecture.

The MCP security guide covers the tool layer. This guide covers the agent communication layer. Together, they describe the complete security perimeter for agentic AI systems.

A2A Deployment Audit Checklist

Ten questions to ask about any A2A deployment before approving it for production:

Are all agent cards cryptographically signed, and is signature validation enforced at the client?

Are agent card fields treated as structured data or passed directly into LLM context?

Is mTLS configured and enforced on all A2A endpoints, or are API keys the authentication baseline?

Are machine identities managed with short-lived certificates (SPIFFE/SPIRE or equivalent), or with static long-lived keys?

Are OAuth token scopes explicitly declared in agent cards and enforced per-task, not per-session?

Are push notification webhook URLs restricted to an allowlist, with internal IP ranges blocked?

Is replay prevention implemented for task requests (timestamp + nonce or idempotency keys)?

Are context TTLs and artifact retention policies explicitly configured, not left as implementation defaults?

Are audit logs collected for all A2A interactions (card fetches, task creation, auth-required events, artifact delivery)?

Is rate limiting configured for SSE streaming connections and push notification registrations?

Conclusion

A2A is the agent-to-agent communication standard that will underpin multi-agent AI systems across your organization over the next 18 months. The architecture is well-designed and the protocol is technically sound. The security challenge is that the specification deliberately omits nine categories of security control, leaving them to implementers who typically do not have a security-first mandate.

The five highest-priority risks — agent card spoofing, poisoned card injection, credential delegation abuse, replay attacks, and SSRF via webhooks — each have tractable controls. None require waiting for an updated spec version. They require security architecture decisions made before deployment, not after an incident.

BeyondScale's AI penetration testing service includes A2A attack surface coverage: agent card integrity testing, credential delegation scope analysis, push notification SSRF testing, and multi-hop audit trail verification. Run a free Securetom scan to identify AI agent attack surfaces in your environment, or contact us to scope an agentic AI security assessment that covers both A2A and MCP layers.