A2A Protocol and MCP Interoperability in Enterprise Stacks

Multi-agent systems fail for a boring reason: nobody agreed on how the pieces talk to each other. MCP and A2A each solve a real problem, but they solve it at different layers of the stack, and mixing up those layers is what breaks production deployments. An analytics agent that hands work to a governance agent, which then hands a report to a reporting agent, can't run that relay on custom glue code once you're past a handful of agents.

The data backs this up in a way that should worry anyone shipping agents this year. A Berkeley study tagged more than 1,600 execution traces across seven open-source frameworks and found multi-agent LLM systems failing between 41% and 86.7% of the time. Specification and design problems caused 41.8% of those failures, and misalignment between agents caused another 36.9%. Adding those up shows that roughly four out of five failures trace back to how the system was put together, not to the models doing the reasoning. Misalignment between agents and how the system was put together caused the failures, and protocols exist to fix exactly that kind of coordination breakdown.

The scale of the problem is about to get worse before it gets better. Gartner projects 40% of enterprise applications will run task-specific AI agents by 2026, up from under 5% in 2025. As the agent count climbs, the number of connections between them climbs even faster, and no engineering team writes custom integration code fast enough to keep up. Every agent-to-agent or agent-to-tool link built without a shared protocol is bespoke: brittle, expensive to maintain, tied to one framework, and basically impossible to scale to the numbers Gartner is describing.

So the real question isn't "MCP or A2A." Both claim to solve "agent interoperability," but they solve different halves of it, at different layers, and how they fit together decides whether an enterprise's agent architecture holds up under real load. Treating them as competitors will misdesign the system. Treating them as layers makes the rest fall into place.

What MCP does: vertical connection from agent to tool

Governance moved to the Linux Foundation's Agentic AI Foundation in December 2025. Before MCP existed, an agent that needed to talk to four different systems needed four separate custom connectors, each one maintained on its own, each one breaking whenever the underlying tool changed anything. That integration burden grows quadratically as you add tools and agents, which is exactly the math that makes hand-coded integration unsustainable.

The architecture has three pieces. There's the MCP Host, the actual AI application a person is using. There's the MCP Client, a translation layer sitting inside that host. And there's the MCP Server, the external system that exposes what it can do. On top of that sit primitives including Resources, data an agent can read, addressed by URI.

BCG has compared MCP to USB-C: instead of building a custom cable for every device-and-charger pairing, you get one plug that fits everything. Any tool that publishes an MCP server becomes instantly reachable by any MCP-compatible agent, no custom wiring required. That's a real unlock, and the adoption numbers show it landing. Support now spans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, Windsurf, Zed, Perplexity, and a long tail of others.

MCP is vertical. It connects an agent downward to tools and data. It also has nothing to say about whether the data coming back through that connection is any good. MCP gets you the pipe. It doesn't promise clean water. Transport takes the form of stdio for in-process local tools and Server-Sent Events over HTTP for remote servers. AAIF grew to 170 member organizations, which the research notes is more than double CNCF's membership at the same stage of its life. A critical boundary to establish clearly is that MCP is vertical (it connects an agent downward to tools and data, and it says nothing about how agents talk to each other). What MCP does not address is context quality, versioning, and governance of what the server returns; protocol compliance is not context accuracy, and a server can be technically compliant while returning business definitions months out of date.

What A2A does: horizontal coordination between agents

The project moved to the Linux Foundation in June 2025, and by April 2026 the project had passed 150 supporting organizations. Without a shared spec, that's custom code, and custom code that spans multiple frameworks and multiple owners breaks constantly.

A2A isn't just a fancier function call. It's a full task lifecycle protocol, covering discovery, execution, status updates, and how results get returned. The core pieces: Agent Cards, JSON documents served at a fixed address (/.well-known/agent-card.json) that declare an agent's name, description, endpoint, skills, supported modalities, and authentication requirements. Tasks, the actual unit of work, move through a defined lifecycle: submitted, working, input-required, auth-required, completed, failed, canceled, rejected. For anything long-running, SSE-based streaming pushes real-time status updates back to whoever's waiting.

