The biggest Model Context Protocol news of the past year is that MCP stopped being an Anthropic project and became infrastructure: donated to vendor-neutral foundation governance in December 2025, adopted by every major model provider, and now carrying the security scrutiny that comes with being the default way AI agents touch real systems. Eighteen months after its November 2024 release, MCP has moved through the full hype-to-plumbing arc. This post rounds up where the protocol stands in mid-2026 — governance, spec direction, adoption — and takes an honest look at the security landscape, which now includes shipped critical vulnerabilities, not just theoretical attack papers.
From vendor project to open standard
MCP launched in November 2024 as Anthropic's open protocol for connecting LLM applications to tools and data. The inflection points since:
- Early 2025: OpenAI announced MCP support, followed by Google and Microsoft — the moment MCP effectively won the "USB-C for AI tools" race, since every major client speaking one protocol removed the reason for competitors to exist.
- Through 2025: two significant spec revisions landed. The 2025-03-26 revision brought streamable HTTP transport and an OAuth-based authorization framework; the 2025-06-18 revision refined authorization (classifying MCP servers as OAuth resource servers) and added elicitation for structured user input.
- December 2025: Anthropic donated MCP to foundation governance under the Linux Foundation umbrella, making the protocol vendor-neutral and community-governed via a formal proposal process (SEPs — Specification Enhancement Proposals).
- 2026: the project published a roadmap pointing at a major revision — a stateless protocol core, an extensions framework, first-class long-running tasks, and richer app-style UI surfaces — slated to ship in the second half of the year.
The ecosystem numbers tell the adoption story: public registries index roughly twenty thousand MCP servers, and official SDK downloads run in the tens of millions per month. Whatever agentic system you are evaluating in 2026, the odds are its tool layer speaks MCP.
Why security people started paying attention
An MCP server is, functionally, a privileged adapter: it holds credentials to something real (a database, a repo, a SaaS API, a shell) and exposes operations to a model-driven client. That design concentrates three risks:
1. The confused deputy problem, at scale. The model decides which tools to call based on text it reads — and text is attacker-controllable. Prompt injection via a poisoned document, web page, or even a malicious tool description (tool poisoning) can steer an agent into calling legitimate tools with attacker-chosen arguments. Research through 2025 demonstrated variants like rug pulls (a server that changes its tool descriptions after approval) and cross-server shadowing.
2. The servers themselves are software with bugs. This stopped being hypothetical in mid-2025:
- CVE-2025-49596 (CVSS 9.4): Anthropic's own MCP Inspector developer tool ran a localhost proxy without authentication; a malicious web page could reach it via CSRF-style requests and achieve remote code execution on the developer's machine. Fixed in version 0.14.1.
- CVE-2025-6514 (CVSS 9.6): the widely used
mcp-remoteproxy (hundreds of thousands of npm downloads) could be driven to arbitrary OS command execution when connecting to a malicious MCP server. Versions 0.0.5 through 0.1.15 were affected; 0.1.16, released June 17, 2025, fixed it.
Both are instructive: the victims were developers running local AI tooling, and the attack vector was simply connecting to, or being reachable from, something untrusted.
3. Supply chain exposure. MCP servers are distributed as npm and PyPI packages, cloned from GitHub, and increasingly pulled from registries with uneven vetting. A typosquatted or backdoored MCP server is a credential-stealing implant with a socket into your agent. The same discipline you apply to any dependency applies here — provenance checks, version pinning, and software composition analysis over the server's own dependency tree, which is ordinary open source code with ordinary CVEs.
What the spec has fixed — and what it moved onto you
The authorization work in the 2025 spec revisions addressed the protocol's original sin: early MCP had no standard answer for "how does a remote server know who is calling and what they may do?", so implementers improvised with static tokens and homegrown auth. OAuth-based authorization, resource-server semantics, and the newer enterprise-oriented auth profiles give the ecosystem a correct pattern to converge on.
The candid trade-off, echoed by government guidance (the NSA published security design considerations for MCP-based automation in June 2026) and independent analysts alike: the protocol increasingly specifies the secure pattern but delegates enforcement. Session handling, token validation, tool-permission scoping, sandboxing of tool execution, and UI-content isolation are implementation responsibilities. A spec-compliant server can still be a badly built one. As richer capabilities land — app-style HTML surfaces, long-running tasks — familiar web vulnerability classes (stored XSS, resource-exhaustion DoS) enter the MCP threat model with them.
A practical MCP security checklist for 2026
For teams deploying MCP in anger, the controls that matter most:
- Treat MCP servers as third-party dependencies. Inventory them, pin versions, review before upgrade, and scan them like any package. The
mcp-remoteincident is the template: patch paths matter more than trust in the ecosystem. - Least-privilege every credential a server holds. A GitHub MCP server with a fine-grained read-only token is an information-disclosure risk; one with a classic full-scope PAT is a lateral-movement platform.
- Isolate execution. Run servers in containers or sandboxes with egress restrictions. A tool that can write files or run commands should not share a trust domain with your SSH keys and browser sessions.
- Gate high-impact tools on human approval. Client-side allowlists and per-tool confirmation for anything that mutates state — the confused-deputy problem is managed at the client boundary, not inside the model.
- Log tool calls as security events. Arguments, results, and the originating context. When (not if) an injection attempt happens, this is the difference between an incident report and a shrug.
- Keep developer tooling patched and off shared networks. Inspector-class tools binding localhost without auth were exploitable from a browser tab. Update aggressively; these utilities are now attack surface.
Teams that already run application-security programs will recognize all of this — MCP does not require a new discipline so much as the honest application of the existing one to a new artifact class. (Full disclosure: we ship an MCP server ourselves at Safeguard, and it goes through the same dependency scanning and least-privilege review we recommend here.)
Where this goes next
Three trends worth watching through the rest of 2026: registry maturation (signed, vetted server distribution replacing "clone whatever GitHub repo ranks first"), enterprise auth convergence (centralized identity for fleets of MCP servers rather than per-server OAuth dances), and security tooling catching up (MCP-aware scanners, traffic proxies, and policy engines are an active product category now). The protocol's trajectory looks like Kubernetes circa 2019: governance settled, adoption effectively universal, and the interesting work shifting from "does it work?" to "can we run it safely at scale?" For a deeper grounding in agentic AI risk fundamentals, our academy track on AI supply chain security covers the underlying concepts.
FAQ
Who controls the Model Context Protocol now?
Since December 2025, MCP is governed under a vendor-neutral foundation within the Linux Foundation ecosystem, with changes proposed through a community SEP process. Anthropic created the protocol in November 2024 but no longer solely controls it.
Has MCP had real security vulnerabilities?
Yes. Notable examples from 2025 include CVE-2025-49596, an RCE in the MCP Inspector developer tool (fixed in 0.14.1), and CVE-2025-6514, a CVSS 9.6 command-execution flaw in the mcp-remote proxy (fixed in 0.1.16). Beyond CVEs, prompt injection and tool poisoning remain the dominant systemic risks.
Is MCP safe to use in production?
It can be, with the same rigor you apply to any privileged integration: vetted and pinned server dependencies, least-privilege credentials, sandboxed execution, human approval for destructive tools, and full audit logging of tool calls. The spec provides secure patterns; enforcement is on the implementer.
What is changing in the MCP specification in 2026?
The project's 2026 roadmap centers on a stateless protocol core, a formal extensions framework, first-class long-running tasks, richer app-style UI capabilities, and hardened authorization — aimed at enterprise-scale deployments, with a major revision planned for the second half of 2026.