Securing Agent-to-Agent (A2A) Communication

Last Updated on July 16, 2026 by Arnav Sharma

Securing agent-to-agent communication has become one of the harder problems in enterprise AI, because multi-agent systems are being deployed faster than their security models are being defined. The Agent2Agent (A2A) protocol lets AI agents from different vendors and frameworks discover each other, delegate tasks, and return results over standard web transport. What it deliberately does not do is solve identity, credential provisioning, or authorization for you. That gap is where the risk lives, and closing it is the job of whoever operates the deployment.

This guide walks through how A2A communication works, the concrete security risks it leaves open, and the controls that actually close them. A2A is an open protocol for standardized communication between different ai agents, and enabling seamless communication across systems is exactly what makes agentic ai security hard. The focus here is practical: what a client agent and an a2a client exchange, where authentication and authorization break down, and how to harden an a2a environment before it reaches production. Much of this rests on the large language models inside each agent, which is why agent collaboration between multiple agents needs guardrails.

What Agent-to-Agent Communication Is and Why Its Security Model Is Different

A2A is an open standard for communication between AI agents, and this agent2agent protocol exists to enable agent interoperability. Google introduced it in April 2025 with more than 50 industry partners, and the Linux Foundation now stewards the project. The protocol defines how autonomous agents discover one another, negotiate capabilities, exchange tasks, and return results over HTTPS using JSON-RPC 2.0, with Server-Sent Events for streaming updates on long-running work. The goal is seamless communication and agent collaboration across heterogeneous agent ecosystems.

The design philosophy matters for security. Rather than inventing a new identity system, A2A aligns with existing OpenAPI authentication schemes and lets each agent declare what it supports. That keeps the protocol lightweight and lets it plug into enterprise identity infrastructure. It also means the security posture of any given A2A deployment depends entirely on what the implementers put in place. The protocol gives you the plumbing, not the guarantees.

This is the single most important thing to internalise. A2A is a communication protocol first. Trust establishment, credential handling, and agent identity verification sit outside its scope by design.

The A2A interaction flow: agent cards, client agent, remote agent

Every A2A server publishes an agent card, a JSON document served at a well-known path that describes the agent’s name, capabilities, supported skills, endpoint URL, and the authentication schemes it accepts. The card is the entry point for the whole model, and it drives four stages:

• Discovery: A client agent fetches the remote agent’s card before initiating any communication. The card’s security field maps directly to OpenAPI security scheme objects, so an agent might declare it accepts Bearer tokens via OAuth 2.0, requires mutual TLS, or treats an API key header as sufficient.
• Credential acquisition: A2A explicitly states that credential provisioning is out of scope. The client completes an OAuth flow, or obtains an mTLS certificate, through a separate out-of-band process. Credentials are never embedded in the card itself. They travel in the Authorization header with each request.
• Task request: The client sends a task to the endpoint advertised in the card. Each task carries a unique identifier, and the remote agent processes it and returns a result, a streaming update, or an artifact.
• Response and callbacks: For long-running tasks, the remote agent can push webhook notifications back to a client-supplied URL. That callback URL is its own attack surface and must be authenticated in turn.

The mental model to hold: the agent card is both the protocol’s greatest strength and its primary attack surface. Everything downstream trusts what the card says, and every api call and task request between ai systems inherits that trust. In practice, agent interactions are only as safe as the weakest card in the chain.

A2A and MCP: two protocols, two trust boundaries

A2A is complementary to the Model Context Protocol (MCP), and confusing the two leads to mismatched controls. MCP governs how a single agent accesses tools and context, the agent-to-tool boundary. A2A governs communication between ai agents, the agent-to-agent boundary, and secure ai agent communication depends on knowing which one you are protecting. In a typical topology, an orchestrator agent uses A2A to delegate subtasks to different ai agents acting as specialists, and each specialist may use MCP internally to call its own tools.

The two protocols fail in different ways. MCP is exposed to tool poisoning, where a tool description is modified in transit or at the source to manipulate the calling agent. A2A is exposed to agent card spoofing and cross-agent prompt injection. Securing an agentic ai deployment end to end means addressing both boundaries, not assuming that hardening one covers the other.

The Security Risks in A2A Communication

Deploying agent communication protocols expands the attack surface in ways traditional systems do not, because agents interact autonomously and in multiple steps. The reported threat categories map cleanly onto established models like STRIDE and the CIA triad. Here are the ones that matter most in practice.

