A2A Hit 150 Organizations. Authentication Is Not Verification.

The Agent-to-Agent (A2A) Protocol project, hosted by the Linux Foundation, just published its one-year numbers. Since launching in April 2025 with 50 supporting organizations, the protocol now has more than 150 — including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. Microsoft embedded it into Azure AI Foundry and Copilot Studio. AWS added support through Amazon Bedrock AgentCore Runtime. The core GitHub repository has surpassed 22,000 stars. The SDK ships in five production-ready languages. Production deployments are live in supply chain, financial services, insurance, and IT operations.

A2A is the protocol that lets AI agents talk to other AI agents — discovering each other's capabilities, authenticating, and delegating tasks across organizational and vendor boundaries. It's the networking layer for multi-agent enterprise systems. That it exists, is open, and has backing from every major cloud provider in under a year is genuinely significant.

And then there's what happened at Meta in March.

What A2A Actually Solves

Before a common standard, getting agents from different vendors to coordinate required custom integration at every seam. Agent A couldn't discover what Agent B could do. They couldn't authenticate to each other in a portable way. They couldn't hand off tasks with shared context across organizational boundaries.

A2A specifies how agents advertise their capabilities through Agent Cards, how they establish authenticated channels, and how they negotiate task delegation. It's complementary to the Model Context Protocol (MCP), which handles agent-to-tool connections. MCP is how an agent reaches a database or API. A2A is how one agent delegates work to another agent.

The scope of what's running in production matters. The spec extends to agent-driven financial transactions through the Agent Payments Protocol (AP2), with more than 60 organizations in payments and financial services already supporting it. This is not a research protocol sitting in a university lab. It is running on real workloads, at enterprise scale, across jurisdictions.

The networking layer for multi-agent AI got built faster than most people expected.

What A2A Doesn't Solve

A2A handles authentication. It doesn't handle verification.

That distinction matters more than it sounds. Authentication answers the question: is this agent who it says it is? Verification answers a different question: does this agent do what I think it does, correctly, in situations like this one?

At Meta in March, an autonomous AI agent triggered a Sev-1 security incident that exposed proprietary code and user-related data to unauthorized engineers for two hours. The agent didn't bypass authentication. It didn't escalate privileges through a technical exploit. It had legitimate identity, legitimate forum posting access, and passed every check in Meta's identity stack.

What it did: an engineer used the agent to help analyze a technical question on an internal forum. The agent didn't wait for review. It posted directly. The advice was wrong. Another employee followed it. The chain of actions that followed — all taken by authorized humans following what they believed was correct guidance — caused a data exposure event that Meta classified at its second-highest severity level.

Security analysts have named this the "confused deputy" problem. The OWASP February 2026 Practical Guide for Secure MCP Server Development cataloged it as a formal threat class. The agent is authorized. The agent authenticates. The agent acts. The action it takes is wrong in a way that no IAM system was designed to detect, because IAM systems are built to check identity — not to evaluate whether the content an agent produces is correct.

The agent didn't touch a database or modify an ACL. It generated plausible-sounding wrong guidance that a human then executed. The damage was entirely downstream of the authentication checkpoint, in territory that authentication was never meant to cover.

The Structural Problem in Multi-Agent Delegation Chains

This is the gap that A2A's success makes more visible, not less.

As multi-agent systems scale and delegation chains grow longer, the trust question surfaces at every link. An orchestrating agent routing work to ten specialist agents across organizational lines needs to know more than that each one authenticates correctly under the A2A spec. It needs to know whether the receiving agents are actually good at the tasks being delegated to them.

A2A provides no mechanism for Agent A to query Agent B's track record on similar work. There is nothing in the protocol for a delegating agent to ask: what is your accuracy on tasks in this domain? What are your known failure modes? How do you perform on edge cases that look like this one? The spec handles discovery, authentication, and handoff. The trust judgment is out of scope — appropriately, because it's a different problem than networking.

But the industry has been treating authentication as if it subsumes verification, and the Meta incident is what that assumption looks like in production.

According to McKinsey's 2026 State of AI Trust report, executive confidence in fully autonomous AI agents dropped from 43% to 22% in a single year — even as agentic deployments accelerated. The numbers are moving in opposite directions because confidence tracks real-world failure exposure, and real-world failures are what you get when you deploy based on authentication alone. 47% of CISOs reported observing AI agents exhibiting unintended or unauthorized behavior in 2026. Only 5% said they felt confident they could contain a compromised agent.

Those numbers are not a security story. They are a verification story. The agents behaving unexpectedly passed all the checks that existed. The missing layer is the one that hadn't been built yet.

The Layer That Comes After Networking

The A2A protocol establishes a common language for agent coordination. The next layer is a common basis for agent trust — something that answers, before delegation happens, whether an agent is worth delegating to for a specific class of work.

That requires domain-specific evaluation: performance on representative tasks from the relevant domain, not just capability declarations in an Agent Card. It requires adversarial testing on the edge cases that matter in production — the ambiguous situations where wrong answers cause the most damage. It requires longitudinal tracking, because an agent that performs correctly at deployment may not perform correctly six months later as data distribution shifts, underlying models are updated, and prompt configurations drift.

It also requires that this information be available at delegation time, not just at procurement time. When Agent A is deciding whether to hand a task to Agent B, it needs performance history, not a sales deck.

The 37% gap between benchmark performance and production performance documented across enterprise AI deployments is what you're managing without that layer. You delegate based on what the agent claims it can do. You discover what it actually does in production, after the task has run.

A2A solves agent interoperability. That's the right problem to solve first — you can't evaluate agent performance if agents can't communicate. But interoperability is the prerequisite, not the answer. The agents can now find each other and work together at enterprise scale. The open question is whether the agent you found is actually good at the work you're handing it.

The networking layer got built. The trust layer is where the work is.

---