MCP Security Risks: What Every Engineering Team Should Know

Between November 2024 and March 2026, MCP SDK downloads hit 97 million monthly and more than 13,000 public servers went live. In the first 60 days of 2026 alone, 30 CVEs landed against MCP-based deployments. The protocol that was supposed to be the “USB-C of AI” became one of the fastest-growing attack surfaces in enterprise infrastructure — and most security teams still can’t see it.

If your engineering organization has adopted MCP, or even experimented with it, you’re likely running servers that your security team doesn’t know exist. That’s not a hypothetical. Censys counted 12,520 Internet-accessible MCP services, most of them unauthenticated. The question isn’t whether you have exposure. It’s how much.

The Core Problem: Adoption Outpaced Hardening by Nearly 20x

What I call the Adoption-Hardening Asymmetry is the defining pattern of MCP’s first 18 months. The protocol shipped in late 2024 without a mandatory authentication framework, assuming servers were benign. That assumption was wrong, and the consequences are now measurable at scale.

Anthropic released MCP without requiring authentication, and most tutorial implementations still ignore the OAuth 2.1 requirement in the specification. The result: 40% of remote MCP servers expose tools with no authentication, and 53% rely on long-lived static secrets as their primary auth method. These aren’t misconfigurations an engineer forgot to fix. They’re inherited directly from the protocol’s original design choices.

The vulnerability data confirms the pattern. An audit of 17 popular MCP servers found an average security score of 34 out of 100, with every server lacking permission declarations entirely. 82% of 2,614 scanned implementations were vulnerable to path traversal. And the Anthropic MCP SDK contains a by-design RCE flaw in its STDIO transport layer affecting 200,000+ instances and 150M+ package downloads — which Anthropic has declined to patch.

This is the asymmetry: the protocol prioritized developer velocity and interoperability, and the security bill is now coming due for every team that shipped MCP servers into production based on tutorial code.

The Five Risk Categories That Matter

Not all MCP vulnerabilities are created equal. Based on the research, five risk classes account for the majority of documented exploits, and each requires a different mitigation approach.

1. Unauthenticated Tool Access

MCP servers default to no authentication. Any client can invoke tools with no identity check. This isn’t an edge case — it’s the default state for most frameworks. Without authentication, your MCP server’s tools are publicly callable by anyone who knows the URL, bypassing the agent entirely.

2. Prompt Injection via Tool Results

External content returned by tools can carry attacker instructions that the model treats as legitimate. The Supabase Cursor agent incident in June 2025 demonstrated this concretely: a privileged agent processing user-supplied support tickets was tricked into leaking integration tokens through prompt injection. Tool poisoning attacks succeed at 84.2% when auto-approval is enabled.

3. Over-Privileged Agent Access

Agents typically receive access to all tools for the full session. A PolicyLayer audit of 2,031 MCP servers found that 42% expose at least one tool that destroys data or executes commands, and 96.1% of all tools don’t warn the agent about destructive behavior. When an agent connects to a server with 50 tools and no capability scoping, every one of those tools is a potential blast radius.

4. Credential and Token Exposure

Long-lived OAuth tokens and static secrets held by agents create single points of credential failure. The n8n-mcp server — with 120,000+ weekly npm downloads — contained a critical cross-tenant credential theft flaw (CVE-2026-54052, CVSS 9.6) that allowed any authenticated tenant to read or delete another tenant’s workflow backups, including API keys and Bearer tokens stored inside them.

5. Missing Audit Trails

No structured log of which agent called which tool means incidents can’t be reconstructed. Most organizations have zero visibility into MCP servers running in their environments, with 200,000+ public instances unreported to security teams. You can’t govern what you can’t see.

The Governance Dilemma: Centralized Control vs. Deployment Flexibility

Here’s where the tradeoffs get uncomfortable. You need centralized governance to eliminate shadow MCP risk. But centralized governance platforms introduce concentration risk of their own.

On one side, platforms like MintMCP, RunLayer, and Composio offer security controls, SSO integration, tool-level policy enforcement, and complete audit trails. MintMCP is SOC 2 Type II audited, while Composio holds SOC2/ISO certification. RunLayer’s SOC 2 status is pending. AWS Managed MCP Server reached general availability in May 2026, offering IAM-based governance, sandboxed Python execution, and CloudTrail audit logs. These are the tools that give security teams the visibility they desperately need.