Agent card spoofing and poisoning

Because client agents rely on the card to decide who to trust and how to authenticate, the card is the highest-value target. A2A version 0.3 and later supports card signing but does not enforce it, which means card spoofing through DNS or CDN compromise is a low-cost, routine threat rather than an exotic one.

Two distinct attacks show up in the research. In Agent Card spoofing, a malicious agent crafts a deceptive card to misrepresent its capabilities and win selection by the orchestrating agent. In Agent Card poisoning, documented by researchers at Keysight, a malicious remote agent embeds adversarial instructions inside the card’s metadata, turning a discovery artifact into an injection vector. Palo Alto Networks researchers have also shown compromised servers advertising spoofed endpoint and documentation URLs that redirect legitimate client agents to hostile endpoints.

Authentication and authorization gaps

A2A supports strong authentication schemes but mandates none of them, and it defines no authorization framework at all. The specification acknowledges that authorization logic, meaning which agents can access which skills and trigger which actions, is the responsibility of each implementation. Its enterprise guidance states that agents must enforce authorization before sensitive actions, but leaves the mechanism unspecified.

That creates predictable failure modes:

• Validation gaps: Relying solely on upstream validation creates trust holes. Authentication for agent-to-agent communication must be verifiable, contextual, and revocable, and validation has to occur at every receiving endpoint, not just the first hop.
• Capability inflation: An agent requests or is granted permissions, such as file access or network calls, that extend beyond its intended scope, as documented in Cisco’s A2A threat work.
• Cross-boundary escalation: In multi-tenant agentic systems, a compromised agent in one tenant can invoke privileged services in another when tokens are not bound to tenant context.

Prompt injection across agent workflows

Prompt injection is dangerous in a single agent. In a connected ecosystem it becomes transitive. Crafted inputs can propagate through interconnected agent workflows, so a malicious instruction absorbed by one agent spreads to the agents it collaborates with downstream. Cisco has documented indirect prompt injection delivered through live Server-Sent Events streams, where hidden commands ride inside streaming updates and hijack agent behaviour mid-task. The root cause is the same one behind most reasoning attacks: the lack of a hard separation between data and instructions.

Replay, DoS, and compromised agent scenarios

Beyond identity and injection, A2A’s scalable design introduces operational threats. Recursive denial-of-service attacks are triggered by repeated task delegation that causes deadlocks or unbounded loops between agents. Task replay, where a captured task is resubmitted, is a real risk when tokens are not sender-constrained. And a single compromised agent, whether through card poisoning or credential theft, becomes a pivot point into every agent that trusts it.

Core Controls for Securing Agent-to-Agent Communication

The through-line for every control below: A2A hands you the mechanisms and expects you to enforce them. Treat the protocol as offering options, and treat your integration layer as where security is actually won or lost.

Authentication: scoped tokens, mTLS, and sender constraints

Authentication in A2A communication should lean on modern token-based standards: OAuth 2.1 authorization code flows with PKCE, client credentials grants with sender constraints for machine-to-machine calls, and short-lived JWTs with strict audience claims.

• Scope tokens to the agent and the skill. Access tokens should be ephemeral and bound to a specific agent identity. Refresh tokens, where used, should rotate and stay tenant-scoped.
• Constrain the sender. Mechanisms like mTLS-bound tokens or DPoP (Demonstration of Proof-of-Possession) reduce replay risk, because an intercepted token cannot be reused from a different environment.
• Validate everywhere. Every receiving endpoint validates independently. Do not inherit trust from an upstream hop.
• Add PKI-backed machine identity for service-to-service calls. When no human is in the loop, mutual TLS with certificate-based machine identities closes gaps that bearer tokens alone leave open, and it gives you a verifiable, revocable agent identity rather than a shared secret.

Authorization: least privilege at the skill level

Because A2A defines no authorization framework, you build one. The recommended pattern is to scope OAuth tokens to specific agent skills, enforcing least privilege at the token level rather than expecting the protocol to do it. Design agent cards with the minimum permissions necessary, validate authorization at every agent interaction point, and treat tenant boundaries as immutable unless they are formally bridged through a controlled federation policy with identity translation and audit logging.

For high-assurance workflows, deterministic pre-action authorization is worth evaluating. The idea is to run an authorization decision at the framework layer, separate from the model’s reasoning, so that a prompt injection cannot talk the agent out of enforcing policy. This is the principle behind emerging proposals to extend A2A with a dedicated pre-action authorization step.

