What is the A2A protocol?

How does the A2A protocol work?

A2A standardizes how one agent, the client, asks another agent, the remote server, to do work. Each participating agent publishes an Agent Card, a JSON document describing its identity, skills, service endpoint, and authentication requirements. A client agent reads the card, picks the right agent for the job, and sends it a task. The remote agent moves the task through a defined lifecycle and streams results back as messages and artifacts.

Version 1.0 of the specification, the first stable release, defines three transport bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON. Agents advertise which transports and security schemes they support, which lets an agent built on one framework delegate to an agent built on a completely different stack. That interoperability is the point: A2A treats every agent as an opaque service, so agents can collaborate without exposing their internal state, models, or tools.

A2A vs MCP: what is the difference?

The Model Context Protocol connects a single agent to its tools and data sources; A2A connects agents to other agents. In the common analogy, MCP gives an agent hands while A2A gives agents a shared language. A procurement agent might use MCP to query an inventory API, then use A2A to negotiate delivery dates with a supplier's scheduling agent.

The two are complementary, and most agentic architectures will run both. That also means their risks compound: an agent compromised through a malicious MCP tool can push poisoned instructions to every agent it talks to over A2A. Security teams need to treat the combined mesh, not each protocol in isolation, as the attack surface.

How do agents authenticate each other in A2A?

A2A deliberately reuses established web security rather than inventing new cryptography. An Agent Card declares supported schemes in its securitySchemes field: API keys, HTTP authentication, OAuth 2.0, OpenID Connect, or mutual TLS. Clients obtain credentials out of band, present them on every request, and run all traffic over HTTPS.

Agent Cards can also be digitally signed so a client can verify that a card actually belongs to the agent it claims to describe. What the protocol does not do is mint identities. Every agent still needs its own credential from your identity infrastructure, which makes each A2A endpoint a non-human identity that must be issued, scoped, rotated, and retired like any other machine identity.

What breaks when agents trust each other?

Agent-to-agent trust fails in ways traditional service-to-service auth does not, because the payloads are natural language that the receiving agent acts on. Security researchers analyzing A2A deployments consistently flag a short list of failure modes:

None of these are exotic. They are the confused deputy problem, prompt injection, and shadow AI replayed at machine speed across a mesh of autonomous actors, with each new agent multiplying the paths an attacker can chain together.

• Agent Card spoofing: an attacker publishes a forged or lookalike card so victim agents delegate tasks to a malicious endpoint
• Cross-agent prompt injection: a hostile agent embeds instructions in task results that the receiving agent then executes
• Confused deputy attacks: a low-privilege agent routes requests through a high-privilege agent to reach data it could never access directly
• Untraceable delegation: task chains hop across three or four agents and no single hop records which human the work traces back to
• Shadow agents: teams stand up A2A endpoints outside governance, growing the mesh faster than security can inventory it

How do you secure an A2A deployment?

Start with identity. Give every agent its own credential, never a shared service account, so each A2A request is attributable to exactly one agent and, through the delegation chain, to a human owner. Scope those credentials to least privilege and prefer short-lived tokens over long-lived secrets so a stolen credential expires before it is useful.

Then verify and observe. Accept only signed Agent Cards from a curated registry, require mutual TLS or OAuth on every hop, and log every task exchange so you can reconstruct who asked what of whom. Because agent behavior changes with the prompts flowing through it, static reviews are not enough: runtime monitoring of agent-to-agent traffic is what catches a well-credentialed agent doing something it should not.

Frequently asked questions

Related terms