Agent Interoperability Standards: MCP and A2A Become AI Infrastructure

The bottleneck in the AI Agent economy was never that models weren't smart enough—it's that systems can't connect to each other. When Anthropic donated MCP to the Agentic AI Foundation and Google subsequently handed A2A to the same foundation, the protocols that truly matter stopped being one company's marketing pitch and became public infrastructure.

Behind this lies a division of labor between two specification families: MCP handles tool access, while A2A handles delegation between agents. Their journey from the lab into the foundation, and why the real security boundary is authorization rather than prompt design, form the key to understanding the agent infrastructure layer.

Two Protocols, Two Classes of Problems

MCP (Model Context Protocol), led by Anthropic, solves the problem of "how a model calls external tools"—invoking a calculator, querying a database, making network requests—without needing to write a custom integration for each tool. A2A (Agent-to-Agent Protocol), initiated by Google, solves the problem of "how one agent gets another agent to do something on its behalf": how to discover the other party's capabilities, how to delegate tasks, and how to confirm that the other side really is the agent it claims to be.

The two do not overlap in scope, which is why they can coexist under the same foundation rather than replace each other.

The Standards Battle Ended at a Foundation, Not the Market

On December 9, 2025, Anthropic donated MCP's codebase and governance framework to the Linux Foundation. At the same event, the foundation announced the establishment of the Agentic AI Foundation (AAIF)—a directed fund, not an independent legal entity, jointly initiated by Anthropic, Block, and OpenAI, with support from AWS, Google, Microsoft, Cloudflare, and Bloomberg.

The founding member list reads almost like a roll call of the infrastructure layer. Platinum tier includes AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI; Gold tier covers Adyen, Cisco, Datadog, Docker, IBM, JetBrains, Okta, Oracle, Salesforce, SAP, Shopify, Snowflake, Temporal, and others; Silver tier adds another 22 companies, from Elastic to Zapier.

The significance of this breadth: a protocol backed only by Anthropic is just an API wrapper; a protocol adopted simultaneously by Oracle, IBM, and Docker is a wiring layer. The governance design is equally deliberate—AAIF operates as a directed fund under the Linux Foundation, inheriting LF's neutral rules rather than those of any co-founding company. The official MCP blog confirmed that "the governance model introduced earlier continues to apply"—that is, the donation transferred assets, not authority.

Linux Foundation Directed Fund is a governance structure commonly used by the organization. It is not an independent legal entity, but rather a project account established under the foundation's framework, jointly funded by multiple members who form a management committee. Its distinguishing features: ownership of assets and trademarks belongs to the foundation rather than a single donor, governance follows the foundation's neutral charter, and members receive seats according to their funding tier. This differs fundamentally from hosting a project under a single company's GitHub organization—the latter remains legally and governance-wise controlled by that company, which could change the license or roadmap at any time. For MCP and A2A, entering AAIF means their evolutionary direction is no longer decided unilaterally by Anthropic or Google, but jointly by platinum, gold, and silver members. This also explains the line "the donation transferred assets, not authority": Anthropic remains one of the largest contributors, but can no longer unilaterally change protocol rules the way it would for its own product.

MCP Won Its Position Through Distribution, Not Elegance

The numbers in MCP's donation announcement explain its adoption trajectory better than any design evaluation: the protocol has accumulated over 97 million monthly SDK downloads, 10,000 active servers, and first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code.

A protocol with this kind of install base wins the standardization battle not because of optimal design, but because it's already wired into the tools developers open every morning. This is precisely why Anthropic's donation is credible rather than performative: donating a protocol that the ecosystem depends on, with nearly 100 million monthly downloads, carries a real strategic cost—just as Microsoft open-sourcing Git didn't eliminate Git's strategic value, but made replacing it impossible. AAIF's challenge is not building adoption, but maintaining it under a governance model that doesn't favor the donor.

A2A Answers the Question MCP Didn't Want to Ask

A2A's timeline is a matter of public record: announced by Google in April 2025, donated to the Linux Foundation as an independent project on June 23, 2025, and moved under AAIF on August 18, 2026—a three-stage trajectory, not a single donation event. By the time A2A 1.0 was released, it added multi-tenancy, protocol negotiation, and signed Agent Cards.

Signed Agent Cards are the most security-significant addition: they serve to strengthen enterprise deployment and identity verification—precisely the mechanism needed for two agents managed by different vendors to establish mutual trust without a shared identity provider. Techstrong.ai's coverage of the AAIF consolidation gave a blunt definition: A2A "lets AI agents discover capabilities, delegate tasks, and communicate across frameworks and vendors without custom integrations." The keyword is without custom integrations—the economic value of any interoperability protocol scales with the number of custom integrations it eliminates.

Signed Agent Card is A2A's mechanism for solving cross-organizational identity. An Agent Card is essentially a declaration document listing the agent's capabilities, endpoints, supported protocol versions, and authentication requirements, for the other party to discover and evaluate before delegating tasks. With a digital signature added, the card is no longer just a self-declaration but a credential whose origin can be verified via public key—the recipient can confirm "the other side really is the agent I think it is," rather than some impostor. This is especially critical in enterprise deployments: when two agents managed by different vendors and different identity providers need to collaborate, the two sides have no shared SSO system to rely on, so signed cards serve as the identity anchor across trust domains. This complements the audience-bound tokens on the MCP side—A2A guarantees "the other party is the agent it claims to be," while MCP guarantees "this token can only be used on this one service."

