A2A Protocol and MCP Interoperability in Enterprise Agent Architectures

Enterprise AI stopped being about a single chatbot years ago, at least in any deployment that matters. That last part is the catch. The integration surface grows faster than any team can hand-code it: an analytics agent on LangChain handing data to a governance agent on LlamaIndex, or a Copilot Studio orchestrator delegating to an on-premise private-LLM agent, each requiring custom connectors without shared standards. Multiplying that across a dozen agents makes the integration surface grow faster than any engineering team can hand-code it.

The stakes are not hypothetical. The Berkeley MAST study annotated execution traces across seven open-source multi-agent frameworks and found these systems failing at high rates, with specification and design issues plus inter-agent misalignment accounting for roughly four out of five of those failures. In other words, the agents work fine individually. The system around them doesn't. Gartner projects that by 2026, roughly two out of five enterprise applications will carry task-specific AI agents, up from under five percent in 2025, turning the integration problem into a right-now concern. Connecting n agents to m tools without a shared standard requires building n times m custom bridges. A protocol layer collapses that to n plus m. That arithmetic is why the industry stopped debating whether shared standards were necessary and started arguing about which ones.

MCP and A2A solve different problems

The 2026 enterprise AI stack settled on two protocols, not one, because they operate at different layers and solve different problems. Model Context Protocol handles the vertical edge, connecting an agent down to its tools. Agent2Agent handles the horizontal edge, connecting one agent across to another. Major enterprise vendors have already built production architecture around this exact division of labor, a pattern examined in detail further down.

MCP was introduced by Anthropic in late 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025. It's a client-server architecture built on JSON-RPC 2.0, defining three primitives: Tools, which are actions an agent can invoke; Resources, which are data an agent can read; and Prompts, which are templated instructions. Once a tool publishes an MCP server, any MCP-compatible agent can reach it immediately, which erases the need for a custom connector per tool. Transport runs over stdio or HTTP with Server-Sent Events, covering both synchronous requests and event-driven workflows. The industry nickname for it, "USB-C for AI," captures the intent well: one universal adapter between agents and whatever tools, APIs, or data sources sit behind them, regardless of how those systems were built. Adoption backs up the metaphor. Client support spans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, and SDK downloads reached close to half a billion per month by July 2026, with the TypeScript and Python SDKs each crossing a billion total downloads.

