What Is the Agent2Agent (A2A) Protocol?

Multi-agent AI only scales when agents built on different frameworks can communicate without custom code for every pairing. A2A provides that shared language, which lets enterprises connect specialized agents across vendors and clouds. It also creates new handoffs that security teams must govern with zero trust.

Enterprise AI adoption is moving fast, and organizations are extending its potential well beyond standalone chatbots or copilots. Instead, they are building fleets of specialized agents, each designed for a narrow function such as pulling data from a CRM system or drafting compliance reports. Bringing those specialized, disparate agents together is where security concerns escalate.

The Framework Patchwork Problem

Most multi-agent workflows are assembled inside a single framework, such as CrewAI, LangGraph, or AutoGen. That works fine until an organization needs to connect an agent from one framework to an agent from another.

Historically, developers could patch a connection with custom-coded REST APIs. This approach created three recurring problems:

• Every new agent pairing required its own bespoke integration.
• Each integration added a potential point of failure.
• Handoffs often went undocumented, buried inside application code.

Why This Patchwork Can’t Scale

Zscaler ThreatLabz research recorded a 91% year-over-year surge in enterprise AI transaction volume in 2025, across more than 3,400 active applications, nearly four times as many as the prior year.

Building a custom connector for every agent-to-agent dynamic in an environment that size introduces risk and expands the attack surface. Enterprises needed a shared language before the sprawl outpaced their ability to secure it.

A2A gives agents that common language, but it also gives security teams a new set of handoffs to govern with zero trust architecture.

How A2A Makes Agents Interoperable

A2A provides a universal, framework-agnostic communication standard that allows different AI agents to discover each other and collaborate without custom code for each pairing. Any agent, regardless of vendor or framework, can find another agent, check its capabilities, and hand off tasks through the same protocol.

Think of A2A as TCP/IP protocols for the agentic world. TCP/IP does not depend on the two endpoints sharing hardware or an operating system. It gives both a standardized way to exchange information.

Just as TCP/IP provided a common protocol layer across all types of devices, A2A provides a common protocol layer for AI agents. This means a LangGraph-based AI agent can negotiate tasks with a CrewAI-based AI agent without either having to write customized code for those particular agents.

This new layer changes the economics of deploying multiple agents. Instead of creating custom integration points between individual agents, organizations can connect their agents through one protocol and enable automatic discovery and negotiation.

That level of efficiency is exactly why security teams need to pay attention. A protocol built to make legitimate agent collaboration effortless makes illegitimate collaboration just as easy.

A2A defines every interaction through three fixed roles: the user, the client agent, and the remote agent. Each role carries a distinct responsibility and passes along a specific type of data as a task moves from the initial request to the completed result.

The Three Core Protocol Actors

• User: Sits at the top of the protocol chain. This is the human operator, or in some cases an automated service, who starts the workflow by defining a goal or submitting a request. The user hands that request to an agent built to manage it.
• Client agent: Accepts the user’s initial request and manages the entire transaction. This intermediary agent determines what remote capabilities are needed and forwards the request to the appropriate agent. It also authenticates the request before passing on any data and assumes responsibility for coordinating the operation.
• Remote agent: Executes the received task using its own private models and tools, then returns a completed result. To the client agent, it functions as a black box, with only its declared skill set and final output visible.

Discovery and the Standardized Agent Card

Before a client agent can delegate anything, it needs to find a remote agent and learn what that agent can actually do. A2A solves this with the agent card, a JSON document that functions like a digital business card for the agent. This discovery process happens in three steps:

1. The remote agent hosts its agent card at a standardized URI. A2A-compliant remote agents publish their card following RFC 8615, the internet standard that defines “well-known” URIs for discovering metadata on a web domain. Early implementations used the path /.well-known/agent.json, and the current A2A specification has since formalized this as /.well-known/agent-card.json.
2. The client agent requests the card. A client agent simply sends an unauthenticated HTTP GET request to that path and receives the full card in response, with no negotiation required to view it.
3. The client agent evaluates the card’s contents. The agent card lists the remote agent’s identity and supported capabilities. It details input and output modalities, defining what formats the agent can accept and return. Most critically for security teams, it declares the required authentication schemes, whether that means an API key, OAuth 2.0, or OpenID Connect.