Fragmentation Didn't Disappear—It Just Moved Up a Layer

Putting both protocols in the same foundation doesn't eliminate fragmentation, it just relocates it. Before AAIF, the risk was two vendors launching incompatible protocols, forcing every enterprise to maintain two integration surfaces; after AAIF, the risk becomes two protocols coexisting within the same platform, with the integration surface shifting from the vendor boundary to the authorization boundary.

This is not a smaller problem—in some sense it's larger, because the failure mode shifts from "missing a connector" to the "confused deputy" vulnerability. The MCP authorization specification explicitly calls this out in its 2025-06-18 revision: the mechanism must implement OAuth 2.1 (draft-ietf-oauth-v2-1-13), together with RFC 9728 Protected Resource Metadata and RFC 8414 Authorization Server Metadata. The key security requirement is audience binding via RFC 8707: the resource parameter must appear in both the authorization request and the token request, and the server must verify that the access token was issued specifically to it as the intended audience. The anti-pattern explicitly listed in the specification is token passthrough. The defense is not more prompt instructions, but stricter authorization.

Confused Deputy is a classic problem in access control: a component with higher privileges is tricked by a lower-privilege party into performing an operation it should not have been allowed to perform. The classic example is a compiler service—it has the right to write system log files, and an attacker has it treat a log file as an output target, thereby using its privileges to overwrite files it should never have touched. In the agent context, an MCP server often holds credentials for multiple downstream services. If it only verifies "does the request contain a token" without verifying "was this token signed specifically for me and for this call," then a compromised or malicious intermediary agent can use a token obtained elsewhere to drive the server into accessing resources it has no authority to access. This is precisely why the MCP authorization specification locates the attack surface at the protocol layer rather than the model layer: the model cannot defend against such attacks through more careful reasoning—only server-side token audience validation can block it. Understanding this concept is the prerequisite for understanding the article's thesis that "the security boundary is authorization, not prompt design."

The four specifications mentioned form a coordinated set of metadata and authorization mechanisms. OAuth 2.1 is a streamlined version of OAuth 2.0, removing the deprecated implicit grant and resource owner password modes, mandating PKCE—it is the current baseline for authorization flows. RFC 9728 (Protected Resource Metadata) lets resource servers publish through a standardized endpoint "who I am and which authorization server I use," enabling clients to discover the trust chain without hardcoding. RFC 8414 (Authorization Server Metadata) similarly exposes the authorization server's endpoints, supported grant types, and signing algorithms. RFC 8707 (Resource Indicators) specifies that clients explicitly declare the target resource in both authorization and token requests, enabling the authorization server to issue audience-bound tokens—tokens that state within themselves that they are valid only for a specific service. The combined effect is that tokens carry clear attribution as they travel the chain, and no party can use them to act out of bounds.

Tool Access Is an Authorization Problem, Not a Prompt Problem

The authorization chapter of the MCP specification is itself a security document worth reading independently. Its MUST clauses are unambiguous: the authorization server must implement OAuth 2.1 with appropriate security measures for both confidential and public clients; the server must implement OAuth 2.0 Protected Resource Metadata (RFC 9728); the client must implement OAuth 2.0 Resource Indicators (RFC 8707); the resource parameter must be present in both authorization and token requests. There is no such thing as optional compliance—a server that skips audience binding isn't "non-compliant," it's "vulnerable," because the confused deputy scenario described in the specification is exactly how it happens.

For any agent deployment, the implications are specific: when connecting an agent to real external APIs, the authorization design should be exactly the same as when integrating with an external vendor—audience-bound tokens, tool-granular authorization scopes, no token passthrough, explicit outbound allowlists, audit logging on every call, version negotiation between protocol clients and servers, and clearly defined failure semantics so that authorization failures produce recoverable errors rather than silent degradation. These are not best practices—they are the preconditions for keeping agents interoperable without becoming confused deputies.

Wire Agents Into Real Systems the Way You'd Onboard an External Vendor

The practical checklist derived from the specification is short and strict: validate audience-bound tokens before forwarding; scope every authorization to the specific tool being called; never pass tokens through to downstream services unmodified; enforce a defined outbound allowlist; fully log the resource parameter on every call; explicitly negotiate protocol versions; and define failure semantics so authorization errors are recoverable rather than masked.

These are exactly the controls an enterprise would demand before integrating a third-party vendor—and that's the right mental model, because an agent standardized by protocol is, in the authorization sense, a third-party vendor.

The Bottom Line

Agent interoperability is no longer a speculative standards vision. It is a foundation with a verifiable membership hierarchy, a protocol with 97 million monthly SDK downloads, and an authorization specification that writes its own failure modes into the body text. The remaining question isn't whether agents will be wired into real systems, but whether the organizations adopting them will treat authorization as seriously as the specification demands—or whether the first large-scale confused deputy incident will be the event that teaches everyone this lesson. Can the infrastructure layer hold up before failure teaches it?