A2A comes from a different lineage. It runs on HTTP, Server-Sent Events, and JSON-RPC, all standards enterprise IT departments already have wired into their stacks. A2A gives agents four capabilities: capability discovery through Agent Cards (JSON files published at a known URL declaring an agent's skills, supported data formats, transport bindings, and security schemes), task delegation, multi-turn dialogue, and an eight-state task lifecycle for tracking work as it crosses agent boundaries. A2A reached v1.0 in March 2026, and v1.0.1 introduced an extension mechanism supporting new data types, requirements, RPC methods, and state machines. The founding partner list for the Linux Foundation's stewardship reads like a cross-section of enterprise infrastructure: Amazon Web Services, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow, with a large number of additional enterprises signing on as supporters by February 2026.

None of this makes MCP and A2A rivals. They're complements, and production multi-agent systems lean on both at once: A2A routes a task to the specialist agent equipped to handle it, then MCP hands that agent the context and tools it needs to actually do the work. A third layer exists: OSI (now Apache Ossie, incubating), which standardizes the exchange of semantic model definitions, metrics, dimensions, and relationships, across analytics, AI, and BI platforms, relevant to note but not the focus here. That's a semantic-layer problem, while MCP and A2A establish the conceptual foundation the rest of this piece depends on, a complementary two-protocol stack rather than competing systems, and that stack is where this piece stays.

How A2A and MCP interoperate in production

Putting the two protocols side by side in an actual deployment makes the division of labor concrete. A2A handles orchestration across the boundary between agents. MCP handles tool access within a single agent's own scope. A single workflow typically runs both, one after the other.

The pattern looks like this in practice: an orchestrator agent receives a task too complex for any one specialist to handle alone. It uses A2A to read Agent Cards, find the specialist agents suited to each piece of the job, and delegate accordingly. Each specialist then turns to MCP to pull whatever data or tool access it needs to finish its slice of the work, and once it's done, results flow back up the A2A chain to the orchestrator. An orchestrator agent uses A2A to discover and delegate to specialist agents via their Agent Cards, and each specialist agent then uses MCP to reach the tools and data sources it needs to complete its subtask, with results flowing back up the A2A chain.

SAP's reference architecture, published in August 2026, is the clearest documented example of this pattern running in a live enterprise environment. Joule, SAP's assistant, acts as an A2A client that communicates with external agents, while those agents in turn use MCP to discover and pull tools from MCP servers. SAP built this out across three separate governed channels. The Agent Gateway, running on the A2A protocol, handles multi-agent collaboration where an outside client or third-party agent delegates work to SAP-managed agents, covering secure communication and cross-vendor task delegation. The MCP Gateway inside SAP Integration Suite governs the exposure and consumption of SAP and non-SAP APIs as MCP-compliant tools, covering the full lifecycle from creating MCP servers out of existing APIs to securing, monitoring, and governing agent access at scale. A2A connectivity within Integration Suite then adds traffic management, event-driven patterns, and payload transformation for governed multi-party interaction between SAP and third-party agents, layered on top of the Agent Gateway's base security. SAP notes that bidirectional communication with third-party and self-hosted agents through the Agent Gateway is not yet generally available, so the architecture is still mid-transition.

The design rationale SAP makes explicit generalizes: separating A2A (agent coordination) from MCP (tool access) prevents monolithic agent design, promotes reusability, and keeps the ecosystem open to agents built by different teams and vendors. The decoupling matters for maintainability, too. Tools can be versioned and deployed independently of the agents that consume them, and agents don't need to know a tool's underlying implementation, REST, OData, or function. A2A's Agent Card model runs the same decoupling logic on the discovery side: an agent publishes what it can do at a known URL, and an orchestrator finds it dynamically rather than through a hardcoded routing table that breaks the moment something changes.

Where the protocols stop and governance risk begins

MCP and A2A are stateless communication standards that answer which agent can handle this task and how an agent reaches a given tool. Neither protocol was built to track what an agent actually did once it got access, what data it touched, who signed off on the action, or whether any of it complied with a policy somewhere. It's a boundary the protocols were drawn around on purpose, and the distinction between a gap that can be extended away and a gap that requires a new architectural layer entirely is the whole crux of the enterprise governance argument.

A systematic gap analysis of MCP v1.1 and A2A v1.0.1, published in June 2026, applied a six-dimension governance taxonomy: membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. It found voting and dissent preservation universally absent across all five major agent protocols it examined, deliberation absent or at best partial, and no protocol anywhere encoding the full set of primitives a genuinely governed agent community would need. The paper's more important contribution is the distinction it draws between extensible gaps, the kind a protocol can absorb through its own extension mechanism, and structural gaps, which need an entirely new layer built above the protocol rather than bolted onto it. Governance falls into the second bucket. A2A's own four official example extensions, Secure Passport, Timestamp, Traceability, and Agent Gateway Protocol, confirm exactly where that design boundary sits: not one of them addresses governance in the sense an enterprise compliance officer would recognize. MCP's own 2026 roadmap says the same thing about itself, naming audit trails, enterprise-managed authentication, and gateway or proxy patterns as gaps the protocol has no intention of filling on its own.

That's a design choice with consequences already visible in the field. Independent scans conducted in 2026 found large numbers of MCP servers sitting exposed to the open internet, a substantial share of them running with no authentication whatsoever. Nobody currently answers the lifecycle questions that follow from that exposure: who owns deploying those servers, who updates them, who monitors whether they're healthy, and who decommissions them once the API underneath has changed. Coordination and governance are different disciplines answering different questions. Coordination asks which agent can perform a task. Governance asks how agents should collectively decide what to do, and who answers for it when the decision goes wrong. Enterprises need both. Only the first one ships inside the protocol.

The threat surface that opens when agents operate without a governance layer

It is documented, growing, and categorically different from traditional application security.

Prompt injection sits at the center of it. An agent that holds access to private data, gets exposed to untrusted content, and can communicate outward is an agent that a successful injection can turn against its own operator, leaking data, bypassing safety controls, or triggering actions nobody authorized. Confirmed findings have been documented against Slack AI, Microsoft 365 Copilot, Cursor, GitHub MCP, and AI coding assistants. In May 2026, the Five Eyes intelligence alliance, meaning CISA and the NSA alongside counterparts in the UK, Canada, Australia, and New Zealand, issued joint guidance on agentic AI naming prompt injection as a core attack vector and warning explicitly that no single safeguard covers it on its own. The OWASP GenAI Security Project's tracking of agentic security tells the same story from a different angle. Its 2025 edition catalogued threats that were mostly plausible scenarios. The 2026 edition, version 2.01, catalogues actual CVEs, vendor advisories, and breach reports attached to nearly every category of agentic risk it lists.

Data leakage through system prompts runs on a parallel track. OWASP added System Prompt Leakage as its own distinct risk category, and the actual danger there has nothing to do with the prompt text leaking, everything to do with the secrets and authorization logic teams carelessly stash inside that prompt. Any credential written into a system prompt should be treated as compromised the moment it's written, full stop, and authorization needs to run through deterministic controls sitting entirely outside the model's reach.

Shadow AI stacks another layer on top of all of it. The average organization now runs dozens of deployed agents, and that count climbs every quarter as individual teams spin up their own automation without routing it through any central review. Breaches originating from shadow AI cost more to clean up than standard incidents and take longer to catch, which is the identical pattern unmanaged SaaS followed before IT departments finally built governance infrastructure to rein it in. A specific variant of the same problem is the orphaned agent: deployed without central oversight, then left running with live credentials after the workflow it served has changed or the project has ended, becoming a persistent, unmonitored access path into enterprise infrastructure that nobody owns anymore. Identity infrastructure hasn't caught up either. Okta's 2026 blueprint lays out the standard enterprise agents should meet: a unique non-human identity separate from whichever human triggered the workflow, authentication through cryptographic credentials tied to the agent's specific role, and short-lived credentials in place of static service accounts that sit valid indefinitely. Most deployments running today fall short of that bar. Every one of these risks traces back to the same root cause: the protocols coordinate agent behavior competently and audit none of it.

The MCP gateway as the emerging infrastructure response to the governance gap

An infrastructure category has grown up specifically to close that gap: the MCP gateway, a control layer sitting between AI agents and the MCP servers they call, providing exactly the oversight the protocol was never built to include on its own.

Authentication and authorization get centralized through OAuth 2.1, OIDC, and SSO, with identity propagated per user. Access controls apply at the tool level through allow-lists and role-based filtering, so an agent only reaches the specific tools its role calls for. Every tool suggestion, approval, and execution gets logged into an audit trail, closing precisely the accountability hole the base protocols leave open. Gateways route traffic across multiple downstream MCP servers, provide observability through metrics, logs, and distributed traces, and run threat protection tuned for this specific environment, catching tool poisoning attempts and unauthorized shadow MCP usage before either does damage.

Products already in active enterprise evaluation illustrate the range of approaches the category has produced. Obot ships as self-hosted software deployable on Kubernetes or Docker, with a managed-service option alongside it, open-source and built with role-based access control from the ground up. LiteLLM's MCP Gateway takes the opposite path, extending an existing LiteLLM proxy that many enterprises already run rather than introducing a new standalone system, adding tool-level access controls starting with its v1.78.0 release. AWS Bedrock's AgentCore Gateway converts APIs, Lambda functions, and other existing services directly into MCP-compatible tools, and handles inbound authentication by verifying an agent's identity through a JWT issued by Cognito or another OIDC provider.

None of these products fix the protocols themselves, and none is meant to. They sit above MCP and A2A because the gap those protocols leave open is structural and needs an architectural answer. The enterprises that treat the gateway layer as optional in 2026 are running the same experiment unmanaged SaaS already ran once, and the results of that experiment are already on the record.