This card is where discovery ends, and negotiation begins.

A2A uses existing transport protocols and adds a structured layer on top.

How Does A2A Handle Messaging and Asynchronous Tasks?

A2A uses JSON-RPC 2.0 over HTTPS for all messages.

Each A2A exchange is carried via HTTPS, and each payload is encoded as a JSON-RPC 2.0 message. A client agent can call methods like tasks/send or tasks/sendSubscribe. The remote agent will respond in the same simple, established format that has driven web-based APIs for years. There are no proprietary transports to try to reverse engineer and no obscure binary formats to analyze.

Most tasks do not complete immediately. A report generation job or a multi-step approval process could take minutes or even hours. A2A uses push notifications to handle these cases. A client agent provides a webhook URL, and the remote agent posts status updates to it whenever the task’s state changes, including while the client is disconnected. That keeps a serverless function or mobile application up to date.

When tasks require real-time monitoring, A2A supports Server-Sent Events (SSE) in addition to push notifications. Once a client subscribes to a stream, the remote agent will send TaskStatusUpdateEvent and TaskArtifactUpdateEvent messages to the client agent incrementally as the task progresses. This allows a client agent to monitor progress as large files are generated in real time, instead of waiting for a single, potentially long-running response.

What Are the Core Components of an A2A Task?

A2A organizes work into four data objects: tasks, messages, artifacts, and parts. Together, they define how work moves between agents, from the initial request through status updates to the final output. They also give each exchange a consistent format that any A2A-compliant agent can read.

• Tasks are the central unit of work, carrying a unique ID, a lifecycle status such as submitted, working, or completed, and a running history.
• Messages represent individual transactions within the conversation surrounding a task. They contain a role field indicating whether the User or an agent sent the message.
• Artifacts are the true outputs generated by a remote agent. Common examples of such outputs include documents and structured datasets.
• Parts are the atomic units of content within a message or artifact. They may contain plain text, references to files, or structured JSON data.

These components allow A2A to implement what’s called “opaque execution.” In opaque execution, agents view each other as black boxes. While an agent will share task status and final artifacts with other agents, it will never reveal how it arrived at those results.

By doing so, vendors protect their intellectual property. However, the client agent must extend trust exactly where it has the least visibility.

MCP connects a single AI model to its own tools and data, while A2A connects separate, autonomous agents to each other across systems and organizations. A2A is often compared to MCP, but the two protocols solve entirely different problems. Misunderstanding that difference can lead teams to build on the wrong layer.

The Tool-to-Model Layer vs. Agent-to-Agent Layer

Anthropic released MCP in November 2024 to solve a narrower problem: how a single AI model reaches beyond itself to query a database, call an API, or read a file. MCP standardizes that model-to-resource relationship. It’s like the wiring within a single agent, forming a connection from its brain to its hands.

A2A works at a layer above. It focuses on how two independent agents find each other and collaborate across organizational or vendor lines, not on how any one agent gets its data. In most production agentic systems, teams use both protocols together, with MCP providing internal tool connectivity and A2A enabling inter-agent communication.

The difference between these two protocols is especially relevant in security architecture. MCP risk relates to what data and tools a model has direct access to. A2A risk relates to trusting other organizations. That is because a remote agent operated by a partner or vendor performs tasks on behalf of an organization. The enterprise has limited insight into how a remote agent reasons.

A2A standardizes how agents communicate, not which agents deserve trust. That disconnect is where security teams need to concentrate their efforts.

The Danger of Opaque Execution

Concealing a remote agent’s internal logic protects a vendor’s intellectual property, but it also hides that agent’s behavior from the client agent. If a remote agent becomes compromised, such as being poisoned by a manipulated prompt or quietly swapped for a malicious clone, the client agent has no native way to detect it. It only sees a task status and a returned artifact, both of which can be forged convincingly.