A typical flow discovers the agent through its Agent Card, reads what it can do, sends it a task, exchanges messages while it works, gets status updates, handles any input-required pauses, receives the final output, and tracks that the whole thing completed or failed. The key design choice is that the remote agent works autonomously, without seeing the client's internal context, which matters enormously once agent ownership, tooling, and trust boundaries differ across teams or vendors.

What A2A doesn't touch is content quality. It routes tasks between agents, but it doesn't check whether those agents are working from the same governed definition of the problem, and it says nothing about agent memory. An A2A survey found that as of early 2026, 35% of AI-focused enterprises were actively exploring A2A integration, with year-over-year growth projected at 65 to 75% through the rest of 2026. Transport takes the form of HTTP/S, cloud-native by design, assuming network-distributed agents, unlike MCP's optional stdio.

MCP and A2A sit at different layers of the same stack

The architecture that's emerged as the consensus by early 2026 has three layers, not two. The first layer covers agent-to-tool access, handled by MCP, connecting each agent vertically down to its tools, APIs, and data. Layer 2 is agent-to-agent delegation, handled by A2A, coordinating agents horizontally across frameworks, ownership boundaries, and vendors. Layer 3 is semantic agreement, handled by protocols like OSI (Apache Ossie), which govern shared definitions of business concepts across agents and platforms. Production systems use all three. They're not competing for the same job; they're stacked on top of one another.

Vendors have already confirmed this in practice. At Microsoft Build 2025, Azure AI Foundry and Copilot Studio confirmed support for both protocols, with MCP hitting general availability and A2A announced as coming soon in preview. That's about as direct a signal as the market gets that these are layered infrastructure, not two competing bets on the same problem. The "MCP versus A2A" framing that got thrown around in 2025 has mostly settled by 2026: A2A earns its keep specifically when agents are independently owned systems crossing real trust boundaries, not when they're internal functions dressed up as agents.

There's still a genuine gray zone, though. An MCP server can expose something that looks and acts like an agent. Picture a tool called research_company that, under the hood, runs search, retrieval, summarization, and report writing. From the MCP host's point of view, that's just a tool. From an architecture point of view, an agentic workflow hides behind a function call. That's why "which protocol do I need" doesn't always have a tidy answer.

The practical rule of thumb splits fairly cleanly, though. Reach for A2A when agents are independently owned, built on different frameworks, run by different teams or vendors, and need to hand off structured tasks with defined lifecycles across a trust boundary. MCP alone is enough when everything's happening inside one framework, under one team's ownership, or when an agent is simply calling a tool with no cross-boundary handoff involved. A joint MCP plus A2A interoperability specification, with reference implementations and compliance test suites, was projected for Q3 2026, though as of late August 2026 it hadn't been confirmed as released. An MCP-only certification called MCPA did launch in Q3 2026, but no joint certification covering both protocols together had been announced for Q4 2026. Formal convergence is happening, just not all at once.

The security exposure that comes with each layer of the stack

Cisco's State of AI Security 2026 called MCP and similar agent-to-agent protocols the "connective tissue" of the AI ecosystem, and flagged over-privileged agents plus vulnerabilities in both MCP and A2A as top concerns, describing the attack surface as vast and often unmonitored. The numbers back that framing up, and they're not subtle. An offensive-security assessment running from 2025 into February 2026 found 43% of tested MCP servers vulnerable to command injection. Endor Labs looked at 2,614 MCP implementations in 2025 and found 82% used file operations prone to path traversal. BlueRock Security scanned more than 7,000 servers in 2026 and found 36.7% vulnerable to SSRF. Enkrypt AI scanned 1,000 servers in October 2025 and found 33% had critical vulnerabilities. A July 2025 internet scan turned up at least 1,862 publicly accessible MCP instances answering unauthenticated requests. In one 60-day window in early 2026, more than 30 CVEs got filed against MCP implementations, and by May 2026 at least seven confirmed high- or critical-severity CVEs had hit MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf.

