Ask whether MCP is secure and you get a shrug dressed up as an answer, because the honest reply depends entirely on which server someone happens to be running. The protocol itself does not decide mcp security for you. It leaves the hard parts open, and the data from the first serious measurement studies of real, live servers shows what happens when that gap goes unfilled.
What the numbers actually say
Researchers scanned 7,973 live remote MCP servers in a study published in May 2026 and found that 40.55% of them exposed tools with no authentication mechanism at all. Not a weak one. None. Anyone who found the endpoint could call the tools behind it.
The servers that did implement authentication were not much better off. Of 119 OAuth-enabled servers tested in the same study, every single one carried at least one authentication flaw, 325 flaws across the set, and dynamic client registration issues alone showed up in 96.6% of them. That work led to nine CVE assignments through responsible disclosure.
Separately, a April 2026 disclosure by OX Security found something worse than a misconfigured server: a design default sitting inside the official MCP SDKs themselves, the code most third-party servers were built on top of rather than written from scratch.
"A systemic architectural flaw disclosed in April 2026 by OX Security exposes an estimated 200,000 vulnerable instances."
Cloud Security Alliance research note, on the OX Security finding, "The Mother of All AI Supply Chains"
That finding traced through a supply chain of more than 150 million package downloads, and it had already been weaponised for authenticated remote code execution against Letta AI and unauthenticated server takeover against LangFlow by the time the research note was published. Not a hypothetical. Live.
| Finding | Measured scope | Source |
|---|---|---|
| Servers with no authentication at all | 40.55% of 7,973 live remote servers | First measurement study on MCP authentication, May 2026 |
| OAuth-enabled servers with at least one flaw | 119 out of 119 tested | Same study, 325 flaws, 9 CVEs |
| Dynamic client registration flaws | 96.6% of tested OAuth servers | Same study |
| Instances reachable through the SDK design default | Roughly 200,000, across 150M+ downloads | CSA research note on the OX Security disclosure, May 2026 |
Table 1: what the first wave of independent measurement found in production MCP deployments, not in a lab.
The two questions that keep getting collapsed into one
Most of the confusion around mcp security comes from treating authentication and authorization as the same job. They are not, and the gap between them is exactly where the incidents above happened.
Authentication answers one question: who is opening this connection. A static bearer token, an API key, or a full OAuth flow can all answer it, with varying degrees of rigour. MCP authentication patterns covers all four in detail, and each one leaks in a genuinely different way once a credential is compromised.
Authorization answers a completely separate question: given that a caller is who they say they are, what are they actually allowed to see or do. A server can run flawless OAuth and still hand every authenticated caller identical access to everything behind it, because nothing in the OAuth handshake resolves a session down to a specific person with specific, scoped grants. That second step has to be built deliberately. It does not arrive as a side effect of the first.
Why tool poisoning does not need a stolen credential
Tool poisoning skips authentication entirely. The attack plants instructions inside a tool's own name, description, or metadata rather than inside the visible conversation. An agent deciding how to use a tool reads that description as part of its reasoning, and a person watching the chat window sees none of it, because the poisoned text never appears there. A server can be perfectly authenticated and still hand an agent a weapon shaped like documentation.
Why the confused deputy problem is a design flaw, not a bug
A confused deputy is a server, or something sitting in front of one, using its own broad privileges to act on behalf of a caller who never actually held them. In MCP specifically this shows up as a token issued for one server being replayed against a different one, which is exactly what the specification's resource indicator requirement exists to close.
"MCP clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707 to explicitly specify the target resource for which the token is being requested."
Model Context Protocol specification, Authorization
Naming the resource explicitly is a small requirement with an outsized effect, because an agent juggling several MCP connections at once is exactly the situation where a token meant for one server ends up presented to another, and a confused deputy does not require a leak. It only requires ambiguity about which resource a token was ever meant for.
A practical mcp security checklist
None of the following is exotic. It is the gap between the 40.55% of servers running with nothing and the servers that did the ordinary work.
- Never run a remote server with no authentication mechanism at all. That single choice put four in ten measured servers into the worst-case column, and it is the cheapest fix on this list to make.
- Treat OAuth as answering "who," not "what." Pair it with a per-caller authorization check on every call, not just at connection time. Governing tool access per person, not per server is the pattern this splits into in practice.
- Implement resource indicators (RFC 8707) so a token scoped to one server cannot be replayed against another, which closes the specific confused deputy path the spec calls out by name.
- Audit tool descriptions the same way you would audit code, because an agent reads them as instructions whether or not a person ever does. What the mcp registry does not check is a good place to see why listing does not equal vetting.
- Log every call, including refused ones, before the entitlement check runs, so a denied attempt leaves the same audit trail a successful one does.
- Do not assume a vetted SDK means a vetted implementation. The SDK-level flaw behind the 200,000-instance figure sat in the reference code most third-party servers trusted without re-reading.
None of these six steps needs a specialist team to run. What they need is someone treating the checklist as mandatory rather than aspirational, which the 40.55% figure suggests is exactly what most deployments are still skipping.
Where a governance layer helps, and where it does not
It is tempting to treat "add a gateway" as the whole fix, and worth being precise about what that does and does not solve. Contextely's own MCP pillar page is explicit that it is not a transparent MCP proxy: a tool only becomes reachable once an administrator enables it and names the scope it requires, rather than every upstream tool appearing the moment a server is connected. That is more setup than a drop-in proxy, and it is a deliberate trade for the entitlement check most incidents above are missing.
It is equally worth being explicit about the limit on the other side. A passthrough answer is not ranked or rewritten. Entitlement gates whether a live tool call happens at all, not what comes back once it does, and the reply is exactly what the upstream system gave, logged either way. A governance layer decides who gets to ask. It does not vouch for the shape of the answer.
Frequently asked questions, answered briefly
The numbers above are unlikely to sit still. A field this young moves fast, and a specific vulnerability count from May 2026 will look dated within a year the way most security statistics do. What should hold up longer is the underlying split: authentication and authorization are different jobs, tool poisoning and the confused deputy problem do not require a compromised credential, and a server built on a trusted SDK still needs its own review rather than inherited confidence. Self-hosted MCP governance walks through what closing these gaps actually costs to run yourself, and /security documents how Contextely stores and rotates the credentials this whole piece has been about.