MCP became the agentic web's standard in 18 months — its security model did not keep up

From vendor side-project to shared plumbing in 18 months

Anthropic open-sourced the Model Context Protocol in November 2024 to solve a concrete problem: connecting M AI applications to N tools required up to M×N custom integrations. MCP reduces that to one integration per tool behind a standard JSON-RPC interface. Within eighteen months it stopped being a Claude feature and became cross-vendor infrastructure — OpenAI adopted it in March 2025, Google and Microsoft followed, and on December 9, 2025 Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg.

The scale numbers are real and verifiable. At the donation, Anthropic reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads; by July 2026 the Tier 1 SDKs reached roughly 500 million downloads per month, with TypeScript and Python each crossing a billion cumulative. Salesforce began routing Headless 360 interactions through MCP in April 2026 and reported 4.5 million MCP calls processed by late May. Neutral governance removed the single biggest enterprise objection — that you would be betting your integration layer on one vendor's roadmap.

• Nov 2024 launch; Dec 9 2025 donated to the Linux Foundation's Agentic AI Foundation.
• 10,000+ active public servers and ~97M monthly SDK downloads at donation; ~500M/month for Tier 1 SDKs by July 2026.
• Cross-vendor client support: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code.

The numbers everyone quotes — and the ones that survive checking

Adoption statistics for MCP have been messy, and the most-quoted one is not reliable. A widely repeated claim put enterprise production adoption at 78% with no traceable sample behind it; several publishers have since withdrawn it. The defensible figure comes from Stacklok's December 2025 survey: 45% of software-industry technical leaders report limited or broad MCP production use (41% across all industries), with broad rollout alone at just 19%. The same survey found 64% name security and governance as their top obstacle — and only 11% of respondents personally build or use MCP servers in production, against 50% experimenting. Companies are buying the capability faster than their people are building the muscle.

Server counts are equally slippery and deserve the same skepticism. The official registry's latest records sit near 9,652, a July 2026 snapshot counted 18,843 unique servers, and security researchers detected more than 21,000 internet-facing instances. These are not the same thing: registry listings, GitHub tags, and exposed instances measure different populations. One practitioner analysis puts genuinely production-grade public servers between 2,500 and 4,000 and advises treating any headline above 20,000 as ecosystem noise unless the source states its verification method. When someone cites an MCP number, ask how it was counted before you repeat it.

• The viral '78% enterprise adoption' figure was withdrawn for lack of a traceable sample.
• Defensible: 45% of software-cohort leaders report limited/broad production use; 19% broad-only (Stacklok, Dec 2025).
• Server counts range 9,652 (registry) to 21,000+ (exposed instances) — different populations, not a single truth.

What actually changed on July 28, 2026

The 2026-07-28 revision is the largest since launch and it is explicitly backward-incompatible. It makes the protocol core stateless: the initialize handshake and the Mcp-Session-Id header are removed, so every request is self-contained and any server instance behind an ordinary load balancer can answer it. Protocol version, client identity, and capabilities now travel in a _meta field on each request, and a new server/discover RPC replaces the stateful capability exchange. Three methods are mandatory or newly required: server/discover, plus the Mcp-Method and Mcp-Name routing headers on every Streamable HTTP POST. List and resource-read results now carry ttlMs and cacheScope, making them safely cacheable and enabling deterministic tool ordering for prompt-cache hits.

The motivation is scale, and it lands. Removing protocol-level sessions means no instance has to stay warm to hold one, so serverless MCP moves from workaround to first-class pattern — request in, response out is exactly what a Lambda does natively. Server-to-client requests (sampling, elicitation, roots) are replaced by Multi Round-Trip Requests, where a server returns an input_required result with an opaque requestState token. Roots, Sampling, Logging, and Dynamic Client Registration are deprecated on a twelve-month window with earliest removal around July 2027; new clients should build on Client ID Metadata Documents instead. Old servers keep working — July 28 was the publication date of the normative text, not a switch-off.