The Speed of AI System Compromise

Agentic AI is increasingly automating cyberattacks, with AI agents taking on reconnaissance, exploitation, and lateral movement at machine speed. Enterprises transferred 18,033 terabytes of data to AI and ML applications in 2025, a 93% year-over-year increase.

The sheer volume gives attackers a much larger pool of AI traffic to hide inside, and defenders far less time to notice any single malicious request. The old assumption that security teams have time to investigate a potential incident no longer holds.

The numbers validate the concern. In red team testing, ThreatLabz found critical vulnerabilities in 100% of enterprise AI systems assessed, with a median time to first critical failure of 16 minutes. ThreatLabz red teaming experts were able to compromise 90% of enterprise AI systems in under 90 minutes, and the fastest bypass took a single second.

Implicit peer trust between agents in an A2A network, built on the assumption that a remote agent behaves as its agent card describes, is dangerous when compromise happens faster than any human can react.

Traditional network security assumes a defined perimeter, with trusted insiders on one side and threats on the other. A2A breaks that assumption entirely. Each remote agent in a workflow could be operated by a different vendor, hosted in a different cloud, and governed by a different security team. There is no perimeter to defend, only a constantly shifting mesh of agent-to-agent handoffs.

Zero trust fits this reality because it never assumes trust based on network location or a prior relationship. Every request gets verified on its own merits, every time, regardless of whether the requesting agent has connected before. Applied to A2A, this means a client agent’s identity, a remote agent’s declared capabilities, and the specific data in a task payload all get evaluated independently before a handoff is authorized.

This model also addresses the opaque execution problem discussed earlier. A2A does not give organizations visibility into how a remote agent reasons internally, and it likely never will, since that opacity protects vendor intellectual property.

No agent can see inside a remote agent’s black box. An inline position lets it govern the next best thing: what data and permissions move in and out of it.

Best Practices for Zero Trust and A2A

Zero trust principles translate directly into A2A architecture, and enterprises need to apply them at every handoff.

• Enforce rigorous, token-based mutual authentication. Every client agent and remote agent should verify identity using JSON Web Tokens (JWT) and OpenID Connect (OIDC), with the required scheme specified directly in the agent card rather than assumed.
• Deploy inline network monitoring to inspect JSON-RPC payloads in transit, not just at the endpoint.
• Configure fine-grained access control policies for every client-to-remote handoff. Scope each remote agent’s permissions to the narrowest set of actions it needs.
• Maintain a live inventory of every agent in the environment. Enterprises cannot secure remote agents they don’t know exist, and unregistered agents are a common source of shadow AI risk.
• Inspect encrypted A2A traffic, not just the handshake. A2A payloads travel over HTTPS, and encrypted channels can carry a data exfiltration attempt as easily as a legitimate task response.
• Apply data loss prevention policies to task artifacts. Any document, dataset, or file a remote agent returns should pass through the same sensitive-data checks applied to other outbound traffic.

Zero trust security preserves the efficiency of A2A. Agents still discover each other and negotiate tasks automatically, exactly as the protocol intends. Zero trust simply adds the identity checks, monitoring, and access limits that A2A lacks by default, so organizations gain security without giving up speed.

Zscaler enforces zero trust policy inline on every agent-to-agent handoff.

Zscaler does this through its Zero Trust Exchange™ platform, the same policy engine that processes 750 billion transactions daily. Zscaler AI Broker is positioned inline on every A2A and MCP communication and enforces fine-grained access controls at the moment an agent hands off a task.

An integrated Agent Registry gives security teams a governed inventory of every agent in the environment, showing exactly what each one is permitted to access. Paired with Zscaler AI Access Graph, the platform maps and secures agent-to-agent communication.

This is zero trust applied natively to autonomous agents, built into the architecture from the start. Zscaler enforces policy directly on multi-agent traffic, agent by agent, task by task.

To see the platform in action, request a demo.