Security & Governance

MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them

By IdeaBosqueLast updated: July 26, 2026

Trend Micro scanned the internet and found 1,467 MCP servers sitting open — no authentication, no encryption, reachable by anyone. Practical DevSecOps found that 82% of 2,614 surveyed servers are vulnerable to path traversal. A protocol designed to connect AI agents to enterprise systems shipped without a production-security baseline, and the deployment patterns prove it: most teams exposed MCP to the internet before they hardened it. This checklist is the baseline that should have come first — 12 controls across transport, authentication, tool registration, runtime, and audit, each verifiable in under five minutes before an MCP server touches production traffic.

Key takeaways

1,467 MCP servers are publicly accessible with zero authentication or encryption — Trend Micro's corrected scan, July 2026. 1,227 of them run the deprecated SSE transport that the 2026-07-28 spec retires on a 12-month deprecation clock.
82% of 2,614 surveyed MCP servers are vulnerable to path traversal, and only 8.5% use OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. The attack classes are widespread in deployed servers, not theoretical.
3 CVEs landed in the official MCP Python SDK in July 2026 — CVE-2026-59950 (DNS rebinding/CSRF), CVE-2026-52869 (unverified session requests), CVE-2026-52870 (open task handlers). The reference implementation shipped the same class of flaw as the community servers.
78.3% attack success rate when 5 MCP servers connect to 1 agent — Palo Alto Networks Unit 42. Five servers is a typical deployment, not a large one. OX Security identified an architectural RCE affecting 150M+ downloads, and the Cloud Security Alliance classified MCP security as a systemic design-flaw problem.
The MCP 2026-07-28 specification ships as final on July 28, 2026 — all four Tier 1 SDKs (TypeScript, Python, Go, C#) speak the new stateless core, with a 12-month deprecation policy for SSE transport. The migration and the hardening are the same work.

A production MCP deployment that passes this checklist's 12 controls is not invulnerable — no system is — but it is no longer in the population that Trend Micro found, that Practical DevSecOps scanned, or that the July CVE wave caught. The checklist maps each control to the OWASP MCP Top 10 category it addresses, the CVE or exposure it prevents, and the verification step an operator can run in under five minutes. The Microsoft Agent Governance Toolkit — the first hyperscaler-shipped open-source governance runtime with 10/10 OWASP MCP Top 10 coverage — is the reference implementation. This article is the operational complement: a scannable hardening review for a Head of Engineering or platform lead preparing to expose an MCP server to production traffic.

The attack surface, in numbers

The OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) catalogs 10 named risk categories across the MCP-enabled system lifecycle. The numbers behind them are what turn "governance is good practice" into "governance is a production gate":

1,467 exposed servers — Trend Micro's corrected scan found 1,467 publicly accessible MCP servers with no authentication or encryption, up from an initial count of 492. 1,227 run the deprecated SSE transport. At least three expose patient medical records via a progress_note tool. The execute_sql tool appears on 70 hosts.
82% path-traversal exposure — Practical DevSecOps measured 82% path-traversal vulnerability and 8.5% OAuth adoption across 2,614 surveyed servers. 97M+ monthly MCP downloads means the exposure scales with adoption.
150M+ downloads affected by architectural RCE — OX Security framed the STDIO command injection root cause as an architectural-level flaw, not isolated CVEs. The Cloud Security Alliance classified it as a systemic design-flaw problem in AI agent infrastructure.
3 SDK CVEs in July 2026 — CVE-2026-59950 (missing Host/Origin validation, DNS rebinding/CSRF), CVE-2026-52869 (unverified session requests), CVE-2026-52870 (open task handlers). The official Python SDK — the reference implementation every Python MCP server inherits from — shipped the same class of flaw as the community servers it underpins.
3 new attack surfaces in the final spec — backslash.security identified three new attack surfaces introduced by the stateless redesign in the 2026-07-28 specification. New capabilities create new entry points that the security community is still mapping.

The cataam.com analysis frames the state of MCP security precisely: "MCP security is roughly where web security sat fifteen years ago — the attacks are old, only the target is new." The hardening checklist below is the set of controls that moved web security from 82% path-traversal exposure to a baseline where production systems are expected to pass. The same controls apply here.

The 12 hardening controls

The checklist organizes around five layers that map to the OWASP MCP Top 10 and the MCP 2026-07-28 specification changes:

Layer 1 — Transport and network

