- Authenticate and authorize every request between agents, and never trust a peer because it is internal.
- Treat the Agent Card as a trust anchor: verify it, prefer signed cards and use an attested registry.
- Confused deputy attacks pass valid-looking instructions through a trusted agent, so re-check the original intent for each privileged step.
- Contain failures with short-lived credentials, quotas, circuit breakers and tamper-evident logs.
What Is A2A And Why Does It Need Its Own Security?
A2A, the Agent2Agent protocol, is an open specification that lets independent AI agents find each other and hand work over. Its specification says it aims to "facilitate communication and interoperability between independent, potentially opaque AI agent systems". Securing it comes down to four jobs: prove who each agent is, check what it may do on every request, protect the messages, and limit how far one failure can travel.
This is more than normal API security because agents act on what they receive. A forged or tampered message does not just return bad data. It can steer another agent that holds real access. OWASP names the problem ASI07, Insecure Inter-Agent Communication, in its Top 10 for Agentic Applications 2026. It says weak controls for "authentication, integrity, confidentiality, or authorization" let attackers "intercept, manipulate, spoof, or block messages". For the wider threat picture, see top threats to AI agents and what is agentic security.
How Do Agent Cards And Authentication Work?
Each A2A server publishes an Agent Card, "a JSON metadata document" describing its identity, capabilities, skills, service endpoint and authentication requirements. Other agents read the card to decide how to talk to it. That makes the card a trust anchor, and a fake card is an attack. OWASP gives the scenario of an attacker registering a fake peer agent in a discovery service with a cloned schema, so that privileged coordination traffic reaches the wrong party.
The A2A enterprise guidance is direct about the basics. Production traffic must use HTTPS, and TLS 1.2 or higher is recommended. The protocol messages do not carry user or client identity, so credentials travel in HTTP headers, and the server "must authenticate every incoming request". The specification supports API keys, HTTP Basic, OAuth 2.0, OpenID Connect and mutual TLS. Access can be set per skill, and agents must grant only the permissions a client needs. Treat each agent as a non-human identity with its own credentials, and follow zero trust: no peer is trusted because it sits inside the network.
The specification also allows Agent Cards to be signed. Before signing, the card must be canonicalized with the JSON Canonicalization Scheme (RFC 8785). OWASP goes further and asks for signed agent cards, continuous verification and registries that attest an agent's identity. The table sets the two side by side.
| Topic | A2A specification | OWASP ASI07 and ASI03 guidance |
|---|---|---|
| Channel | HTTPS or TLS in production; verify the server certificate | End to end encryption with per-agent credentials and mutual authentication |
| Identity | Authenticate every incoming request; Agent Cards can be signed | Signed agent cards, continuous verification, attested registry |
| Messages | Validate all input parameters before processing | Sign messages, hash payload and context, use typed schemas |
| Permissions | Authorization checks on every request, scoped to the caller | Re-check each privileged step with a central policy engine |
What Is The Confused Deputy Problem Between Agents?
It is when a trusted agent is tricked into using its own power for someone who should not have it. OWASP describes it under ASI03, Identity and Privilege Abuse: "agents often trust internal requests by default. A compromised low-privilege agent can relay valid-looking instructions to a high-privilege agent, which executes them without re-checking the original user's intent."
Authentication alone does not stop this. The finance agent may be correctly identified, and so may the sender, yet the request still came from a crafted email. The chain below is the OWASP example, simplified.
- Crafted email arrivesA message that looks like it comes from IT
- Sorting agent relays itIt passes the instruction to the finance agent
- Finance agent trusts the peerIt treats an internal agent as safe
- Payment is processedNo one checked the original intent
OWASP's fixes are practical. Issue short-lived, narrowly scoped tokens per task. Re-verify each privileged step with a central policy engine. Bind tokens to a signed intent that names subject, audience, purpose and session, and reject a token whose intent does not match the request. Require human approval for high-privilege or irreversible actions, as covered in human in the loop and least agency. The A2A specification adds its part: servers must check authorization on every request and scope results to what the caller may see. For a product example, in the Brandefense MCP server, read-only tools run directly, tools that change data ask for confirmation, and access follows the signed-in user's role.
How Do Tampered Messages And Failures Spread?
OWASP calls this ASI08, Cascading Failures: "a single fault (hallucination, malicious input, corrupted tool, or poisoned memory) propagates across autonomous agents, compounding into system-wide harm." Its examples include replayed trust messages that make agents honor stale instructions, and two agents that rely on each other's output and amplify an error. The warning signs it lists are rapid fan-out, retry loops between agents and queue storms.
Defenses are about containment. OWASP suggests agent-aware anti-replay with nonces, session identifiers and timestamps tied to task windows. It also suggests sandboxing and segmentation, separate policy enforcement between planning and execution, rate limiting, and "blast-radius guardrails such as quotas, progress caps, circuit breakers between planner and executor". The Cloud Security Alliance's MAESTRO threat model supports the same thinking: security "is a property that must be built into each layer" of an agentic system, with agent-to-agent dynamics treated as their own concern.
Logging makes all of this checkable. A2A guidance says to log taskId, sessionId, correlation IDs and trace context on both client and server, and to audit task creation and critical state changes. OWASP adds tamper-evident logs bound to agent identities. See monitoring and logging for AI agents. The UK NCSC puts the test plainly: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."
What To Do Next.
Work through this list for every pair of agents that exchange tasks.
- List every agent and every link between agentsInclude discovery services and registries
- Require HTTPS and authenticate every requestA2A guidance: the server must authenticate every incoming request
- Verify Agent Cards before trusting themSigned cards and an attested registry (OWASP)
- Give each agent its own short-lived, task-scoped credentialsAvoid shared or long-lived keys
- Check authorization on every request, not only at loginA2A specification and OWASP ASI03
- Pin allowed protocol versions and reject downgradesOWASP ASI07
- Add quotas and circuit breakers between planner and executorOWASP ASI08
- Log task IDs and messages in tamper-evident logsA2A guidance and OWASP
- Put a person in front of high-impact or irreversible actionsOWASP ASI03
Then test it. A short exercise that spoofs a peer, replays a message and tries to push a low-privilege request through a high-privilege agent will show which of these controls are real. See red teaming AI agents for how to run such tests safely, and securing MCP servers and tool access for the tool side.
Questions.
-
What is the A2A protocol?
A2A, the Agent2Agent protocol, is an open specification for communication between independent AI agent systems. It lets agents discover capabilities, manage tasks and exchange information without access to each other's internal state, memory or tools.
-
What is an Agent Card?
It is a JSON metadata document published by an A2A server. It describes the agent's identity, capabilities, skills, service endpoint and authentication requirements.
-
Should Agent Cards be signed?
The A2A specification supports signed Agent Cards and requires the card to be canonicalized with JCS (RFC 8785) before signing. OWASP goes further and asks for signed agent cards, continuous verification and attested registries.
-
How should agents authenticate to each other in A2A?
Credentials travel in HTTP headers, because A2A messages do not carry identity. The server must authenticate every incoming request. Supported schemes include API keys, HTTP Basic, OAuth 2.0, OpenID Connect and mutual TLS.
-
Is HTTPS required for A2A?
For production, yes. The A2A guidance says all communication in production must use HTTPS, and TLS 1.2 or higher is recommended.
-
What is a confused deputy attack between agents?
OWASP describes it as a compromised low-privilege agent relaying valid-looking instructions to a high-privilege agent, which acts without re-checking the original user's intent. It sits under ASI03, Identity and Privilege Abuse.
-
What does OWASP ASI07 cover?
ASI07 is Insecure Inter-Agent Communication. It covers interception, spoofing, tampering, replay and routing attacks on messages and discovery between agents.
-
What is a cascading failure in a multi-agent system?
OWASP ASI08 describes a single fault, such as a hallucination, malicious input, corrupted tool or poisoned memory, that spreads across autonomous agents and grows into system-wide harm.
-
How do you limit the spread of a failure?
OWASP suggests sandboxing, least privilege, segmentation, short-lived task-scoped credentials, rate limiting and blast-radius guardrails such as quotas, progress caps and circuit breakers between planner and executor.
-
What should be logged for A2A traffic?
A2A guidance says to log taskId, sessionId, correlation IDs and trace context on both client and server, and to audit task creation, critical state changes and agent actions.