Agent to Agent Protocol (A2A)

What Is Agent2Agent Protocol (A2A)?

Agent2Agent (A2A) is an open interoperability protocol that allows autonomous AI agents to collaborate across different platforms and vendors. It is sometimes referred to informally as the agent-to-agent protocol.

A single AI agent can handle a narrow task effectively, but complex workflows require specialized, multi-agentic teams. That often looks like one agent researching, another drafting and a third reviewing. A2A is the shared communication layer that enables agents to collaborate seamlessly.

Google announced the A2A protocol on April 9, 2025, with more than 50 technology and services partners committing to adopt it, including Atlassian, Salesforce, SAP, ServiceNow and Workday. Google subsequently donated the project to the Linux Foundation, where it is maintained under the Apache 2.0 license.

The protocol builds on existing web standards (HTTP(S), Server-Sent Events (SSE), and JSON-RPC 2.0) rather than inventing new transport layers. It allows agents to interact synchronously, stream responses in real time or receive asynchronous push notifications for long-running tasks that may span hours.

Core Components of A2A

Every A2A interaction involves a small set of core components that agents use to find one another and coordinate work.

• Agent Card: A JSON metadata document that an agent publishes to advertise its capabilities, supported authentication schemes and endpoints. This is how a client agent discovers what a remote agent can do before initiating a task.
• Task: The fundamental unit of work. A client agent creates a task, tracks its lifecycle and receives artifacts when it finishes.
• Message: The turn-based content exchanged within a task. Messages include questions, instructions, status updates and clarification requests between agents.
• Artifact: The structured output produced when a task completes. This may be text, files or JSON data.

The A2A protocol defines three primary actors: the User who initiates work, the Client Agent that sends tasks and the Remote Agent that fulfills them.

A2A vs. MCP: How They Fit Together

A2A and Model Context Protocol (MCP) address different layers of the same stack. They are complementary, not competing. The following table sets out the purpose and typical use case for each protocol:

A practical multi-agent system often uses both: MCP gives individual agents access to tools and data sources, while A2A governs how those agents hand off tasks to one another.

But even joint A2A and MCP adoption isn’t enough to govern agents. As recent security research explains, “An authentication vulnerability in the A2A layer could be exploited to gain unauthorized MCP access, while sensitive information exposed through inadequately protected MCP connections might enable subsequent A2A-based compromises.”

The research concludes that an effective security strategy must encompass MCP, A2A and every intersection of the two, along with those of any other protocols in place.

Security in A2A

Built-In Security Features

A2A provides enterprise-grade security controls from the outset. Agents publish Agent Cards to show how they verify incoming requests before any data is sent. All communication is encrypted over HTTPS with TLS, and access relies on short-lived, task-scoped tokens rather than long-lived secrets.

Security Risks and Gaps

The protocol’s design also comes with significant security gaps.

A2A does not mandate cryptographic verification of Agent Cards, which means a rogue agent can publish a fraudulent card claiming capabilities it does not have. The Cloud Security Alliance’s MAESTRO threat model for A2A identifies unauthorized agent impersonation, message injection and protocol downgrade attacks as high-priority risks.

The protocol delegates credential management entirely to implementers. Without additional controls such as signed Agent Cards, mutual TLS (mTLS) or PKI-backed machine identities, replay attacks, card tampering and agent-in-the-middle attacks remain live risks.

How to Mitigate A2A Security Risks

While the agent-to-agent protocol is considered a safe standard for agentic collaboration, it’s not enough on its own. But the solutions required to fill the gaps can seem overwhelming:

• Attested Identities: Encrypted, hardware-bound identities are impossible to impersonate or use on other devices.
• Scoped Credentials: Short-lived, identity-based, context-aware credentials such as SVIDs prevent agents from claiming unauthorized capabilities.
• Identity and Access Management (IAM): Many organizations already have IAM for users and devices, but not all systems accommodate agentic speed or scale.
• Mutual Authentication: Agent-to-agent authentication through mutual Transport Layer Security (mTLS) verifies both cryptographic identities and task scope before data exchange.
• Certificate-Based Authentication: Digital certificates aren’t vulnerable to credential theft or replay attacks, unlike traditional credentials and tokens.
• Active Revocation: Short-lived X.509-SVIDs and live posture signals revoke rogue agent access in minutes, not hours or days.

But most of these needs can be met through a robust certificate lifecycle management tool.

“Certificates make sure that a hacker can’t just steal a token, or impersonate another agent, or get access to a certain amount of data,” explains Micah Spady, Product Marketing at SecureW2. “They also allow companies to say, ‘I know for sure that this is my agent that’s accessing a certain resource.’ That’s why the industry is starting to adopt SVIDs.”

One managed PKI can handle every entity in your environment: issuance, renewal and revocation for agents, workloads, devices and users, all in one system.

Related Terms

Frequently Asked Questions