Control 1: SSE to Streamable HTTP migration. The MCP 2026-07-28 specification ships as final on July 28, 2026, with a 12-month deprecation policy for the HTTP+SSE transport. All four Tier 1 SDKs (TypeScript, Python, Go, C#) speak the new stateless core as of publication day, with migration notes for the breaking parts. The 1,227 deprecated-SSE servers in Trend Micro's scan are the population most affected — they run a transport the spec is retiring. Verification: check the server's transport configuration. If it serves SSE, it is on the deprecation clock. Migrate to Streamable HTTP before the 12-month window closes.

Control 2: Network isolation and origin validation. CVE-2026-59950 — confirmed in the National Vulnerability Database — is a missing Host/Origin validation flaw in the official MCP Python SDK. A web page the victim visits can drive their local MCP server via DNS rebinding and CSRF. The browser becomes the attacker's proxy into a loopback server the operator believed was private. Verification: confirm the server validates Host and Origin headers on every request. If the server is internet-facing, confirm it sits behind a network boundary that prevents direct access from untrusted origins. A server that should never have been reachable from the public internet must not be accessible from the public internet.

Layer 2 — Authentication and identity

Control 3: OAuth 2.1 + OIDC enforcement. The 2026-07-28 spec makes OAuth 2.1 plus OpenID Connect mandatory — a shift from the prior "bring your own token" approach. WorkOS's authentication migration guide details the requirements: RFC 8707 (Resource Indicators) to prevent token replay across servers, Client ID Metadata Documents replacing Dynamic Client Registration, issuer verification (RFC 9207). The Practical DevSecOps finding — only 8.5% of surveyed servers use OAuth — is the baseline this control lifts. Verification: check the server's authentication configuration. If it accepts unauthenticated requests or uses static API keys without OAuth, it fails. Confirm the server implements RFC 8707 resource indicators.

Control 4: Agent identity separation. NIST's AI Agent Standards Initiative (February 2026) proposes treating agents as distinct non-human identities with their own lifecycle: provisioning, attestation, revocation. Most deployments authenticate the human user and pass that identity to the agent. When the agent takes an action, the audit log says the human did it. Verification: confirm each agent has its own credential (OAuth token, SPIFFE SVID) distinct from the human operator's. Revoking the agent's identity should stop all agent calls without affecting the human's access.

Layer 3 — Tool registration and supply chain

Control 5: Tool poisoning scan. OWASP MCP03 names tool poisoning as a top-10 risk: rug pulls (trusted tools updated to malicious versions), schema poisoning (interface definitions corrupted to mislead the model), tool shadowing (fake tools intercepting calls meant for real ones). The Microsoft Agent Governance Toolkit's McpSecurityScanner detects tool poisoning, typosquatting, and hidden instructions — a demo tool named read_flie (typosquatting read_file) with injection in its description scored 85/100 risk. Verification: inspect the tool registration process. If tools are registered without a security scan, it fails. The scan must cover prompt injection patterns in descriptions, typosquatting against known tool names, and hidden system directives.

Control 6: Signed provenance and dependency monitoring. OWASP MCP04 covers supply chain attacks and dependency tampering. The Postmark MCP backdoor — the first malicious MCP server caught in the wild — was a legitimate-looking npm package that silently intercepted emails and exfiltrated them. It passed registry review. UpGuard's research found one in 15 MCP servers is a lookalike designed to impersonate a legitimate service. Verification: confirm every MCP server in the deployment has a signed provenance record and an AIBOM (AI Bill of Materials) inventory. Confirm dependency monitoring is active and alerts on new CVEs in the dependency tree.

Control 7: STDIO hardening. OX Security's disclosure identified an architectural RCE in STDIO configurations affecting 150M+ downloads. The root cause: shell: true in the TypeScript SDK enabled command injection via configuration strings. The Cloud Security Alliance classified this as a systemic design-flaw problem. Verification: if the server uses STDIO transport, confirm shell: false or equivalent hardening is set. Confirm command allowlists check arguments, not just binary names — the Upsonic and Flowise bypasses (CVE-2026-30625, CVE-2026-40933) showed that npx -c <malicious-command> passes through an allowlist that checks only the binary.

Layer 4 — Runtime and execution

Control 8: Rate limiting. Each tool declares its own rate limit in the registration call. The backbone enforces limits per-agent, per-tool, and per-window. When a limit is hit, the agent receives a 429 response with a Retry-After header. A compromised agent cannot exhaust upstream API quotas because the rate limit is enforced at the module boundary. Verification: confirm every registered tool has a rate limit. Confirm the limit is enforced at the module boundary, not at the upstream API. A tool without a rate limit is a tool a compromised agent can call without bound.

Control 9: Context boundary. OWASP MCP10 names context injection and over-sharing as a top-10 risk. An agent with broad context access leaks information across tenants, sessions, or users — a particularly acute concern for B2B deployments where the same agent serves multiple customers with different data-access rights. Verification: confirm each tool receives only the context it needs for its specific operation. Confirm the context window is scoped per-tool, not shared globally across all tools. A tool that receives the full session context when it needs only a single field is a data-leak surface.

Control 10: Kill-switch per module. Each MCP module must be independently disableable without touching the orchestration backbone. The kill switch is a configuration change, not a code deployment. When a vulnerability is disclosed — as the July CVE wave disclosed 3 SDK CVEs and 7+ server CVEs in a fortnight — the operator's first question is: can I disable this module without taking down the agent? In a governed deployment, the answer is yes. Verification: confirm each module can be disabled via a feature flag or configuration change. Confirm the disable path has been tested — not just configured. A kill switch that has never been exercised is a kill switch that will fail when it is needed.

Layer 5 — Audit and telemetry

Control 11: Per-call audit logging. OWASP MCP08 names lack of audit and telemetry as a top-10 risk. Without logs of tool invocations and context changes, token theft and injection remain invisible. Every tool call must log timestamp, agent ID, tool name, input hash (not raw input — PII boundary), output status, duration, and upstream system. Logs are structured JSON shipped to the observability pipeline. Verification: confirm every tool call produces a structured log entry. Confirm the log includes the input hash, not the raw input. Confirm the log is immutable — an attacker who compromises the server cannot rewrite the audit trail.

Control 12: Shadow server detection. OWASP MCP09 covers shadow MCP servers — unapproved or unsupervised deployments invisible to governance. UpGuard found one in 15 MCP servers is a lookalike. An engineer who installs the wrong mcp-server-postgress (note the typo) gets a package that silently exfiltrates SSH keys and .env files. Verification: confirm there is an inventory of every MCP server in the deployment. Confirm the inventory is checked against a registry of known-good packages. Confirm drift monitoring alerts when a new server appears that was not in the inventory.

How the frameworks map to the checklist

Control	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. SSE migration	—	12-month deprecation	—	—	—
2. Network isolation	MCP07	Origin validation	—	—	—
3. OAuth 2.1 + OIDC	MCP07	Mandatory auth	—	OAuth 2.0	—
4. Agent identity	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. Tool poisoning scan	MCP03	—	MCP Security Gateway	—	—
6. Signed provenance	MCP04	—	—	—	—
7. STDIO hardening	MCP05	—	—	—	Systemic design flaw
8. Rate limiting	—	—	Policy Engine	—	—
9. Context boundary	MCP10	—	Response sanitizer	—	—
10. Kill-switch per module	—	—	Hypervisor kill switch	—	—
11. Per-call audit logging	MCP08	—	Audit + metrics	—	—
12. Shadow server detection	MCP09	—	—	—	—

No single framework covers all 12 controls. The checklist is the intersection of OWASP, the spec, Microsoft, NIST, and CSA — each contributing the controls the others lack. The Microsoft Agent Governance Toolkit covers 10/10 OWASP MCP Top 10 categories (7/10 fully, 3/10 partial with roadmap) and is the first hyperscaler-shipped open-source runtime with explicit OWASP mappings — 68 tests in the Agent OS Policy Engine, 127 tests in the MCP Security Gateway, 80 tests in the Agent Hypervisor Execution Control including the kill switch.

Scoring the checklist

A production-ready MCP server passes all 12 controls. A partially-ready server passes 8–11. A server that passes fewer than 8 should not be exposed to production traffic without a documented remediation plan and a target date for each failed control.

Score	Status	Action
12/12	Production-ready	Deploy with monitoring
8–11/12	Partially ready	Deploy with documented exceptions and remediation timeline
<8/12	Not ready	Do not deploy. Remediate failed controls first

The most common failure pattern is passing controls 1–4 (transport, authentication, identity) while failing controls 5–12 (supply chain, runtime, audit). The first four are architectural and get attention in design reviews. The last eight are operational and get missed until an incident or an audit surfaces them. The July 2026 CVE wave — 3 SDK CVEs and 7+ server CVEs in a fortnight — is what happens when the operational controls are absent.