• Stateless core: initialize handshake and Mcp-Session-Id removed; _meta carries version and capabilities per request.
• New requirements: server/discover RPC, Mcp-Method and Mcp-Name headers, ttlMs and cacheScope on list results.
• Deprecated (12-month window): Roots, Sampling, Logging, Dynamic Client Registration; HTTP+SSE transport.

Stateless is not the same as safer

The most important nuance in the whole rewrite is easy to miss: making MCP stateless makes it scalable and gateway-readable, not automatically more secure. Identity information becomes declarative and self-reported in _meta — useful for routing, metering, and debugging, but not sufficient for trust decisions on its own. The control question shifts from what a connection remembers to what each request proves about itself, which means identity, capability, and authorization now have to be enforced on every request rather than once per session.

Multi-round-trip state moves into requestState, a server-authored value the client carries back. Because it can influence authorization or business logic, the spec recommends integrity-protecting it with HMAC or AEAD and binding it to the principal and request context. SSE resumability is gone, so replay and continuation handling move out of the transport and into explicit server state — tools may need application-level idempotency. Removed methods do not fail silently: servers return 404 with JSON-RPC error -32601. And because there is no session to group logs, observability now depends on correlation IDs you wire yourself. The protocol got easier to scale and harder to trust by default.

• Self-reported _meta identity is for routing, not trust — enforce auth per request.
• requestState travels client-side; integrity-protect it (HMAC/AEAD) and bind it to the principal.
• No session to group logs: add correlation IDs; removed methods return 404 / -32601.

The attack surface, by the numbers

Adoption outran security, and the measurements are blunt. A July 2026 arXiv study ('Exposed by Design') detected more than 21,000 internet-facing MCP server instances; of 640 production servers audited, 91.8% lacked OAuth and 687 instances had unrestricted shell tool access. A separate credential audit of 5,200+ public servers found 88% require credentials, 53% rely on static API keys or personal access tokens with no rotation or expiry, and only 8.5% had adopted OAuth. Elastic Security Labs found 43% of tested MCP implementations had command-injection flaws and 30% allowed unrestricted URL fetching.

The vulnerability cadence is now a firehose. Forcepoint tracked more than 30 CVEs filed against MCP servers, clients, and infrastructure between January and February 2026 alone, with command injection — the same class web apps have patched for two decades — a large share. A CISA advisory in June 2026 documented command-injection vulnerabilities in a significant fraction of public servers, and OWASP formalized an MCP Top 10. The pattern across every scan is identical: missing authentication, overly broad scopes, unvalidated tool metadata, and weak supply-chain hygiene. The connective tissue of agentic systems is under-protected relative to its privilege.

• 21,000+ internet-facing instances; 91.8% of 640 audited production servers lack OAuth (arXiv, Jul 2026).
• Only 8.5% OAuth adoption; 53% rely on static keys/PATs across 5,200+ servers audited.
• 30+ CVEs in Jan–Feb 2026 alone; 43% of tested implementations had command-injection flaws (Elastic).

The incidents that define the failure modes

These are not theoretical. Tool poisoning — coined by Invariant Labs on April 1, 2025 — hides instructions in a tool's description that the model reads as commands; the proof-of-concept 'add' tool exfiltrated an mcp.json config and SSH keys, and OWASP now lists it as MCP03:2025. In the GitHub MCP exploit (Invariant, May 26, 2025), a malicious public issue hijacked an agent asked to review issues, which then pulled private-repo data and leaked it through a public pull request — a 'toxic agent flow,' not a bug in one tool. The Supabase case (General Analysis, July 2025) ran the server with a service_role that bypassed row-level security; an injection planted in a support ticket made the agent run SQL and leak tokens.

