[ LEARN // MCP SECURITY ]
The MCP Security Index 2026.
We surveyed the 50 most widely used public MCP servers — the layer through which AI agents reach GitHub, AWS, databases, browsers, and money — against a fixed security rubric. The result in one sentence: the ecosystem authenticates well, authorizes almost nothing, and rarely keeps evidence. The full dataset is public and CC BY 4.0.
[ THE HEADLINE NUMBERS ]
48%
no per-call authorization of any kind
24 of 50 servers execute any tool call a connected client sends — no permission model between connection and execution.
92%
no policy hooks
46 of 50 offer no extension point to intercept, evaluate, or deny a tool call before it runs.
58%
no audit logging documented
29 of 50 document no record of what was called, by whom, with what parameters.
78%
expose destructive tools
39 of 50 can write, delete, execute code, or move money through at least one tool.
30%
destructive + zero authorization
15 of 50 combine destructive capability with no per-call authorization at all.
56%
have documented security issues
28 of 50 carry at least one public CVE, advisory, or security write-up — 55 documented issues in total.
Population: the 7 active reference servers plus the 43 most-starred public vendor and community MCP servers on GitHub, assessed September 2026. Method, rubric, per-server evidence, and every documented issue with its source: github.com/sentnelops/mcp-security-index.
[ WHAT THE PATTERN SAYS ]
Read the fifty rubric rows together and the shape is unmistakable. The ecosystem has largely solved downstream authentication — servers hold scoped API keys for the systems they front. Hosted servers are converging on caller authentication via the spec's OAuth framework. What is almost uniformly absent is the layer in between: per-call authorization — may this caller invoke this tool, with these parameters, right now — and the evidence trail of what was decided.
That absence is not an accident of immaturity; it is a division of labor nobody accepted. Server maintainers reasonably treat authorization as the deployer's problem. Deployers assume the server, or the client, or the platform handles it. The result is the number that matters most in this survey: 30% of the most popular MCP servers expose destructive capability with no per-call authorization at all— and 92% offer no hook where anyone could add it. This is the layer AI agent runtime governance exists to fill, and it currently has to be added from outside.
[ FOUR THINGS THE DATA SHOWS ]
The reference servers set the tone
Anthropic's own Git reference server carried a three-CVE chain (path traversal → argument injection → RCE) exploitable via prompt injection; the Filesystem server's directory containment was broken twice (CVE-2025-53109/53110). If the reference implementations ship this way, downstream expectations follow.
Authenticated ≠ governed
HashiCorp's Terraform MCP server shipped a CVSS 10.0 cross-tenant credential-reuse flaw in stateless HTTP mode. Grafana's server allowed caller-supplied URLs to reach internal endpoints (CVSS 9.1 SSRF). Both authenticate callers; neither had a layer asking whether a specific call made sense.
Prompt injection cashes in on missing authorization
The canonical incidents all follow one shape: planted content steers an agent, and the blast radius is whatever its tools allow. Supabase's service-role access let ticket text exfiltrate a whole database. A malicious GitHub issue exfiltrated private-repo data through the official GitHub server's legitimate tools. A published Heroku exploit coerced an app-ownership transfer via log lines.
The counter-examples prove it's possible
PayPal's toolkit — which moves real money — ships a genuine per-action tool allowlist and sandbox-by-default. The containers/kubernetes-mcp-server passes the caller's own token through so cluster RBAC applies per call. MongoDB's server has op-type disabling and deletion confirmations. Good per-call governance exists; it's just rare.
Every claim above is sourced in the dataset — CVE identifiers, advisories, and write-ups with URLs, per server. Most cited issues are patched; the structural findings are the point.
[ HOW SENTNELOPS IMPLEMENTS THIS ]
[ FREQUENTLY ASKED QUESTIONS ]
What is the MCP Security Index?
A September 2026 survey of the security posture of the 50 most widely used public MCP servers — the 7 active reference servers plus the 43 most-starred public vendor and community servers — assessed against a fixed 15-field rubric covering transports, authentication, per-call authorization, scoping, audit logging, policy hooks, destructive capability, and documented issues. The full dataset is public under CC BY 4.0.
How were the findings produced?
By documentation and source inspection with evidence URLs recorded per server, plus one targeted search per server for public CVEs and advisories. It is a documentation survey, not a penetration test: where a control is not documented, the recorded value is 'none documented' — which is itself the finding, since an undocumented control is one deployers can't rely on.
What is the single biggest gap?
Per-call authorization. The ecosystem has largely solved authenticating servers to downstream systems and is converging on OAuth for callers, but 48% of surveyed servers have no mechanism to decide whether a specific tool call — this caller, this tool, these parameters — should execute, and 92% offer no hook where such a decision could be added.
Does a documented CVE mean a server is unsafe today?
No — most documented issues in the dataset are patched, and having public advisories often indicates an active security process. The issues matter as evidence of the failure modes the architecture allows; the structural findings (missing authorization, logging, and hooks) matter more than any individual bug.
How can maintainers correct an entry?
Open an issue or pull request on the dataset repository (github.com/sentnelops/mcp-security-index). Corrections are welcome and attributed; the survey's value depends on being accurate, and entries record what was documented at assessment time.
[ REFERENCES ]