MCP Just Got a New Home at the Linux Foundation - But Its Security Debt Followed It There
The announcement was carefully orchestrated. On December 9, 2025, Anthropic published a blog postannouncing that MCP would join the Linux Foundation’s new Agentic AI Foundation alongside two other founding projects: Block’s goose local-first AI agent framework and OpenAI’s AGENTS.md specification for describing agent capabilities. The foundation’s platinum members read like a who’s who of enterprise technology: AWS, Bloomberg, Cloudflare, Google, Microsoft. Gold members included Cisco, Datadog, Docker, IBM, JetBrains, Oracle, SAP, and Snowflake.
The numbers backing the transition were impressive. MCP had reached 97 million monthly SDK downloads, over 10,000 active servers, and more than 13,000 deployed servers. The protocol had evolved from Anthropic’s internal project to the de facto standard for connecting AI agents to external tools and data sources. Moving it to neutral governance made sense for the same reasons that Kubernetes moved from Google to the Cloud Native Computing Foundation: no single company should control infrastructure that the entire industry depends on.
But governance transitions have a pattern that enterprise leaders should recognize. They generate enthusiasm about the future while doing nothing to address existing technical debt. MCP’s security challenges are real, documented, and unresolved. A new organizational home doesn’t change the code.
What the foundation actually changes
The Agentic AI Foundation (AAIF) provides several things that MCP under Anthropic’s sole stewardship couldn’t offer.
First, neutral governance. MCP’s specification development was previously controlled by Anthropic. Competitors adopting the protocol were implicitly ceding influence over their integration architecture to a rival. Under Linux Foundation governance, specification changes follow a multi-stakeholder process. No single vendor can unilaterally alter the protocol.
Jim Zemlin, executive director of the Linux Foundation, stated in the announcement that the foundation would provide “neutral stewardship” similar to the model used for Kubernetes, PyTorch, and Node.js. The governance structure includes a technical advisory council with representatives from member organizations, and specification changes require community review and approval.
Second, broader contribution. When a protocol is owned by a single company, external contributors are volunteering labor for someone else’s product. Under foundation governance, contributions go to shared infrastructure. This typically accelerates development - Linux Foundation projects generally see increased contribution rates after donation.
Third, ecosystem credibility. Enterprise procurement teams have learned to be cautious about building critical dependencies on vendor-controlled standards. Foundation governance provides the assurance that the standard won’t be abandoned, radically changed, or monetized in ways that disadvantage adopters. This matters for MCP because enterprise adoption decisions are increasingly bottlenecked by governance concerns rather than technical ones.
Dario Amodei, CEO of Anthropic, described the donation as recognizing that MCP had “grown beyond any single organization” and that neutral stewardship would “accelerate adoption and ensure the protocol serves the entire ecosystem.” OpenAI’s involvement - contributing AGENTS.md as a founding project - was particularly notable given the competitive relationship between the two companies.
What the foundation doesn’t change
Here’s what the December 9 announcement didn’t address: any of MCP’s existing security problems.
The protocol’s first year produced a vulnerability record that should give enterprise security teams pause. Between June and December 2025, five critical CVEs were disclosed in MCP core components:
CVE-2025-49596 (CVSS 9.4): Remote code execution in MCP Inspector, the official debugging tool, via DNS rebinding and CSRF. All versions prior to 0.14.1 were affected. The tool had approximately 38,000 weekly downloads.
CVE-2025-6514 (CVSS 9.6): Remote code execution in mcp-remote, the npm package for remote MCP connections. Over 558,000 downloads were affected. Exploitable through browser-based attacks against developers running the tool locally.
CVE-2025-6515: SSE connection handling vulnerability in mcp-remote, allowing connection interception.
CVE-2025-53967: Authentication token handling flaw in mcp-remote, enabling credential theft.
The Anthropic Git MCP server contributed three additional CVEs (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145) including a vulnerability where the git_init tool could create repositories in sensitive system directories like ~/.ssh, potentially overwriting SSH keys.
Beyond the CVEs, BlueRock Security’s ecosystem-wide analysis found that 36.7% of over 7,000 MCP servers had SSRF vulnerabilities - a class of flaw so prevalent that it represents a systemic design pattern rather than individual coding errors.
Moving MCP to the Linux Foundation changes who governs the specification. It doesn’t change the code that’s already deployed. The 13,000+ MCP servers in production don’t get automatically patched or audited because the protocol’s governance moved. The insecure default patterns that produced a 36.7% SSRF rate don’t get corrected because the specification is now maintained by a multi-stakeholder foundation.
The Kubernetes parallel - and where it breaks down
Advocates for the Linux Foundation transition frequently compare MCP’s journey to Kubernetes. Google donated Kubernetes to the CNCF in 2015, and the project subsequently became the dominant container orchestration platform. The comparison is apt in some ways and misleading in others.
Kubernetes benefited from CNCF stewardship because the foundation invested heavily in security tooling, compliance programs, and ecosystem certification. The CNCF Security Technical Advisory Group provides security audits for CNCF projects. The Kubernetes Security Response Committee has established processes for vulnerability disclosure and patching.
MCP would benefit from equivalent investment. But Kubernetes had several advantages that MCP doesn’t share at this stage. Kubernetes was already relatively mature when it was donated - it had been in production at Google for years. MCP has been a public standard for approximately one year. Kubernetes had Google’s security team behind it for years before donation. MCP’s security has been primarily community-driven, with Anthropic’s security team focused on their own products rather than the broader ecosystem.
Ed Sim, founder and managing partner of Boldstart Ventures, commented on the transition that while the foundation model is proven for infrastructure protocols, “the pace of change in the AI space is unprecedented” and “governance structures need to be able to move as fast as the technology they govern.” The concern isn’t that Linux Foundation governance is wrong for MCP. It’s whether governance processes designed for mature infrastructure can keep up with a protocol that’s still rapidly evolving.
The AGENTS.md and goose dimension
MCP didn’t arrive at the Agentic AI Foundation alone. The two companion projects - OpenAI’s AGENTS.md and Block’s goose - add important context to what the foundation is attempting.
AGENTS.md addresses a problem adjacent to MCP: how AI agents discover what other agents and services can do. While MCP handles the communication protocol between agents and tools, AGENTS.md provides a standardized way for services to describe their capabilities. The specification has seen rapid adoption, with over 60,000 open-source projects incorporating AGENTS.md files, including tools like GitHub Copilot, Cursor, and Gemini CLI.
Block’s goose is a local-first AI agent framework with native MCP integration. It represents a reference implementation for building agents that use MCP to connect to tools and services.
Together, the three founding projects create a stack: AGENTS.md for discovery, MCP for communication, and goose for implementation. The foundation’s ambition is to standardize the full agent-to-tool interaction lifecycle. But each layer inherits the security challenges of the layers below it. If MCP connections are vulnerable to SSRF, then goose agents using those connections inherit the vulnerability. If AGENTS.md capability descriptions can be spoofed or poisoned, then MCP connections established based on those descriptions start from a compromised foundation.
The security model for the full stack hasn’t been articulated yet. Individual projects have individual security practices. What’s missing is a cross-project security architecture that addresses how vulnerabilities in one layer propagate to others.
What enterprise leaders should actually do
The temptation for enterprise leaders is to treat the Linux Foundation transition as a validation signal - “if Google, Microsoft, AWS, and OpenAI are all backing this, it must be ready for enterprise deployment.” That logic has failed enterprises before. Remember that Kubernetes was backed by every major cloud vendor years before its security posture was ready for regulated industries. The backing signals strategic importance, not operational maturity.
Here’s what enterprise security and architecture teams should do in response to MCP’s governance transition:
Don’t treat the transition as a security milestone. The Linux Foundation announcement is a governance event, not a security event. Your security posture for MCP deployments should not change based on who governs the specification. Continue applying the same security controls you would for any protocol with MCP’s vulnerability history.
Track the foundation’s security roadmap. The AAIF will presumably establish security review processes, vulnerability disclosure policies, and ecosystem security standards. Monitor what those processes look like and how quickly they produce tangible improvements. The gap between announcing security governance and implementing it is where risk lives.
Maintain independent security controls. Don’t outsource your MCP security posture to the foundation’s ecosystem health. Implement your own MCP server allowlists, SSRF protections, network segmentation, and monitoring. The foundation can improve the ecosystem’s baseline over time. Your security can’t wait for that.
Plan for specification versioning and breaking changes. Foundation governance typically introduces formal versioning and deprecation cycles. This means MCP specification updates may move more slowly and require migration planning. Factor this into your architecture decisions - if you’re building on MCP features that might change in a foundation-governed revision, build abstraction layers now.
Monitor the CVE response process. One of the clearest indicators of a foundation’s security maturity is how quickly it responds to vulnerability disclosures. Track the time between CVE disclosure and patch availability for MCP components under foundation governance. If the response time increases compared to Anthropic’s direct management, you have a governance-imposed security gap.
Evaluate cross-project security implications. If you’re adopting multiple AAIF projects (MCP, AGENTS.md, goose), assess how vulnerabilities in one project affect your deployments of the others. The foundation hasn’t published a cross-project security model yet. Until it does, assume that security boundaries between projects are your responsibility.
The real question the transition raises
The Linux Foundation transition is the right structural move for MCP’s long-term viability. No serious enterprise infrastructure standard can remain under single-vendor control indefinitely. The foundation model works. It worked for Linux, for Kubernetes, for Node.js, for PyTorch. It will likely work for MCP.
But “working” in the foundation context means “producing a mature, secure, well-governed standard over time.” The emphasis is on “over time.” Kubernetes didn’t become enterprise-ready the day it joined the CNCF. It became enterprise-ready years later, after sustained investment in security tooling, compliance programs, and operational maturity. MCP is at the beginning of that journey, not the end.
The 97 million monthly SDK downloads and 13,000 deployed servers mean that MCP is already critical infrastructure for many organizations. The five critical CVEs and 36.7% SSRF prevalence rate mean that the infrastructure has known, unresolved security challenges. The Linux Foundation governance means those challenges will eventually be addressed through structured, multi-stakeholder processes. The gap between “eventually” and “now” is where enterprise risk teams need to focus their attention.
The protocol has earned its place as the leading standard for AI-tool integration. It hasn’t yet earned the security trust that critical infrastructure requires. Foundation governance is the first step toward earning that trust. It’s not the last.