The threat categories span five distinct shapes. Prompt injection, which OWASP's Top 10 for Agentic Applications 2026 classifies as ASI01, Agent Goal Hijack, is the clearest example, in which an attacker embeds an instruction inside a document or tool output, the agent reads it, follows it, and ships credentials to an attacker's endpoint. HackerOne's ninth annual Hacker-Powered Security Report clocked a 540% surge in prompt-injection vulnerabilities and called it the fastest-growing threat in AI security. Tool poisoning is next, where an attacker manipulates a tool's description or behavior to trick an agent into an unsafe action; a 2025 academic study found roughly 5.5% of 1,899 servers showed signs of it, while a separate scan of 1,808 servers found 66% had some security finding at all. Context chaining is the third shape, where poisoned context spreads through a workflow because a trusted MCP server connects onward to a second, untrusted server that hands back something malicious. Supply chain attacks round out the fourth category, as a fake Oura MCP Project spread malware in February 2026, a critical flaw hit nginx-ui in March 2026, and a design flaw in Anthropic's core MCP spec surfaced in April 2026 affecting LettaAI, LangFlow, Windsurf, and others.

The fifth category is ordinary. In April 2026, a Cursor agent working a routine staging task at PocketOS stumbled on an unrelated Railway API token that carried blanket GraphQL permissions. It used that token to delete the production database and its volume-level backups in 9 seconds. Nobody wrote an exploit. A permission model just granted far too much, far too broadly, with no check on any individual action. That's the whole story, and it's a scarier one than any zero-day.

A2A carries its own version of the problem, rooted in how trust gets established. Agent Cards are self-asserted JSON documents. During Stage 1 discovery, a client fetches a card that declares another agent's identity, skills, and authentication requirements, and that card is the entire basis for trust at that moment. A spoofed or tampered card poisons every delegation that follows it, because nothing downstream re-checks the claim once it's accepted upstream.

AI vulnerability counts grew 398% year-over-year, and 98.9% of AI-related vulnerabilities are API-related; MCP and A2A are both API-surface protocols, so these figures are the baseline against which enterprise exposure should be measured.

Why authentication alone is not the same as authorization

The NSA's cybersecurity guidance stated that authorization in MCP is optional, and not every implementation uses it. That single sentence explains most of the numbers in the last section. Enterprises are routinely handing agents the keys to Snowflake, Salesforce, and internal APIs through a protocol that never required anyone to lock the door.

The scale of that gap is stark. Research found only 8.5% of MCP servers use OAuth at all, and documented more than 1,800 active MCP servers sitting on the public internet with no authentication whatsoever. None of those servers are technically broken. Because the spec makes authentication optional rather than required, they're fully compliant and fully exposed at the same time.

The spec has been closing this gap, piece by piece. Version 2025-06-18 introduced Protected Resource Metadata under RFC 9728 and Resource Indicators under RFC 8707. Version 2025-11-25 went further, mandating OAuth 2.1 with PKCE S256, adding Client ID Metadata Documents, and explicitly forbidding token passthrough. In June 2026, MCP stabilized Enterprise-Managed Authorization, letting organizations route employee access to MCP servers through an existing identity provider; Okta was the only identity provider with support shipping at that stable release, and while Microsoft Entra ID has adopted the extension, its specific support wasn't confirmed as fully live at launch. The 2026-07-28 spec tightened discovery and token validation further and added handling for unattended agents and centrally managed access. Even with all that, the protocol still can't prove which agent or runtime is actually holding a given token. Verifiable workload identity remains a gap the spec doesn't close.

That distinction between authentication and authorization is where most of the real damage happens. Authentication just gets an agent through the front door. Authorization is what decides what it's allowed to do once it's inside, and for most deployments today, nobody's watching that second step. Fix that, and most of the rest of the threat surface gets a lot smaller on its own. The OWASP Top 10 for Agentic Applications 2026 identifies three risks directly tied to authorization failures.