What is the A2A protocol?
By Identra · Updated
The A2A protocol, short for Agent2Agent, is an open standard that lets independent AI agents exchange messages, coordinate tasks, and return results across platforms. It provides a shared communication format, while deployments remain responsible for deciding which agents can connect, what they can access, and which actions they can take.
Key numbers
- More than 150 organizations back the A2A protocol, up from about 50 at its April 2025 launch (Linux Foundation, April 2026)
- The core A2A repository passed 22,000 GitHub stars in its first year (Linux Foundation, April 2026)
- A2A 1.0, the first stable specification, defines three transports: JSON-RPC 2.0, gRPC, and HTTP+JSON (A2A Protocol Specification v1.0)
How does the A2A protocol work?
An A2A client communicates with a remote agent through a server interface. The server publishes an Agent Card, a JSON document describing its capabilities, skills, connection details, and authentication requirements. Clients use that information to determine how to interact with it. Agents can collaborate without exposing their internal models, tools, or reasoning.
A client sends a message. The server can respond directly or create a task with a tracked lifecycle. Tasks can produce status updates and artifacts, such as a report or structured result. Streaming and push notifications depend on the server's advertised capabilities. These concepts are defined in the official A2A specification.
For security teams, each remote agent is another service boundary. Record its operator, business purpose, permitted data, and approved callers before allowing production use. A useful description in an Agent Card is not evidence that its publisher is trustworthy.
What is the difference between A2A and MCP?
A2A focuses on collaboration between independent agents. The Model Context Protocol exposes tools, resources, and prompts to AI applications. A workflow can use both, but neither protocol requires the other.
For example, a procurement agent might use MCP to retrieve purchase records, then use A2A to request a delivery assessment from a logistics agent. Review the authority at each boundary. Permission to request an assessment should not automatically permit changing an order.
What does it connect?
- A2A
- A client and a remote agent service
- MCP
- An AI application and servers exposing tools, resources, or prompts
What might it carry?
- A2A
- Messages, task updates, and result artifacts
- MCP
- Tool requests, tool results, and resource content
What should security review?
- A2A
- Remote agent trust and delegated authority
- MCP
- Server trust, tool permissions, and returned content
How do authentication and delegation work in A2A?
Agent Cards advertise authentication requirements, but publishing a card does not issue credentials or grant permission. The server must validate the caller and enforce authorization. Establishing who called and deciding what that caller may do are separate checks.
Treat AI agent identity as an operational responsibility. Assign an accountable owner, define credential issuance and revocation, and document the resources the agent can reach. A claimed agent name in a message must not substitute for verified credentials.
For AI agent delegation, preserve the distinction between the calling agent and any user on whose behalf it acts. Do not infer a user's authority from natural-language instructions. Where the identity system supports delegated access, validate that authority at the receiving service. Otherwise, constrain requests to an explicitly approved service role.
What could go wrong in an enterprise A2A workflow?
Consider a purchasing assistant that asks an external supplier agent for delivery options. The supplier returns a valid-looking response containing an instruction to attach the company's full purchasing history to a follow-up request. If the assistant treats that response as trusted operating instructions, routine collaboration can become data disclosure.
This is a possible prompt injection scenario, not an inherent outcome of using A2A. Authentication can establish the response's sender without establishing that its content is safe to obey. Treat returned text, files, and structured fields as untrusted input.
A separate failure occurs when a limited purchasing agent asks a more privileged finance agent to release payment. If finance relies only on the sender's authenticated identity, it may become a confused deputy. The receiving service must check authority for the specific transaction, including any required human approval.
How do you secure an A2A deployment?
Apply least privilege to the whole workflow. Restrict both what an agent can request and what the receiving service can execute. Put authorization checks in application code and service policy rather than relying on a prompt to enforce them.
- Approve remote endpoints and card sources. Review ownership and destination changes before allowing credentials or sensitive data to reach a new service.
- Protect connections with TLS and validate credentials at each receiving service. Prefer short-lived credentials where supported, with tested revocation procedures.
- Authorize task reads, updates, cancellation, and artifact retrieval. Knowing a task identifier must not grant access to its contents.
- Limit outbound data to fields needed for the task. Keep credentials and unrelated business records out of messages and artifacts.
- Validate returned content before using it in tool calls. Require explicit approval for payments, permission changes, and destructive actions.
- Constrain callback and artifact destinations. Prevent agents from using supplied URLs to access internal services or send data to unapproved locations.
What should you test before approving A2A for production?
Test denied paths alongside successful collaboration. Try an unauthorized caller, a revoked credential, a task belonging to another user, a changed endpoint, and a malicious instruction embedded in a result. Confirm that rejected requests cannot still trigger downstream actions.
Maintain an AI audit trail that records the verified caller, destination, task reference, authorization decision, and action outcome. Include the initiating user when that relationship is established. Limit sensitive payload logging and control access to retained records.
Finally, rehearse disabling a compromised agent. Stop new requests, revoke its access, and inspect unfinished work and downstream changes. Cancellation should not be assumed to undo an action that has already completed.
How Identra thinks about it
Identra discovers AI agents across Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, each with its owner, so teams know which agents exist before approving new agent-to-agent connections. On macOS and Windows, every AI agent run is recorded with the user, device, AI client and outcome, giving reviewers an accountable record as agent collaboration grows.
Go deeper: AI security, built on identity
Frequently asked questions
Does A2A replace MCP?
No. A2A supports collaboration with remote agents, while MCP exposes tools, resources, and prompts to AI applications. A system can use either protocol or both.
Is an Agent Card proof that an agent is trustworthy?
No. An Agent Card describes a service and how to connect to it. Its claims still need to be checked against an approved publisher, endpoint, and access policy.
Does A2A automatically pass along a user's permissions?
Do not assume it does. The deployment must establish and validate delegated authority through its identity and authorization systems.
Can an authenticated agent still send a malicious result?
Yes. Authentication identifies the caller or sender, but does not make its content safe. Receiving agents must treat results as untrusted input and enforce authorization before acting.
Does every A2A task need human approval?
No. Approval should match the action's consequences. Routine retrieval may run within a constrained policy, while payment release or access changes may require explicit approval.