The Model Context Protocol has crossed into production at scale, but 86% of its servers still run on developer laptops. The institutional pieces are in place; the security scaffolding is the next engineering problem.
The Model Context Protocol went to production before its production stack was finished. The 86%-local, 5%-production split tells only half the story. The other half is that every signal that mattered for Docker circa 2014 is present for MCP right now.
By the end of 2025, MCP had been adopted across ChatGPT, Cursor, Claude, Gemini, Microsoft Copilot, and VS Code, with more than 16,000 servers indexed across registries and monthly Python plus TypeScript SDK downloads hitting 97 million. The Linux Foundation's Agentic AI Foundation now stewards the spec, co-founded with OpenAI and Block and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. The protocol is, by any reasonable measure, past the prototype threshold.
It is also, by every measure that matters for production, not yet finished.
Research from Clutch Security found that 86% of MCP servers run locally on developer machines, while only 5% run in production environments — CI, cloud, or Kubernetes. In a typical 10,000-person organization, that works out to roughly 1,500 employees running about two MCP servers each, or 3,000+ deployments connecting to around 115 distinct enterprise services, almost all of them local. The 13-month growth curve, from 3 implementations in October 2024 to roughly 7,000 in November 2025, is the kind of number that gets cited in conference keynotes. It is also the kind of number that security teams lose sleep over.
The deployment topology tells one story. The security topology tells another. Astrix Security's analysis of more than 5,200 MCP server implementations found 88% require credentials, 53% rely on static API keys or long-lived personal access tokens, and only 8.5% use OAuth. Seventy-nine percent of API keys pass through environment variables. Zuplo's State of MCP Report puts the share of servers with no authentication at 25% and reports that 38% of builders cite security concerns as actively blocking increased adoption. It also finds 58% of MCP servers wrap existing APIs rather than building new capabilities — useful for prototyping, brittle for production.
What the OWASP MCP Top 10 catalogs is the natural consequence: tool poisoning, privilege escalation through scope creep, supply-chain attacks, command injection, and insufficient authentication and audit. Independent testing found 43% of MCP implementations had command-injection flaws and 492 servers exposed on the open internet with zero authentication. AuthZed's analysis lands the diagnosis cleanly: "The spec handles authentication. Authorisation, the actual permission decisions, is left entirely to implementers." Cato Networks has documented two vulnerabilities in Anthropic's own MCP SDK — a default-permissive CORS policy and unvalidated redirect URIs enabling silent OAuth token theft — that are the kind of finding that ends up in a postmortem.
The pattern is not new. Docker in 2014 was the developer experience that would eat the world; production-grade orchestration, what eventually became Kubernetes, was a separate, harder problem that took roughly four years to consolidate. MCP is, structurally, in the same place. The runtime is in production. The deployment, identity, tenancy, and observability layer around it is not.
The scaffolding is no longer a research problem. The November 2025 MCP specification introduced OAuth 2.1-based authorization for HTTP transports and Client ID Metadata Documents as the recommended client registration mechanism, superseding the deprecated SSE mode. The Cloud Security Alliance's Agentic AI MCP Security Best Practices v1 is now a public reference. The institutional pieces are in place: foundation governance, named backers, an active spec, and an industry analyst community — including Simon Willison's "lethal trifecta" framing — that has already named the problem.
The remaining work is engineering, not advocacy. Tenancy isolation, per-agent audit trails, transport choice under load (Stacklok benchmarks show STDIO failing 20 of 22 requests at 20 simultaneous connections), and the long tail of credential hygiene across 16,000 servers is the work of the next two to four years, not the next two to four months.
For a Type0 team making a build-or-buy decision on AI infrastructure, the takeaway is simple. The protocol is real, the adoption curve is real, and the security gap is also real — and it is the kind of gap that gets closed by the same people who close every other production gap, on a known timeline, with the tools already specified. The Kubernetes moment is not a question of whether. It is a question of who builds it.