Multi-agent LLM systems fail in production at rates between 41% and 87%, with the majority of failures attributable to coordination defects rather than base-model capability. The instinct is to blame the stack - the wrong framework, the wrong model, the wrong orchestration pattern. But there is a more specific culprit that the current protocol debate mostly sidesteps: agents that can delegate to other agents without any mechanism for verifying what those agents will actually do.
That gap has a name now. It just does not have a clean fix yet.
What A2A actually solved, and what it left open
A2A's goal is to allow AI agents, built on different frameworks and by different vendors, to communicate securely, exchange information, and coordinate their actions to tackle complex tasks. It is designed as a complement to MCP, not a replacement. That framing is accurate and useful. A2A handles the coordination layer. MCP handles the tool access layer underneath. They solve adjacent problems at adjacent levels of the stack.
A2A advanced to v1.0.0 in January 2026, marking the transition from experimental to production-ready status, introducing signed Agent Cards for cryptographic verification, and codifying the discovery and trust mechanisms identified as gaps in earlier analyses. That is genuine progress. Signed Agent Cards use JSON Web Signature. A signed card carries a detached JWS that a client can verify against a known issuer public key - closing a class of impersonation attacks that plagued 0.x implementations, where an attacker could host a card claiming to be another agent's endpoint with no cryptographic recourse.
So identity: mostly solved. Capability verification: not close.
The A2A protocol's AgentSkill data model consists entirely of self-asserted string fields - id, name, description, tags - with no protocol-level mechanism for verification, attestation, or challenge-response validation. Client agents use these unverified claims to select downstream agents for task delegation. Put plainly: an agent can advertise itself as a billing specialist, a compliance reviewer, or a code auditor, and the protocol has no way to check. Agent Card signing authenticates identity but does not attest capability: it confirms who published the card, not whether the advertised skills are truthful. The specification provides no skill verification primitive.
The delegation chain is where accountability disappears
The trust problem compounds at depth. In a three-hop delegation - orchestrator → domain agent → specialist - credential providers cannot make informed authorization decisions, as the original principal's identity and the delegation chain are invisible to them. Intermediary agents receive forwarded credentials with no protocol-level restriction on misuse. An adversary controlling any intermediate agent can silently harvest credentials across repeated delegation chains.
This is not an edge case. It is the default behavior unless you build around it.
A2A creates a delegation governance problem, not just an interoperability problem. Once agents can hand work to other agents, the key question becomes who may delegate what, under which scope, and for how long. Existing IAM patterns were built around human-paced approval and relatively stable sessions. A2A shifts that authority into machine-to-machine flow, so the governance model must now account for cross-agent trust boundaries, not just single-actor authentication.
A known gap in A2A implementations is authorization creep, where agents discover required internal tools only after accepting a task, creating implicit permission checks. The correct pattern is to map OAuth 2.0 scopes to individual skills at the Agent Card level and enforce them at the gateway so permission verification happens before any work begins. Most teams enforce at acceptance, not at the gateway - which means an agent has already committed to a task before anyone knows whether it is allowed to complete it.
Beagle in action#ops-automation, routing a customer refund requestThe steelman: protocols are the right place to start
It is fair to argue that the protocol should not solve every governance problem. HTTP does not enforce rate limits; OAuth does not prevent bad authorization policies; TLS does not stop you from trusting the wrong certificate authority. Infrastructure standards set the vocabulary; enforcement is the application's job.
Security in A2A is a discoverable contract, not an enforced mandate. The Agent Card declares which schemes an agent supports; the protocol does not mandate that the agent actually verifies them. That means implementer discipline determines whether an A2A mesh is safe. If you accept that framing, A2A is doing exactly what it should.
The problem is that "implementer discipline" at multi-agent scale is not a reasonable ask for most teams. 79% of observed multi-agent failures originate from specification and coordination issues rather than base-model limitations. That number is not a model problem or a protocol problem - it is a design problem. Teams reach for multi-agent architectures before they have a clear model of who owns each decision and what happens when any agent in the chain exceeds its brief.
Simpler single-agent baselines, equipped with the same tools and the same retrieved context, often match or exceed multi-agent workflows at substantially lower cost. This is the finding nobody in the multi-agent ecosystem wants to quote. A four-agent pipeline accumulates roughly 950ms of coordination overhead while actual processing takes 500ms. A three-agent pipeline consumes 29,000 tokens versus 10,000 for an equivalent single-agent approach. If your pipeline does not need the specialization, you are paying 3x for the same result.
The argument for multi-agent is real: parallelism, specialization, the ability to mix models from different vendors for different parts of a job. Newer models like Sonnet 5 showed improved coordination capabilities in Anthropic's Frontier Red Team research - but systemic behaviors that emerge when multiple agents interact in real-world settings remain poorly understood. Better models help at the edges. They do not fix a delegation chain with no audit log.
What teams actually need to build on top of A2A
The protocol gives you the vocabulary. The governance layer is yours to build. A workable production stance has four components:
- Scope gates at the gateway, not at the agent. Enforce least-privilege scope at the gateway before task acceptance, not after. An agent that discovers it needs write access mid-task is already a problem.
- Delegation depth limits. Set a maximum hop count. A delegated task could exceed the user's authority. An agent could return poisoned artifacts. A chain of agents could make accountability unclear. Cap the chain before you find out which scenario you are in.
- Immutable task logs at every state transition. Log every Task state transition. If you cannot reconstruct which agent made which decision and under what scope, you cannot do incident response.
- Human approval for scope escalation. Hidden instructions and excess privilege travel through the chain when an agent reads a retrieved document or chat thread carrying an injected instruction, and holds an over-broad credential that lets the injected instruction execute with more authority than intended. A teammate like Beagle sitting inside the communication channel - where the task was triggered - is a natural checkpoint for surfacing those escalations before they run.
Multi-agent trust: common questions
What is the main security risk in A2A protocol deployments?
The biggest risk is not impersonation - signed Agent Cards address that. The harder problem is unverified skill claims and delegation chain opacity. Agents self-assert their capabilities with no attestation primitive, and credentials forwarded across multi-hop chains carry no protocol-level restriction on scope or reuse. Governance must be built in the application layer.
Does A2A v1.0 fix the trust problem?
Partially. A2A v1.0 introduced signed Agent Cards for cryptographic identity verification and codified discovery and trust mechanisms. What it did not fix: skill attestation, delegation depth tracking, and scope inheritance across hops. Those are implementer responsibilities, not protocol guarantees.
When does a single agent beat a multi-agent system?
More often than expected. Single-agent baselines equipped with the same tools and the same retrieved context often match or exceed multi-agent workflows at substantially lower cost. The case for multiple agents is parallelism and specialization - not complexity for its own sake. If your task is sequential and the agents share a model family, run a benchmark before adding the second agent.
What is authorization creep in multi-agent systems?
Authorization creep is when agents discover required internal tools only after accepting a task, which creates implicit permission checks. An agent commits to a job, then realizes mid-execution that it needs access it was never granted - and either fails silently or escalates in a way no one planned for. Fixing it means mapping scopes to skills before task acceptance, not during.
How many organizations support A2A today?
As of April 2026, more than 150 organizations support the protocol, including AWS, Google, Microsoft, Salesforce, and SAP, with production deployments across supply chain, financial services, insurance, and IT operations. Adoption is not the bottleneck. Governance tooling is.