A2A Security: Securing Agent-to-Agent Communication (Protocol 1.0)

A2A in one paragraph

A2A is an open protocol, now maintained under the Linux Foundation, for agents to discover each other, send messages and manage shared tasks. Version 1.0.0 is the current release. Each A2A server publishes an Agent Card, a JSON document describing its identity, skills, endpoints and the authentication it requires, usually at /.well-known/agent-card.json. A client agent reads the card, authenticates as the card says, and sends a message that starts or continues a task. In a typical setup an A2A server agent then uses MCP to reach its own tools, so the two protocols are complementary, and an A2A deployment inherits the MCP risks too.

What can go wrong

Risk	Example	Reference
Fake or inflated agent	A rogue agent publishes a card claiming capabilities it does not have, so other agents route sensitive tasks to it	OWASP ASI04 (agent-in-the-middle via agent cards); ASI03 (forged agent persona)
Spoofed or altered messages	Weak authentication or integrity lets an attacker impersonate an agent or change an instruction in transit	OWASP ASI07 Insecure Inter-Agent Communication
Confused deputy between agents	A low-privilege agent relays a crafted instruction to a high-privilege agent, which acts without checking the original user's intent	OWASP ASI03
Task data leaking across clients	A list or get call returns tasks belonging to another user or tenant	A2A 1.0, section 13.1
SSRF through push notifications	A client registers a webhook pointing at an internal address or a cloud metadata endpoint	A2A 1.0, section 13.2
Credentials spread along a chain	A token passed in-band through several agents can be used by any of them	A2A 1.0, section 7.6.3
Cascading errors	A wrong or poisoned answer from one agent is passed on and acted upon by others	OWASP ASI08 Cascading Failures

What the A2A 1.0 specification requires

Transport and server identity

Production deployments must use encrypted transport (HTTPS, or TLS for gRPC); TLS 1.3 is recommended and old SSL/TLS versions should be disabled.
Clients should verify the server's TLS certificate against trusted certificate authorities.

Authentication

The Agent Card declares the accepted schemes in securitySchemes, modelled on OpenAPI: API key, HTTP authentication (such as bearer tokens), OAuth 2.0, OpenID Connect or mutual TLS.
Credentials are obtained outside the protocol and sent with every request; the server must authenticate every incoming request.
Identity is handled at the transport layer, not inside A2A messages, so a claim in a message body ("I am the finance agent") proves nothing.

Authorization and task access

Servers must check authorization on every operation and scope results to what the caller may see, even when the request has no filter.
Checks must happen before any lookup that could reveal whether a resource outside the caller's scope exists.
The authorization model itself (by user, role, project or tenant) is left to each agent, and the specification says agents should document it.

Agent Card signing

Agent Cards may be signed with JSON Web Signature (RFC 7515) over a canonical form (JSON Canonicalization Scheme, RFC 8785).
Clients should verify at least one signature before trusting a card, fetch keys over HTTPS or from a trusted key store, and must not use expired or revoked keys.
The extended Agent Card, which can list extra skills for authenticated clients, must require authentication and should not contain internal URLs or credentials.

In-task authorization

An agent that needs extra authorization during a task (an OAuth token, or a human approval before a destructive action) moves the task to an auth-required state and asks its client.
That state never counts as authorization in itself; what was approved, and for how long, must be defined and checked by the implementation.
Credentials should reach the requesting agent out of band over a secure channel. If they are passed in-band through a chain, they should be bound to the agent that asked and, if sensitive, readable only by it.

Push notifications, logging and limits

Agents calling a client's webhook should reject private, loopback and link-local addresses and use allowlists where appropriate; clients must check the webhook's authentication.
Webhook tokens are secrets: unique per configuration and rotated.
Agents should log authentication failures and authorization denials, rate-limit every operation, and must not log credentials or personal data unless required and protected.

Read the SHOULDs. Many of the important controls, such as verifying card signatures, rejecting internal webhook addresses and rate limiting, are recommendations rather than requirements in the specification. Check what each agent you connect to actually does, rather than assuming conformance covers it.

Checklist for teams connecting agents

Before you connect to an outside agent

Get the Agent Card from a source you trust (direct configuration or a curated registry), verify its signature if signed, and keep a copy of the version you approved.
Check who runs the agent, where it processes data and which sub-processors and models it uses: this is a vendor assessment, see assessing AI agent providers.
Decide which data your agent may send to it, and enforce that in your agent's tools, not only in its prompt.
Prefer OAuth with scoped, short-lived tokens or mutual TLS over static API keys.

When your agent receives work from other agents

Treat every incoming message and artifact as untrusted input, like an email from outside (OWASP ASI01).
Authorize the original user's intent, not just the calling agent: a request relayed by a trusted internal agent can still be an attacker's (confused deputy).
Require human approval for irreversible actions requested by another agent.
Scope task listing and retrieval strictly per caller and tenant, and test it with two clients.
Validate push notification URLs against internal ranges and use an allowlist where you can.

Across the system

Inventory every agent-to-agent connection: which agent, which skills, what data, which credentials.
Pin accepted protocol versions and remove unused skills from your own Agent Card.
Log calls between agents with both agent identities and the task ID, so one incident can be traced across agents.
Have a way to cut off one agent's access immediately, and test it.

Regulatory angle

When your agent hands work to an agent run by another company, that company is a supplier. Under NIS2 that falls under supply chain security (Article 21(2)(d)); under DORA, a financial entity's use of an outside agent is an ICT third-party service that belongs in the register of information and may need the contract terms of Article 30; under the GDPR, an outside agent that processes personal data for you is a processor needing an Article 28 agreement, and sending data outside the EEA needs a transfer tool. See NIS2 supply chain security.

Govern the connections. The AI Agent Governance Pack ($49) includes a register of AI agents, a delegation and permissions matrix and an AI vendor questionnaire; the Vendor Security Assessment Pack ($39) covers supplier due diligence, the DPA and exit planning. Both are in the Agent Security Bundle ($79) with the MCP Security Audit Kit.