The Agent2Agent (A2A) protocol is an open standard that lets independent AI agents, built on different frameworks or by different vendors, discover each other, agree how to interact and collaborate on tasks. It runs over ordinary web transport and leaves identity and authorization to standard enterprise practice, so most of the security work is yours.
What problem does A2A solve?
The specification (latest released version 1.0.0 when checked) says A2A aims to let agents discover each other's capabilities, negotiate interaction modes such as text, files or structured data, manage collaborative tasks, and exchange information without exposing their internal state, memory or tools. That last property, which it calls opaque execution, means agents work from declared capabilities rather than from each other's inner workings.
It reuses existing standards: HTTP, JSON-RPC 2.0 and Server-Sent Events, with gRPC and an HTTP plus JSON binding also defined. It supports long-running tasks and human-in-the-loop steps.
What are the core pieces?
- Agent Card. A JSON document describing the agent: who it is, what skills it offers, how to reach it and which security schemes it requires. It is published at a well-known URI, /.well-known/agent-card.json. Cards may be signed with JSON Web Signature, canonicalized with the JSON Canonicalization Scheme so signatures verify consistently.
- Task. The unit of work, with states. An agent can move a task into an auth-required state when it needs a credential or human approval.
- Message, Part and Artifact. The content exchanged: messages in, artifacts out.
- Operations. Send message, streaming send, get task, list tasks, cancel task and get Agent Card.
How is A2A different from MCP?
The specification's appendix says they are complementary. The Model Context Protocol standardizes how a model or agent connects to tools, APIs and data sources. A2A standardizes how independent agents talk to each other as peers and delegate work. In the spec's picture, a client agent asks a server agent to do a complex task, and that server agent may use MCP to call the tools needed to complete it.
What does the spec require for security?
Section 7 and section 13 are short and worth reading in full. The main points:
- Production deployments must use encrypted transport (HTTPS or TLS, with TLS 1.3 or later recommended), and clients should verify the server's certificate.
- Authentication is declared in the Agent Card's security schemes, credentials are obtained out of band, and the server must authenticate every incoming request.
- Authorization is left to the implementation, but the server must check it on every operation and scope results to what the caller may see. List and get operations must not leak the existence of other callers' tasks.
- Push notifications, where an agent calls a client's webhook, carry their own risks. The spec says agents should validate webhook URLs against server-side request forgery by rejecting private and loopback ranges, and clients must validate that a notification is authentic.
- Extended Agent Cards, returned to authenticated clients, should not include internal service URLs or credentials.
What is not covered?
A2A does not tell you whether the agent behind a card is trustworthy, whether its tool use is safe, or what a delegated task is allowed to touch. A signed card proves who published it, not that its behavior is safe. Prompt injection through a message from a peer agent is a separate risk that the protocol cannot remove.
A constructed example
A travel agent in a company delegates "book the cheapest compliant flight" to a partner's booking agent through A2A. The booking agent's card declares OAuth. The client obtains a scoped token out of band and sends the task. Midway the booking agent needs payment approval and sets the task to auth-required. A human approves in the company's own app. Without per-request authorization and scoping, the partner agent could also have listed every task the client had ever sent. With scoping, it sees only its own.
How to check or apply this
- Inventory every agent that exposes or consumes A2A, and who owns it.
- Fetch each Agent Card and review the declared security schemes and skills. Treat unsigned cards from outside your organization as untrusted.
- Require TLS and verify certificates for every connection.
- Give each agent its own identity and the narrowest scopes it needs, and check authorization on every operation.
- Validate webhook URLs and authenticate callbacks if you use push notifications.
- Log delegated tasks end to end, so you can see which agent asked which agent to do what.
Safeguard works on adjacent controls: its MCP Guardrail, agent identity and policies are meant to govern what agents can call and who they act as. They sit beside A2A rather than implementing it.
Quick check
Does A2A replace MCP?
No. The A2A specification describes them as complementary: MCP connects an agent to tools and data, while A2A connects agents to each other.
Does A2A handle authorization for me?
No. It requires authentication on every request and authorization checks on every operation, but leaves the authorization model to each implementation.
Sources
- A2A Protocol Specification, sections 1, 7, 8, 13 and Appendix B (fetched 18 October 2026)
Last reviewed: 18 October 2026.