Two more crystallize the governance gap. In June 2025 an access-control flaw in Asana's MCP feature exposed data from roughly 1,000 organizations to other tenants — not an external attacker, just over-broad access plus weak tenant isolation shipped fast (launched May 1, found June 4, restored June 17). The postmark-mcp package was a supply-chain rug-pull: it quietly added a hidden recipient to every email an agent sent, a slow silent leak that looked like normal operation. And CVE-2025-6514 in mcp-remote — an OAuth proxy downloaded over 400,000 times — let a malicious server trigger OS command injection and remote code execution on the client machine. Simon Willison's 'lethal trifecta' names the common thread: private data, untrusted content, and an exfiltration channel in the same agent. The server is the pivot; the data is the target.

• Tool poisoning (OWASP MCP03:2025): hidden instructions in tool metadata the model obeys.
• GitHub MCP toxic-agent-flow and Supabase service_role RLS bypass: untrusted content steering entitled agents.
• Asana cross-tenant exposure (~1,000 orgs) and postmark-mcp silent BCC leak: governance and supply-chain failures.

The controls that actually hold

Transport hardening governs the door, not the query, so the controls have to operate at execution. Authenticate with OAuth 2.0 using audience-validated, scoped tokens (RFC 8707 resource indicators) and reject any token whose audience does not match the server's own identifier — this kills token passthrough and the confused-deputy pattern. Treat every tool output as data, not instructions: sanitize and schema-validate results before they enter the agent's instruction-following context, which is the only real defense against indirect prompt injection. Enforce least privilege with scoped service accounts rather than personal tokens, short-lived and auto-rotated, read-only wherever the task allows.

Then make it auditable and supply-chain-safe. Log every tool call with the authenticated user, server id, tool name, redacted arguments, and a correlation ID, written to an append-only store the server cannot modify. Require cryptographic attestation or signed manifests before admitting a server, pin tool definitions and schemas, and alert or block on drift — rug-pulls become detectable when the definition you approved no longer matches what the agent sees at runtime. Once you run more than two or three servers, put an MCP gateway in front: a single choke point for authentication, rate limiting, circuit breaking, egress restriction, and per-tool policy, so you are not reimplementing controls in every server. Under the stateless spec, add per-request auth, integrity-protected requestState, and correlation IDs for tracing.

• OAuth 2.0 with audience-validated, scoped tokens; reject mismatched audience (RFC 8707).
• Treat tool outputs as data, not instructions; schema-validate before they reach the context window.
• Least privilege + short-lived rotated tokens; immutable per-call audit log with user attribution.
• Signed/pinned server manifests with drift alerts; an MCP gateway once you run more than 2–3 servers.

Build, buy, or wait — a decision frame

MCP earns its keep where an agent needs to reach many tools through one authenticated, discoverable interface — the M×N problem it was built for. The enterprise usage data shows where it is winning budget today: version control (63% of teams connecting it), documentation systems (62%), issue tracking (54%), cloud infrastructure (53%), and security scanning (49%), overwhelmingly read-mostly or scoped-action patterns. Debugging production issues (56%), security remediation (54%), and technical-debt identification (53%) lead the use cases. A plain REST integration still wins for deterministic, high-volume, single-purpose machine-to-machine calls where you do not need agent discovery or natural-language tool selection — MCP removes the protocol session, not the provider-specific work of authorizing users, refreshing credentials, handling rate limits, and tracing failures.

The build-vs-buy signal is clear: roughly 69% of software organizations plan to build their MCP platform in-house on open-source components, and only 9% outsource entirely. For market context, treat the forecasts with appropriate caution — a single analyst house sizes the MCP market near $1.2–1.28 billion in 2025 growing to roughly $28.4 billion by 2035 at a 37.2% CAGR, and Gartner projects 40% of enterprise apps will embed task-specific agents by end-2026 while also warning that more than 40% of agentic AI projects are at cancellation risk by 2027 over cost, unclear value, and weak governance. The practical move is to adopt the standard but govern it like a privileged integration: target 2026-07-28 for new servers, keep the backward-compatible lane until you stop serving pre-2026 clients, and never connect an unvetted server with broad scopes just because the demo worked.