On the other side, most MCP governance vendors are US-headquartered and downstream of US hyperscalers designated as Critical ICT Third-Party Providers under DORA. That inherits CLOUD Act exposure. And confirmed Chinese state-sponsored operation GTG-1002 already uses MCP tool calls for 80–90% of intrusion work, making centralized governance platforms high-value targets for large-scale compromise.

The open-source alternative — gateways like Bifrost and IBM ContextForge — gives you self-hosted deployment and full security policy customization. But 14+ downstream CVEs have been traced to the MCP SDK’s by-design RCE flaw, and most enterprise teams lack the resources to audit third-party open-source MCP servers for hidden malicious behaviors.

There’s no clean answer. The right choice depends on your regulatory environment, your team’s security engineering capacity, and your tolerance for vendor concentration risk.

What Production Hardening Actually Looks Like

If you’re running MCP servers in production today, or planning to, here’s the minimum viable security posture based on the research:

Authentication and access control:

• Enforce OAuth 2.1 with resource-bound tokens on every MCP server. No exceptions for “internal” servers.
• Implement per-tool capability scoping. An agent reading from a database doesn’t need write or delete permissions.
• Rotate credentials on a defined schedule. No long-lived static secrets.

Isolation and sandboxing:

• Run MCP servers in containerized environments with filesystem and network jails. The Docker MCP Gateway was built specifically for this.
• Enforce per-tenant CPU and memory caps to prevent resource exhaustion attacks.
• Treat MCP configuration files as trusted code. Enforce command allowlists on any STDIO adapter.

Observability and response:

• Implement structured audit logging with prompt and secret redaction. Verbose JSON-RPC logs that capture argument values verbatim are a leak by design.
• Deploy a kill switch for runaway invocations.
• Run continuous discovery scans. If you don’t know what MCP servers are running in your environment, you can’t secure them.

Supply chain hygiene:

• Vet third-party MCP servers before connecting agents to them. Check for rug-pull patterns, tool poisoning vectors, and hidden behaviors.
• Pin SDK versions and monitor for CVEs. The MCP SDK’s by-design RCE flaw has spawned at least 14 downstream CVEs.

For a comprehensive audit framework, the 75-point MCP security checklist from Digital Applied covers eight threat domains and maps cleanly onto SOC 2 controls.

The Contradiction at the Heart of MCP

Here’s the tension that every engineering leader needs to sit with: MCP is simultaneously a production-ready enterprise integration standard and inherently too insecure for production use without full architectural overhaul.

The case for “production-ready”: AWS, Azure, and Google have all launched managed MCP servers with IAM integration and audit logging. Major vendors including OpenAI, Microsoft, and Cursor have adopted the standard as a core integration layer. The ecosystem has 97M SDK downloads.

The case for “insecure by default”: 30 CVEs in 60 days. 82% path traversal vulnerability rate. A by-design RCE flaw affecting 200,000+ instances that the upstream maintainer won’t patch. A nation-state operation weaponizing MCP for 80–90% of intrusion work.

Both of these are true at the same time. The protocol’s adoption is real and accelerating. Its security posture is, by any enterprise standard, unacceptable in its default state.

The Recommendation

Enterprises must classify MCP servers as privileged access workloads — not developer convenience tools — and enforce mandatory OAuth 2.1 authentication, per-tool capability scoping, and centralized governance before any production deployment. Post-incident patching cannot remediate systemic design flaws.

If you’re evaluating MCP governance platforms, the comparison below covers the key options across deployment model, compliance posture, and pricing:

Platform	Type	SOC 2	Deployment	Authentication	Best For
MintMCP	Commercial	Type II ✓	Cloud	OAuth, SAML, SSO	Regulated industries (healthcare, finance)
RunLayer	Commercial	Pending	Cloud or VPC	Okta, Entra	Security-first orgs with VPC requirements
Composio	Commercial	SOC2/ISO ✓	Cloud or self-hosted	Built-in	Rapid integration (500+ connectors)
Bifrost	Open source (Apache 2.0)	—	Self-hosted	—	Performance-focused teams wanting OSS
AWS Managed MCP	Managed service	—	AWS cloud	IAM + SigV4, OAuth 2.1 proxy	Teams already in AWS ecosystem

For teams just starting to map their MCP attack surface, begin with discovery. You can’t secure servers you don’t know exist. Then layer in authentication, scoping, and audit logging in that order.

The teams that get this right will be the ones that treat MCP security as infrastructure work — not a configuration step you’ll get to later.