MCP Security Checklist: 12 Controls Needed Before Production

Here’s a number that should stop you mid-scroll: 40% of public MCP servers have zero authentication. Not weak auth. Not misconfigured auth. None. That finding from internet-wide scanning that cataloged 12,520 exposed MCP services isn’t an edge case — it’s the baseline. The protocol that’s supposed to connect your AI agents to production infrastructure has a security posture closer to a 2014 PHP tutorial than enterprise middleware.

The 2026-07-28 specification, which ships July 28, makes this worse in the name of operational simplicity. I’ll walk through why, what actually puts you at risk, and the 12 controls that matter — based on what researchers are finding in the wild, not what the spec docs hope you’ll do.

The Stateless Spec Is an Operational Win and a Security Loss

The headline change in the 2026 spec is that MCP goes stateless. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Every request now carries client metadata in _meta and routes via Mcp-Method and Mcp-Name headers, per the readiness checklist. This means you can run MCP behind a plain round-robin load balancer with no shared session store. Serverless deployments get simpler. That’s the good news.

The bad news is what disappears with those enforced boundaries between tenants, between requests, between trust contexts — session hijacking as a protocol-level threat is gone, and that’s a real improvement. But it transfers all state integrity enforcement to individual implementers. And the data on implementer quality is brutal.

Akamai’s analysis identifies the core problem: predictable tracking IDs in the stateless model can enable workflow hijacking, cross-tenant data access, and unauthorized cross-tenant actions. When a server hands a client a state object and the client hands it back later, the server has to trust that object — or build custom cryptographic verification. Most teams won’t. The spec warns developers to verify these objects but sets no standard for how.

Think of it this way: the old spec had a known, protocol-level vulnerability class (session hijacking) that attackers could exploit. The new spec removes that class but introduces implementation-dependent risks that, based on current adoption data, are far more likely to be exploited because most implementers aren’t defending against them at all.

The Attack Surface You’re Actually Defending

MCP security risk breaks into three categories that cover nearly every real incident in 2026, as outlined in hardening guidance:

1. Tool poisoning — a malicious tool description manipulates the model into unsafe actions before the tool is ever called. The description lands in your model’s context the moment the client connects.
2. Indirect prompt injection — the tool is honest, but the data it returns (a web page, a ticket, a customer review) contains instructions the model then follows.
3. Supply-chain compromise — the server code itself is exploitable. An academic audit using VIPER-MCP found 106 zero-day vulnerabilities across 39,884 open-source MCP server repositories. 67 now have CVE IDs.

The third category is what makes MCP risk different from ordinary API risk. You’re not just defending your own code. You’re defending against every server you install, and the data on open-source server quality is not encouraging. An audit of 2,614 open-source MCP servers found 82% vulnerable to path traversal. That’s not a bug — it’s a pattern.

Then there’s the AutoJack exploit chain, disclosed June 18, 2026, which achieved zero-click RCE against Microsoft AutoGen Studio via MCP WebSocket. It chained three weaknesses: missing origin validation, missing authentication on MCP endpoints, and OS command injection through unsanitized server_params. A malicious webpage rendered by a local AI browsing agent could execute arbitrary code on the host. No user interaction beyond submitting a URL.

And the Appium MCP XSS flaw (GHSA-x975-rgx4-5fh4, CVSS 8.2) let a hostile mobile app hijack the AI agent testing it — via unescaped HTML in a locator generator UI. The tested app became the attacker.

The 12-Point Production Checklist

This is the control set I’d gate any MCP deployment against. It draws from the OWASP MCP Top 10 (published March 2026), the NSA’s hardening guidance (released May 20, 2026), the MCP Server Security Standard (24 controls across 8 domains), and the 75-point audit methodology built across 100+ production audits.

Authentication and Identity