Transport-level security and card signing

Transport-level security is non-negotiable. A2A communication runs over HTTPS, and unless channels enforce mTLS or equivalent, they remain exposed to interception, injection, and spoofing. On top of transport encryption, enable and require agent card signing so a client agent can verify a card’s authenticity before trusting its contents. Since signing is supported but not enforced by the protocol, making it mandatory in your environment is a deliberate hardening decision you have to take yourself. Store all authentication tokens in dedicated secret management systems and rotate credentials on a defined schedule.

Threat-to-control mapping

The following matrix maps the primary A2A threats to the controls that address them, so the defensive picture is concrete rather than abstract.

Threat	Primary control	Supporting control
Agent card spoofing	Mandatory card signing and verification	mTLS, DNS and CDN integrity monitoring
Agent card poisoning	Treat card metadata as untrusted input; validate and sanitise	Data and instruction separation in the orchestrator
Weak or missing authentication	Scoped OAuth 2.1 or mTLS, short-lived JWTs	Sender-constrained tokens (DPoP, mTLS binding)
Missing authorization	Skill-scoped least privilege, per-endpoint checks	Deterministic pre-action authorization
Cross-agent prompt injection	Data and instruction separation, input validation	Plan-then-execute architecture, output filtering
Task replay	Sender-constrained tokens, nonce and task ID checks	Short token lifetimes
Recursive DoS	Delegation depth limits, rate limiting	Loop detection, timeouts
Compromised agent pivot	Least privilege, revocable machine identity	Continuous task auditing and monitoring

A2A vs MCP Security: A Side-by-Side Comparison

A2A and MCP solve different problems and carry different risks. Choosing controls without understanding which boundary you are protecting leads to gaps. This comparison sets them side by side.

Dimension	A2A protocol	Model Context Protocol (MCP)
Boundary secured	Agent to agent	Agent to tool and context
Core artifact	Agent card	Tool and resource definitions
Transport	HTTPS, JSON-RPC 2.0, Server-Sent Events	JSON-RPC over stdio or HTTP
Signature threat	Agent card spoofing and poisoning	Tool poisoning and rug pulls
Auth stance	Aligns with OpenAPI schemes, mandates none	Mandates OAuth 2.1 for remote servers
Authorization	Undefined, left to implementers	Left largely to implementers
Primary hardening	Card signing, mTLS, scoped tokens	Transport encryption, tool description integrity
Injection exposure	Transitive cross-agent injection	Indirect injection via tool output

The practical takeaway: an orchestrator that delegates via A2A while its specialists call tools via MCP has two trust boundaries to defend, and mcp and a2a demand different controls at each. As an open protocol built for standardized communication, A2A gives you interoperability, but authorization in a2a is left to you. To secure agent behaviour across agentic ai environments, treat both boundaries as first-class. Securing one and assuming coverage of the other is the most common architectural mistake in agentic deployments.

A Phased Approach to Deploy Secure A2A Agents

Hardening an A2A environment is easier as a staged progression than as a single big-bang effort. Getting ai security right here is a critical security requirement, not a nice-to-have, because every potential security gap in an a2a workflow compounds as you deploy ai agents at scale. This sequence works for most agentic ai environments, whether you are rolling out agentic ai for enterprises or scaling existing agentic ai adoption.

1. Establish machine identity first. Before any agent talks to another, give every agent a verifiable, revocable identity. Certificate-based machine identity through PKI is the strongest foundation for service-to-service communication.
2. Enforce transport and card integrity. Require mTLS on agent channels and make card signing and verification mandatory. Reject unsigned or unverifiable cards outright.
3. Scope authentication and authorization. Issue short-lived, sender-constrained, skill-scoped tokens. Validate authorization at every endpoint and bind tokens to tenant context.
4. Separate data from instructions. Architect the orchestrator so that content returned by remote agents is treated as data, never as instructions to execute. This is your primary defence against transitive prompt injection.
5. Add operational guardrails. Apply rate limits, delegation-depth caps, and loop detection to blunt recursive DoS, and log every task for audit.
6. Monitor continuously. A2A’s support for task auditing gives you the raw material for security monitoring. Use it. Open-source tooling such as Cisco’s A2A scanner can help validate agent configurations against known threat patterns.

Each stage assumes the one before it. Skipping straight to token scoping without a machine identity foundation, for instance, leaves you scoping credentials you cannot reliably attribute to a real agent.