MCP Security Risks Explained: What the Data Actually Shows

Anthropic shipped the Model Context Protocol in late 2024 without a mandatory authentication framework, and in eighteen months it has become the most consequential security blind spot in enterprise AI. MCP has crossed 78% adoption among production AI engineering teams, with the public registry passing 9,400 servers. Yet the protocol itself provides no built-in authentication, no rate limiting, no audit logging, and no access control, per Requesty’s gateway analysis. What started as a developer convenience has metastasized into an infrastructure layer that security teams are scrambling to understand and govern.

The Core Problem: Metadata as Executable Code

Here’s the pattern I’ve observed, which I’ll call the Metadata Execution Risk. MCP shifted the enterprise trust boundary to plain-text metadata. Tool descriptions—those innocent-looking strings that tell an agent what a tool does—function as executable instructions for AI agents. An attacker who poisons these descriptions doesn’t need to compromise a server, steal credentials, or execute code. They just need to edit text.

The numbers are stark. MCP tool poisoning achieved a 72.8% attack success rate against 45 real servers and 20 leading models in the MCPTox benchmark, and the models almost never refused. On June 30, 2026, Microsoft Incident Response and its Defender research team published the mechanism in detail, confirming this isn’t theoretical—it’s reproducible, scalable, and silent.

The attack works because of a trust gap between connect-time and runtime. Tool descriptions get reviewed once when the agent first connects. Tool responses go straight into the context with no equivalent check. The model sees one undifferentiated context. It has no reliable way to tell an instruction written by your developer from one slipped in by whoever maintains a vendor’s server. Both are just bytes in the window.

This is fundamentally different from traditional supply chain attacks. No malware executes. No vulnerability gets exploited in the conventional sense. The agent simply follows instructions that look legitimate because they arrived through an approved channel. Invariant Labs demonstrated that a malicious MCP server could silently exfiltrate an entire WhatsApp message history. The Supabase Cursor agent incident in June 2025 showed how a privileged agent processing user-supplied support tickets could be tricked into leaking integration tokens through prompt injection. These aren’t edge cases. They’re architectural consequences of treating natural language as a trust mechanism.

The Implementation Debt: What Scanning 2,614 Servers Revealed

If tool poisoning is the sophisticated threat, implementation sloppiness is the pervasive one. Endor Labs’ analysis of 2,614 MCP implementations found that 82% use file operations prone to path traversal, 67% use APIs related to code injection, and 34% use APIs susceptible to command injection. These aren’t niche servers. These are the tools your developers are connecting to right now.

The CVE trail tells the same story. CVE-2025-49596 carries a CVSS score of 9.4 and allows unauthenticated MCP Inspector instances to be exploited to execute arbitrary commands. CVE-2026-52830 is a critical path traversal vulnerability in fast-mcp-telegram with a CVSS score of 9.4, allowing remote HTTP clients to bypass session controls by authenticating as the default legacy session. CVE-2026-34163 is a high-severity SSRF vulnerability in FastGPT’s MCP tools endpoints that allows attackers Accessible to make unauthorized internal network requests.

And then there’s the supply chain angle. The npm package @szc-ft/mcp-szcd-client versions 0.38.0 and 0.39.0 contains a malicious MCP skill called local-browser-test that decrypts every saved password in local Chrome/Edge profiles using Windows DPAPI and AES-256-GCM, writes them to ~/.szcd-mcp/deps/decrypted-creds.json, and returns them to a remote MCP server. The credential-reading behavior lives in an MCP skill that only executes when an operator points the tool at their own running browser—not in an install hook where most scanners look. This is a pattern worth naming: SkillLeak, where the sensitive capability hides in a tool invocation, not in the installation path.

The Scale Problem: Ungoverned Sprawl

Wiz found MCP servers in at least 80% of observed cloud environments in early 2026, with 5% of those environments running at least one internet-facing MCP server. Meanwhile, 70% of MCP consumers already have between two and seven MCP servers configured, and 72% expect their MCP usage to increase over the next 12 months.

Without a gateway, the math gets ugly fast. Ten agents connecting to twenty tools produce two hundred independent connection paths, each with its own credentials. That’s two hundred potential leak points, two hundred audit gaps, two hundred places where a departing employee’s access might linger because nobody remembered to revoke that one token.

The proxy function accounts for roughly 5% of an enterprise-grade MCP gateway’s scope. The remaining 95% covers identity federation, automated provisioning, audit logging, RBAC, and policy enforcement. Organizations that evaluate gateways primarily on latency benchmarks and integration counts are optimizing for the 5%. The 95% is what determines whether your security team will sign off.

The New Spec: Fixes and New Friction

The MCP 2026-07-28 specification removes protocol-managed sessions (Mcp-Session-Id), eliminating session hijacking vectors. It also introduces mandatory OAuth 2.1, kills legacy password and implicit grants, and requires PKCE. These are genuine improvements.

But the stateless shift introduces its own risks. The new specification introduces tracking identifiers and state objects that enable workflow hijacking, cross-tenant data access, and unauthorized cross-tenant actions if predictable or improperly validated. It also introduces MCP-specific HTTP headers (MCP-Method, MCP-Name) that create protocol confusion (Desync) attack risks and data leakage via x-mcp-header if sensitive inputs are accidentally mapped.