1. Enforce OAuth 2.1 with PKCE — no exceptions. The 2026 spec bans legacy password and implicit grants. Every remote MCP server must require OAuth 2.1 with Proof Key for Code Exchange. If a server doesn’t support it, it doesn’t go to production.

2. Per-tool capability scoping — don’t issue blanket tokens. A token that can read email shouldn’t also be able to delete infrastructure. Scope tokens to the minimum set of tools the agent needs for the current task, not the full server surface.

3. Validate the MCP-Method and Mcp-Name headers against body content — the Streamable HTTP transport requires these headers, and your server must reject requests where headers and body disagree. This prevents smuggling and confused-routing attacks.

Input Validation and Execution

4. Treat all tool responses as untrusted input — prompt-injection vectors live in the strings your tools return. Any text content flowing back into the agent’s context is attacker-controllable. Sanitize outputs before they reach the model, or treat them like user messages.

5. Validate all parameter types at runtime — JSON Schema in your tool definition is not enough. The server must enforce types, ranges, and formats before execution. Reject unexpected parameters entirely rather than silently ignoring them.

6. Contain filesystem and network access — reject ../, absolute paths outside allowed directories, symlink traversal, and null bytes. Use Docker MCP Gateway or equivalent sandboxing to jail filesystem and network access per server.

Logging, Monitoring, and Governance

7. Redact PII in structured audit logs — verbose JSON-RPC logs capture argument values verbatim, including email addresses, API keys, and customer names. Redact at the structured-logging layer before persistence. Audit logs without redaction are a leak by design.

8. Implement resource quotas per tenant — the stateless spec’s “hit-and-run” task abuse vector lets attackers initiate costly operations that consume server resources. Set per-tenant CPU, memory, and invocation-count caps.

9. Maintain a server catalog with approval status — Shadow MCP (unapproved servers deployed by teams without IT visibility) is the new shadow IT, with estimates of 3–10× more servers than IT expects. You can’t govern what you can’t see.

Supply Chain and Client-Side

10. Vet third-party servers before connecting — check for auth implementation, input validation, recent commits, maintainer responsiveness, and known CVEs. The supply-chain risk is real: a connected server can steer a client into executing attacker-controlled actions, affecting 150M+ downloads per disclosed RCE-class flaws.

11. Verify state object integrity — if your server uses tracking IDs or state objects for cross-request workflows, cryptographically sign them and validate signatures on return. Predictable IDs enable cross-tenant hijacking.

12. Deploy behind an MCP gateway — centralize auth, audit, rate limiting, and credential brokering in a control plane rather than implementing it per server. This collapses your audit surface from dozens of servers to one. AWS reports that applying proper governance and testing can improve AI agent task accuracy by 28-32%.

The Compliance Gap You Can’t Ignore

SOC 2 scope follows data, not protocol. If an MCP server touches in-scope systems — customer records, financial data, source code — that server is automatically in scope, per compliance guidance. The five trust services criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) all apply.

Here’s the problem: the MCP spec provides no native controls for per-tool access scoping, structured audit logging, input validation, or data redaction. You have to build or buy those separately. The spec gives you a transport layer. It does not give you a compliance layer.

For teams operating in regulated environments, the MCP Server Security Standard offers 24 security controls across 8 domains with 4 compliance levels (L1-Essential through L4-Maximum Assurance). It’s the closest thing to a certifiable baseline the ecosystem has right now.

Where to Start If You’re Overwhelmed

If you do nothing else before July 28: enforce OAuth 2.1, validate headers against body, redact PII in logs, and deploy a gateway. Those four controls address the highest-frequency findings in public scanning data.

The deeper question is whether your organization should be connecting AI agents to production systems via a protocol whose security model depends entirely on implementer discipline — when all available data suggests that discipline is the exception, not the rule. That’s not a protocol question. It’s a governance question. And it’s the one that actually determines your risk.

If you’re still in pilot phase, this is the moment to read this. Retrofitting security after an agent is already operating against production data is significantly more expensive than building the controls before launch.