A2A Protocol Security: How to Secure Agent-to-Agent Communication

A2A protocol security is the set of controls you add on top of Agent2Agent so that agents discovering and delegating to each other cannot be impersonated, over-privileged, or manipulated. A2A itself handles interoperability: how an agent advertises its capabilities in an Agent Card, how a task is handed off, and which authentication schemes an agent says it supports. It deliberately does not decide whether a given Agent Card is authentic, whether a delegated task exceeds the requester authority, or whether an incoming message contains an injected instruction. Those are your problem, and in a fleet of agents they are where incidents actually come from.

What is the A2A protocol?

Agent2Agent is an open protocol for agents to find each other and work together across vendors and frameworks. Google published it in 2025 and donated it to the Linux Foundation, which is a large part of why it caught on: it gave the industry a neutral way for a planner agent built on one stack to hand work to a specialist agent built on another.

The core object is the Agent Card, a JSON document an agent publishes describing what it is, what skills it offers, where its endpoint lives, and which authentication schemes it accepts. A client agent reads the card, decides the peer can do the job, authenticates, and sends a task. Messages and artifacts flow back. That is the whole model, and its simplicity is the reason it works.

It is worth separating two things people conflate. A2A is a transport and discovery convention. It is not an authorization system, not a policy engine, and not a trust framework. The spec says how agents talk. It does not say who is allowed to ask whom for what.

Is the A2A protocol secure?

A2A is built on ordinary web security primitives, so the transport can be secure, but the protocol alone does not make a multi-agent system secure. Agent Cards declare supported authentication schemes without the spec mandating how a consumer verifies that the card itself is authentic. That single gap is what makes agent impersonation, card tampering, and replay realistic rather than theoretical.

Think of it the way you think about HTTP. HTTP is not insecure, but nobody would claim that speaking HTTP means your API is protected. You still need authentication, authorization, input validation, rate limiting, and logging. A2A sits in the same position for agents, one layer up.

What are the security risks of agent-to-agent communication?

The risks specific to agents talking to agents are different from the ones you test for in a single agent. Each of these has been demonstrated in agentic security research, and none of them requires a flaw in any individual agent.

Authority widening is the one that surprises teams. It is not an exploit in the usual sense: no code is broken, no boundary is bypassed. An executor agent holds credentials for a payments API because it legitimately needs them, another agent asks it to move money, and it does. The security research name for this is the confused deputy problem, and it has been well understood in systems design for decades. Multi-agent architectures reintroduce it at scale because delegation is the entire point of the design.

How do you secure agent-to-agent communication?

The workable answer is to stop trusting what agents say about themselves and start enforcing at the boundary. Six controls cover most of it.

1. Give every agent a verifiable workload identity. Not a shared service account and not a self-declared name in a card. Short-lived, cryptographically issued credentials, ideally sender-constrained with mTLS or DPoP so a stolen token is useless elsewhere. Our guide on how AI agents authenticate covers the mechanisms in detail.
2. Verify the card, then pin the endpoint. Check the peer identity against something you actually control before a task or a token leaves your side, and do not let a card silently redirect traffic to a new host.
3. Never widen privilege on a handoff. The authority attached to a delegated task should be the intersection of what the requester held and what the task needs. Delegation can narrow; it must not expand.
4. Inspect every inbound message for injection. Treat text from a peer agent exactly as you treat text from a web page or a document, because it may have originated there. See indirect prompt injection for how the payload travels.
5. Bound the graph. Maximum delegation depth, per-chain budgets, and hard timeouts, enforced by infrastructure rather than by asking agents to behave.
6. Log every hop immutably. Acting agent, requesting agent, policy verdict, and what data crossed. Without per-hop attribution, a multi-agent incident cannot be reconstructed after the fact.

Note what is absent from that list: instructions in a system prompt. Anything enforced by prompt can be argued away by an injected paragraph or a model upgrade, and in a fleet you would have to get it right in every agent at once. Enforcement belongs in one place that every agent passes through.

A2A vs MCP: which security problem does each create?

These two protocols are complementary and are often described as competitors, which confuses the security conversation. MCP standardizes how an agent reaches tools and data. A2A standardizes how agents reach each other. A typical fleet runs both, and each opens a distinct attack surface.

A2A has the larger blast radius because it is transitive. A poisoned MCP tool gets you what that tool can do. A trusted-but-compromised peer agent gets you everything that agent can reach, plus everything it can convince its own peers to do. If you are prioritizing, secure the delegation edges before the tool edges. We cover the tool side in MCP tool poisoning.

What does a realistic A2A attack chain look like?

A concrete example makes the abstraction land. Say a marketing team runs three agents: a research agent that reads the open web, a writing agent that drafts, and a publishing agent that pushes finished work live, the kind of pipeline that writes and auto-publishes SEO articles without a human in the loop. Each agent is scoped sensibly on its own.

The research agent fetches a competitor page that carries a hidden instruction. It summarizes the page faithfully, injected sentence included, and hands the summary to the writing agent over A2A. The writing agent has no reason to distrust a peer, so it treats the summary as context and the instruction as guidance. It emits a draft containing a link the attacker wanted, and delegates publishing. The publishing agent holds the CMS credential and does its job. Nothing was compromised. Everything worked as designed.

Now walk the controls back through that chain. Inspecting the research agent output at the boundary catches the injected sentence before it becomes context. Scoping the writing agent so it cannot request publication directly removes the escalation path. Gating the publish action for a human catches what got through. Per-hop logging tells you within minutes which fetch introduced the payload. Any one of the four breaks the chain, which is the useful property of layered enforcement.

Where to enforce it

A2A gave the industry a shared language for delegation, and that is a genuine step forward. It also moved the security question from inside one agent to the space between many, which is harder to reason about and easier to leave unowned. The teams handling this well are not writing better prompts. They are putting a control plane on the path every agent request takes, so identity, authorization, injection inspection, approval, and audit are enforced once and apply everywhere.

Agentshield is that layer. It gives every agent its own identity and least-privilege scope, checks each cross-agent call and tool call against policy before it runs, blocks injection at every boundary, holds irreversible actions for a human, and writes an immutable trail of the whole chain. See multi-agent system security for the full architecture, or MCP server security if tools are your first concern.