On March 12, 2026, the A2A protocol reached v1.0.0, providing the first stable open standard for agents to discover one another and coordinate work across framework and vendor boundaries.
This gives teams a clean way to route tasks between autonomous agents. But the specification solves communication only. Because v1.0.0 deliberately omits built-in authorization, deploying these systems with broad OAuth scopes risks downstream data leaks and agent impersonation.
This article covers the primitives of the v1.0.0 spec, how A2A differs from the Model Context Protocol, and what authorization actually needs to look like when agents call agents.
TL;DR
-
The A2A v1.0.0 standard uses Agent Cards, Tasks, and Messages to map discovery and long-running execution across agent frameworks.
-
MCP handles agent-to-tool connections; A2A handles agent-to-agent coordination. The two create overlapping infrastructure concerns for platform engineers.
-
A2A deliberately leaves authorization out of the protocol, exposing networks that rely on standard API gateways to context poisoning and typosquatting attacks.
-
Broad OAuth tokens cannot constrain autonomous sub-agents that recursively route data through multiple services.
-
Securing production deployments requires authorization that evaluates permissions at the individual task and document level, not just at the network boundary.
How the v1.0.0 architecture standardizes cross-agent communication
Agents initiate discovery by publishing an Agent Card. The JSON metadata document sits at /.well-known/agent-card.json and defines an agent's identity, endpoint URL, available skills, streaming capabilities, and required security schemas. When your application needs to delegate a task, it pings the target agent's card to understand precisely how to format the request:
{
"name": "logistics-agent",
"description": "Routes shipments and provides delivery status updates.",
"version": "1.0.0",
"supportedInterfaces": [
{
"url": "https://api.logistics.example.com/a2a",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"capabilities": { "streaming": true, "pushNotifications": true },
"defaultInputModes": ["text/plain"],
"defaultOutputModes": ["text/plain"],
"skills": [
{
"id": "shipping-routing",
"name": "Shipping Routing",
"description": "Selects optimal carrier and route for a shipment.",
"tags": ["logistics", "routing"]
}
]
}
With the payload retrieved, the calling agent can authenticate the session dynamically before initiating any long-running workflows. Once connected, work revolves around Tasks. Tasks act as the durable units for long-running processes, while Messages serve as the conversational turns within those tasks. The invoking agent creates a Task and exchanges simple Messages, giving the executing agent time to reason, scrape data, query databases, or contact other agents before returning explicit outputs as Artifacts.
Google introduced A2A on April 9, 2025, as an open protocol for agents to discover one another and coordinate work. After moving under the vendor-neutral Linux Foundation umbrella on June 23, 2025, the standard reached v1.0.0 on March 12, 2026, marking stable enterprise readiness. As of April 9, 2026, the protocol boasts support from over 150 organizations, including integrations across Google, Microsoft, AWS, and IBM.
To transmit data effectively, the protocol supports multiple transports, including ordinary HTTP, JSON-RPC 2.0 semantics, WebSockets, and Server-Sent Events for real-time output streaming. Developers building the connective tissue also have official SDKs available across Python, Go, JavaScript, Java, and .NET environments, alongside an official Inspector tool and a Test Compatibility Kit (TCK).
This raises a practical question: how does A2A interact with existing frameworks for agent tooling?
The boundary between A2A and the Model Context Protocol
Developers often blur the line between these frameworks, but their functions differ conceptually. While the Model Context Protocol (MCP) standardizes governing agent-to-tool connections by dictating how a single agent connects to your internal databases and APIs, the A2A protocol governs how autonomous agents coordinate externally with each other.
Official documentation declares them complementary. The theory suggests you use MCP for internal resource connection and A2A for general routing. A sales representative agent uses MCP to check internal inventory databases, and then uses A2A to message a distinct supply chain agent owned by your logistics vendor.
The reality in production proves messier. Running two parallel agent protocols creates operational overhead: separate authentication flows, separate error handling, and separate security audits. Solomon Hykes has noted the friction developers face when choosing between the two ecosystems. When teams duplicate security patterns across both specifications, a misconfiguration in one protocol can go unnoticed if testing focuses on the other.
Since A2A handles cross-boundary coordination using standard JSON and HTTP, infrastructure teams frequently assume they can guard the endpoints using traditional API gateways. Perimeter defenses alone are insufficient for generative workflows because standard security protocols cannot evaluate AI intent.
Why standard perimeter security fails generative workflows
Many engineering teams treat A2A connections like traditional microservices, deploying mutual TLS, IP allowlists, OAuth 2.0 flows, and rate limiting. These methods ignore the reality of autonomous systems: perimeter defenses cannot evaluate what an agent intends to do with its access.
The design deliberately offloads security to external infrastructure, using securitySchemes in the Agent Card to defer authorization to underlying web standards. Consequently, teams relying solely on broad OAuth implementations expose their networks to security gaps in agentic AI architectures. When you leave the protocol to self-police, bad actors bypass basic authentication quickly.
Malicious actors exploit the baseline security through several specific attack vectors:
-
Malicious cards inject deceptive instructions directly into the discovery phase during context poisoning attacks.
-
Impersonators mirror legitimate endpoints to intercept confidential queries.
-
Typosquatting takes advantage of popular framework names to redirect requests.
-
According to Orca Security, misconfiguring A2A and MCP servers by binding them to 0.0.0.0 or openly exposing their context endpoints can leak sensitive data directly to the public web.
Security researchers at Palo Alto Networks' Unit 42 assess that unprotected Agent Cards remain vulnerable to deceptive instructions and shadowing via customized descriptions and skills. A rogue card embeds prompt injections directly into the discovery phase. A developer might spell a popular analytics agent incorrectly, pointing the network request toward an impersonator.
When a poisoned agent bypasses the network perimeter and exploits an authenticated connection, the critical vulnerability shifts away from the gateway and directly onto how the underlying protocol handles token permissions.
The delegated execution problem in multi-agent networks
An employee asks their primary HR agent to summarize available vacation days. The agent instantly spins up a sub-agent to query the internal payroll database, passing along the employee's broad OAuth token to authenticate the request.
From the database's perspective, the sub-agent is the employee. It has read access to everything the employee can legally see. Suddenly, the sub-agent encounters a poisoned Agent Card disguised as a standard payroll function.
The directory becomes compromised. The sub-agent autonomously searches the enterprise system, pulling out every available social security number and compensation record.
Generative agents autonomously chain requests in unpredictable ways. Broad OAuth scopes fail to separate permissions between the initial user prompt and the recursive sub-agent task. Broad token architectures expose data because they cannot limit the depth of an AI query.
March 2026 research confirms that standard protocols lack native identity provenance and verification mechanisms for delegated executions. The token proves who originated the request, but gives zero indication of how many autonomous loops occurred during execution.
If standard tokens create over-privileged autonomous actors, securing execution requires an architectural layer that restricts access at the individual task and document level.
Constraining agent access at the document level
The delegated execution problem highlights a structural gap: tokens prove who started a request but cannot limit what autonomous sub-agents do with that access. Closing the gap requires authorization that evaluates every query against the specific relationships between the agent, the task, and the target data.
Relationship-based access control (ReBAC) models permissions as a graph of relationships rather than flat role assignments. Instead of asking "does this token have read access?", a ReBAC system asks "does this specific agent, performing this specific task, have a relationship to this specific document?"
Return to the HR scenario: when the primary agent spawns a sub-agent to check vacation balances, a ReBAC layer enforces that the sub-agent's queries are scoped to vacation records only. The sub-agent holds a relationship to the vacation-summary task, and that task holds a relationship to vacation data, not to compensation records or SSNs. Even if the sub-agent encounters a poisoned Agent Card, it cannot read data outside its task boundary because no relationship path exists.
This model fits A2A's architecture naturally. Each Task in the protocol already represents a discrete unit of work. ReBAC extends that boundary into the data layer, so the executing agent's permissions expire with the task rather than persisting across the session.
Google's internal authorization system, Zanzibar, pioneered this approach for managing permissions across billions of users. AuthZed implements the Zanzibar model as an infrastructure layer, evaluating fine-grained permissions in milliseconds so authorization checks do not become a bottleneck in real-time agent coordination.
Building safe boundaries for agent communication
The A2A protocol works because it refuses to dictate infrastructure, giving engineering teams the freedom to construct multi-agent networks across any vendor boundary. That agnosticism also means the protocol cannot protect what flows through it.
Perimeter security handles authentication. Relationship-based access control handles what happens after authentication: which agent can touch which data, for how long, and under what task context. Teams moving past proof-of-concept deployments need both layers in place before agents reach production.
A2A establishes the connection. The authorization layer determines what that connection is allowed to do.
FAQs
How does an Agent Card work in the A2A protocol?
The Agent Card is a machine-readable JSON metadata document at /.well-known/agent-card.json. It declares the agent's endpoint URL, supported protocol bindings, available skills, streaming capabilities, and required authentication schemes.
What is the difference between A2A and MCP?
The A2A protocol standardizes external communication between distinct autonomous agents operating across different frameworks. The Model Context Protocol (MCP) securely manages internal connections between a single agent and your underlying databases or file systems.
Why are common OAuth scopes dangerous for multi-agent communication?
Broad OAuth scopes grant user-level permissions to agents without task-level restrictions. Because agents chain requests autonomously, a token with wide read access lets an agent query resources unrelated to its original prompt.
What is context poisoning in a multi-agent system?
Context poisoning occurs when a malicious actor embeds deceptive instructions directly into an Agent Card's description or skill array. When an unprotected secondary agent reads the poisoned discovery file, the hidden prompts hijack its logic and divert the authorized workflow.
How do you authorize sub-agent tasks securely?
Traditional perimeter defenses verify identity but cannot restrict what an autonomous sub-agent does after authentication. Relationship-based access control (ReBAC) addresses this by modeling permissions as relationships between agents, tasks, and data. Each sub-agent receives access scoped to its immediate task, so even a compromised agent cannot query resources outside that boundary.