The spec fixes old problems by pushing security decisions to implementers. That’s not necessarily bad, but it means the safety of your deployment now depends heavily on your team’s ability to validate tracking identifiers, sanitize state objects, and configure headers correctly. The protocol no longer handles these for you.

Enterprise-Managed Authorization: What It Solves and Where It Stops

Enterprise-Managed Authorization (EMA) for MCP became stable on June 18, 2026, with Anthropic, Microsoft (Visual Studio Code), and Okta implementing support. It solves the per-user consent problem: employees get approved servers on first SSO, no more manual authorization queues, and revocation happens centrally through your IdP.

But EMA governs connection-level authorization and explicitly does not govern runtime, context-aware authorization decisions; the identity provider never sees MCP traffic. The IdP can decide that Alice in engineering may connect to the Jira server. It cannot decide whether Alice’s specific request to update a ticket in a specific project at 2 AM from a new device should go through. That runtime decision is entirely yours to build.

This creates a governance gap that EMA alone doesn’t close. For a deeper look at how to think about MCP authentication architecture, see our MCP Authentication Explained: 2026 Security Best Practices guide.

The Five Attack Vectors You Need to Model

Wiz identifies five specific attack vectors that define MCP risk: confused deputy, token passthrough, tool poisoning, SSRF via tool connectors, and rogue server registration. Each maps to a different control domain:

Attack Vector	Mechanism	Key Control
Confused deputy	Agent acts with broader rights than user holds	OAuth 2.1 with PKCE, strict audience checks, short token lifetimes
Token passthrough	Credentials leak through tool call chains	Token binding, per-tool scoping, no shared service accounts
Tool poisoning	Malicious descriptions steer agent behavior	Approved-server lists, description pinning, runtime validation
SSRF via connectors	Unvalidated URLs in tool calls trigger internal requests	Egress boundaries, URL allowlists, input validation
Rogue server registration	Attackers register malicious servers mimicking legitimate tools	Server attestation, registry curation, discovery governance

For a practical checklist of controls to implement before production, our MCP Security Checklist: 12 Controls Needed Before Production covers the specifics.

The Market Consolidation I’m Watching

The market will consolidate around identity-centric governance platforms. Here’s why: gateways solve the N×M integration problem, but the real enterprise requirement is identity federation, automated provisioning, and audit trails. Capabilities that open-source projects and API gateway vendors are structurally unlikely to prioritize at the depth regulators demand.

Open-source options like Lunar MCPX and agentgateway offer RBAC, audit trails, and policy engines. But regulated enterprises require SOC 2 Type II certification, HIPAA BAAs, and SCIM-driven provisioning—features that create a compliance gap in the OSS ecosystem. Commercial platforms like MintMCP are filling it, but that creates vendor lock-in risks that open-source advocates rightly flag.

The tension is real. Shadow AI proliferation fights against sanctioned AI acceleration. 70% of MCP consumers have 2-7 servers configured with no centralized governance, creating credential sprawl and audit gaps. Meanwhile, EMA makes approved servers appear automatically on first SSO, potentially accelerating sanctioned adoption faster than security teams can review tool descriptions.

What to Do Monday Morning

If you’re running MCP in production today, three actions have the highest leverage:

First, inventory. You cannot secure what you don’t know exists. Find every MCP server in your environment, who configured it, and what credentials it holds.

Second, pin descriptions. The Microsoft advisory on tool poisoning makes clear that an approved-server list plus description pinning closes most of the supply-chain path with zero runtime overhead. Do this before you build anything more elaborate.

Third, separate by blast radius. Keep high-risk servers—mail, finance, source control—away from general-purpose tool groups unless a gateway enforces policy between them. One server holding mailbox, database, and ticketing scopes means one stolen token inherits all three.

For teams looking at gateway options, the comparison landscape is evolving quickly. Here’s how the major approaches stack up on dimensions that matter for security:

Platform	Type	SOC 2	SSO/IdP	Key Differentiator
MintMCP	Commercial	Type II	OAuth, SAML	HIPAA BAAs, compliance documentation
Lunar MCPX	Open source	—	IdP integration	Open-source governance, immutable audit trail
Composio	Commercial	SOC2/ISO	Built-in	1,000+ integrations, runtime tool selection
Kong AI Gateway	Commercial + OSS	Kong’s existing	OIDC, Key Auth	LLM, MCP, A2A unified governance
agentgateway	Open source	—	OAuth 2.1 + PKCE	CEL policy engine, performance-critical routing

The right choice depends on whether your organization prioritizes compliance certification (favoring commercial platforms), integration breadth (favoring connector-heavy solutions), or operational control and cost predictability (favoring open-source with in-house expertise). For a deeper analysis of how to evaluate these tradeoffs, see our MCP Security Risks: What Every Engineering Team Should Know overview.

The Open Question

The most dangerous MCP threat isn’t compromised servers or stolen credentials. It’s approved servers with subtly edited tool descriptions that steer agents to exfiltrate data using the user’s own permissions—a supply chain attack requiring no code execution and triggering no traditional security alerts. We’ve built our security models around detecting malicious code and unauthorized access. How do you detect malicious intent expressed in grammatically correct English, delivered through a trusted channel, and executed by an agent doing exactly what it was told?