MCP Is Now Permanent Infrastructure: What the Linux Foundation Means for Gateways
Algis Dumbris • 2026/03/21
TL;DR
Anthropic just donated the Model Context Protocol to the Linux Foundation’s new Agentic AI Foundation (AAIF), co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. MCP is no longer one company’s protocol — it is now governed industry infrastructure. For anyone running MCP servers in production, this changes the calculus entirely: gateways are no longer optional developer tooling. They are mandatory enterprise infrastructure sitting between your agents and an ecosystem that just got a lot bigger, a lot more permanent, and a lot more security-sensitive.
The Donation: What Actually Happened
On March 20, 2026, Anthropic transferred full governance of the Model Context Protocol to the Agentic AI Foundation (AAIF), a new entity formed under the Linux Foundation. The founding members are Anthropic, Block (formerly Square), and OpenAI. Supporting members include Google, Microsoft, AWS, Cloudflare, Bloomberg, Intuit, and several others.
This is not a symbolic gesture. Anthropic transferred the specification, the reference implementations, and the governance process. The AAIF now controls the spec’s roadmap, versioning, and certification processes. Anthropic retains no veto power.

The structure follows the same playbook that produced Kubernetes (CNCF), GraphQL (GraphQL Foundation), and OpenTelemetry — all protocols that became permanent infrastructure once governance moved to the Linux Foundation. The track record is clear: protocols that enter the Linux Foundation do not die. They accumulate adoption, compliance requirements, and ecosystem gravity until they become the kind of thing you cannot rip out of your stack.
Three things about this donation matter more than the press release suggests.
Single-vendor risk is eliminated. The most common objection to MCP adoption in enterprise environments was “What if Anthropic pivots?” That objection is now gone. MCP’s governance is distributed across companies that compete with each other. No single company can unilaterally change the spec, deprecate features, or steer it toward a proprietary direction. This is the same dynamic that made Kubernetes unkillable — Google, Red Hat, VMware, and AWS all needed it, so none of them could kill it.
OpenAI is a co-founder. This is the signal that matters most. OpenAI joining as a founding member means the two largest AI model providers are now committed to the same protocol for tool use and agent-to-server communication. If you were waiting for a sign that MCP was not just an Anthropic bet, this is it. The protocol war is over before it started.
The backing roster reads like a cloud infrastructure checklist. Google, Microsoft, AWS, and Cloudflare collectively control the platforms where MCP servers will run. Bloomberg and Intuit represent the financial and enterprise software categories where compliance requirements are strictest. These are not speculative backers — they are the infrastructure providers and consumers who will encode MCP into their products, their compliance frameworks, and their procurement requirements.
What This Means for Enterprise Adoption
Before the AAIF, MCP adoption followed the pattern of any early-stage protocol: individual developers built MCP servers, teams experimented with them, and a few forward-leaning organizations started running them in staging environments. The governance question always hung over production deployments. IT leaders could not justify committing infrastructure budget to a protocol controlled by a single AI startup, no matter how good the technical design.
The AAIF removes that blocker completely. Here is what changes:
Procurement unlocks. Enterprise procurement teams have a standard playbook for open standards governed by the Linux Foundation. They know how to evaluate CNCF projects, GraphQL Foundation specs, and OpenTelemetry implementations. AAIF-governed MCP fits into the same evaluation framework. Expect to see MCP requirements appearing in RFPs within the next two quarters.
Compliance frameworks will follow. When Bloomberg and Intuit sit on a governance board, compliance is not an afterthought — it is a design constraint. The AAIF will likely produce conformance tests, security baselines, and audit guidelines that enterprise security teams can reference. This is the same path OpenTelemetry followed, and it dramatically accelerated adoption in regulated industries.
The MCP server ecosystem is about to explode. With governance risk removed, cloud providers will start shipping first-party MCP servers for their services. AWS already has MCP servers for Bedrock; expect Google Cloud, Azure, and Cloudflare to follow with official, supported implementations. When the major cloud providers ship MCP servers, every enterprise using those clouds becomes an MCP consumer by default.
This explosion in adoption creates a new problem: who controls what those MCP servers can do once they are connected to your agents?
The $692M Signal: Security Capital Is Pouring In
The timing of the AAIF announcement is not coincidental. In March 2026 alone, over $692 million was raised by companies focused on AI agent security and infrastructure:
- Snyk raised $300M for AI-focused application security
- Chainguard raised $356M for software supply chain security, explicitly targeting AI agent workloads
- Stacklok raised $36M for MCP security and optimization tools
These are not speculative bets on a future market. They are infrastructure investments by firms that see MCP becoming permanent and are positioning to secure it. The pattern mirrors what happened with Kubernetes security: once the orchestration layer became permanent infrastructure, an entire category of security tooling emerged around it (Falco, OPA, Kyverno, Aqua, and dozens of others).
The same thing is happening now with MCP. The protocol is settling into permanence, and the security market is forming around it. Gateways sit at the center of that market because they are the enforcement point — the place where policies, access controls, and audit trails converge.
Why Gateways Become Mandatory
In a pre-AAIF world, you might run a handful of MCP servers that your team built, connecting to agents you control. The attack surface was manageable because you controlled both sides. In the post-AAIF world, your agents will connect to MCP servers built by AWS, Google, Cloudflare, your SaaS vendors, your internal platform teams, and open-source projects you have never audited. The attack surface is not manageable without a gateway.
Here is the concrete threat model:
Tool sprawl. Enterprise agents will have access to hundreds or thousands of tools across dozens of MCP servers. Without a gateway performing tool discovery and routing, agents receive every tool in every connected server. Context windows overflow, tool selection accuracy drops (as we documented in our BM25 benchmarks), and costs spike from wasted tokens.
Untrusted servers. When a cloud provider ships an MCP server, you are trusting that vendor’s implementation. When an open-source project ships one, you are trusting that community’s security practices. When a SaaS vendor ships one, you are trusting their release process. A gateway that quarantines new tools — requiring explicit approval before agents can invoke them — is the only way to maintain control over what your agents can actually do.
Audit requirements. Regulated industries need to know exactly which tools an agent invoked, with what parameters, and what results were returned. A gateway that logs every tool call provides the audit trail that compliance teams require. Without it, you are flying blind.
Lateral movement. If an agent is compromised or manipulated through prompt injection, every tool it has access to becomes an attack vector. A gateway enforcing least-privilege access — where agents only see the tools they need for their current task — limits the blast radius of any compromise.
This is not theoretical. It is the same argument that made API gateways mandatory for microservices and service meshes mandatory for Kubernetes. Every time a protocol becomes permanent infrastructure, a control plane emerges to govern it. MCP gateways are that control plane.
MCPProxy: Built for This Moment
MCPProxy is an open-source MCP gateway that was built around three principles that the AAIF world now demands:
BM25 tool discovery. Instead of dumping every tool into the agent’s context, MCPProxy indexes all tools from all connected upstream servers and uses BM25 ranking to surface only the relevant tools for each request. This keeps context windows lean and tool selection accurate, even as the number of connected servers grows. Install and try it:
go install github.com/smart-mcp-proxy/mcpproxy-go/cmd/mcpproxy@latest
mcpproxy serve
Quarantine by default. When you add a new upstream MCP server, its tools are quarantined — visible to MCPProxy but invisible to agents until an administrator explicitly approves them. This is the “deny by default” posture that enterprise security teams expect:
mcpproxy upstream add --name "aws-bedrock" --url "https://bedrock.aws.example.com/mcp"
mcpproxy upstream list # shows quarantined tools
mcpproxy upstream approve aws-bedrock # makes tools available to agents
Docker isolation. MCPProxy can run upstream MCP servers in isolated Docker containers, preventing a compromised or misbehaving server from accessing the host system. This is defense-in-depth: even if a tool does something unexpected, the blast radius is contained to its container.
These three capabilities — discovery, quarantine, and isolation — form the minimum viable control plane for MCP in an enterprise environment. The AAIF does not change what MCPProxy does; it changes why MCPProxy matters. We are no longer building a developer tool for early adopters. We are building infrastructure for an ecosystem that just committed to permanence.
What Comes Next
The AAIF is a governance event, not a technical one. The MCP spec does not change overnight. But governance changes create downstream technical requirements, and here is what we expect:
Conformance testing. The AAIF will likely establish a conformance test suite, similar to what the CNCF did for Kubernetes. MCP servers and clients that pass conformance testing will carry a certification mark. Gateways will need to mediate between certified and uncertified implementations.
Transport evolution. The current MCP spec supports stdio and HTTP+SSE transports. The AAIF will likely standardize additional transports (gRPC has been discussed) and potentially mandate TLS for HTTP transports. Gateways will need to bridge between transport types as the ecosystem transitions.
Authentication and authorization standards. The AAIF will almost certainly standardize how MCP servers authenticate clients and how authorization scopes map to tool access. Today, every MCP server handles auth differently. A standard auth framework would simplify gateway implementation and enable federated access control across organizations.
Rate limiting and quota management. As MCP servers become production services with SLAs, rate limiting and quota management will move from “nice to have” to “required.” Gateways are the natural enforcement point for per-agent, per-tool, and per-organization quotas.
Observability standards. OpenTelemetry integration for MCP is already being discussed. When it arrives, gateways will need to propagate trace context across tool calls, enabling end-to-end observability from agent request to tool execution and back.
MCPProxy is tracking all of these developments. The open-source model means the community can contribute support for new transports, auth standards, and observability integrations as the AAIF defines them.
The Bottom Line
The AAIF announcement is not about Anthropic being generous. It is about MCP crossing the threshold from “promising protocol” to “permanent infrastructure.” Every major AI model provider, every major cloud platform, and a critical mass of enterprise software companies have now committed to MCP as the standard for agent-to-tool communication.
That commitment creates an ecosystem. That ecosystem needs a control plane. That control plane is an MCP gateway.
If you are running MCP servers today, or planning to in the next year, the question is no longer whether you need a gateway. It is which gateway you trust to sit between your agents and an ecosystem that is about to grow by an order of magnitude.
MCPProxy is open source, production-ready, and built for exactly this moment. Try it out and join the community building the control plane for agentic AI.