The Model Context Protocol, introduced by Anthropic in November 2024, standardizes how AI models connect to external tools and data. Before it, every integration needed custom code. After it, a model could talk to a database, a file system or an API through one interface.
Adoption was fast. The public server registry grew from roughly 1,200 entries in early 2025 to more than 9,400 by mid-April 2026 — a seven-fold expansion in about fourteen months.
MCP security is the practice of governing what happens at the join between a model and the tools it can invoke. That includes who may connect, what a server may expose, what a tool may actually do when called, and whether any of it can be reconstructed afterwards.
The protocol solved a genuine integration problem. It also created a new trust boundary, and that boundary was not designed with adversaries in mind.
Key Takeaways
- MCP security fails at a specific seam: the tool description field is unsanitised text that the model reads as instruction and the user never sees.
- Roughly 40% of internet-exposed MCP servers accept requests with no credential check. Among those that do authenticate, 53% rely on static API keys alone.
- The 2026-07-28 specification revision is the largest since launch and makes MCP servers formal OAuth 2.1 resource servers. Much published guidance still describes the older, weaker model.
- Published vulnerability rates vary enormously by methodology, and one audit found a 78% false-positive rate from YARA-based MCP scanners. Treat single percentages with caution.
- Most disclosed MCP CVEs are not novel AI attacks. 43% of CVEs filed in early 2026 were shell injection.
Quick Navigation
- The Model-to-Tool Boundary Explained
- Why MCP Security Fails at the Description Field
- The Four Baseline MCP Security Failures
- What the MCP Security Scan Data Shows
- Reading MCP Security Statistics Critically
- The MCP Security CVE Record
- Supply Chain Incidents Worth Knowing
- How the July 2026 Spec Changes MCP Security
- Where MCP Security Enforcement Should Live
- An MCP Security Checklist That Holds Up
- Primary sources
- Frequently Asked Questions
The Model-to-Tool Boundary Explained
To see where things break, follow what happens when an agent connects to an MCP server.
The server advertises its tools. For each one it sends a name, a description in natural language, and a parameter schema. The client loads all of that into the model’s context so the model knows what is available and when to use it.
The user sees a friendly label — something like “Send email” in a list of connected capabilities.
The model sees the full description text.
Those two views are not the same, and the gap between them is the whole problem. The description field is where the server tells the model how to behave. It is unsanitised by design, it is rarely rendered in any interface, and almost nobody reads it after the first install.
This is the distinction between systems that generate text and systems that take actions, explored further in our comparison of agentic AI and generative AI. A tool description is not documentation. It is executable influence.
Why MCP Security Fails at the Description Field
Invariant Labs first documented tool poisoning in April 2025. The mechanism is simple enough to state in a sentence: a malicious or compromised server embeds instructions inside what looks like help text, and the agent follows them.
OWASP ranks this at position three in its MCP Top 10, a framework currently in beta under project lead Vandana Verma Sehgal.
Three properties make this class unusually difficult.
It is invisible to source-code scanning. SAST and SCA tools read code. A poisoned description lives in a metadata field the scanner has no reason to parse. A clean scan tells you nothing about it.
It persists. A document-borne injection has to be delivered again each time. A poisoned description ships with the server and fires on every invocation, in every session, for every user, until someone reads the metadata.
Approval happens once. Users approve a tool at install and never revisit it. That is what makes rug pulls work — a server can redefine a tool’s description silently after approval.
Microsoft’s guidance reframes this usefully: treat a tool description change as equivalent to a dependency update. It is a modification to a software artifact that directly changes agent behavior, and it deserves review before deployment. The recommended controls follow from that framing — signed tool manifests, automated metadata scanning for embedded instructions, and dynamic tool scoping that limits an agent to the specific tools a session needs.
The Four Baseline MCP Security Failures
Four classes appear across essentially every serious MCP security resource. They are the vocabulary you need before anything else makes sense.
Tool poisoning. Hidden instructions in tool descriptions or metadata. The model reads and acts on them; the user sees only the benign label.
Confused deputy. An MCP proxy holding elevated privileges performs an action for a user without verifying the user was entitled to it. The server’s permissions become the user’s permissions.
Prompt injection through tool output. A tool returns attacker-controlled content in a free-text field, and that content enters context as though it were data rather than instruction.
Token pass through. A server accepts a token issued for a different service and forwards it downstream without validating the audience. The specification explicitly forbids this as an anti-pattern, which tells you how often it happens.
Two further classes matter in multi-server deployments. Tool shadowing occurs when one server’s description manipulates how the agent uses a different server’s tools. Cross-server cascade describes what happens next: research indicates a 72.4% cascade rate once multiple connected servers are compromised.
What the MCP Security Scan Data Shows
The empirical picture is worse than the taxonomy suggests, though the numbers need care.
| Finding | Figure | Source context |
|---|---|---|
| Publicly exposed MCP services | 12,520 | Censys scan |
| Exposed servers with no authentication | ~40% | Multiple converging scans |
| Authenticating servers using static API keys only | 53% | Same scan population |
| Servers implementing OAuth 2.1 | 8.5% | Registry analysis |
| File operations vulnerable to path traversal | 82% | 2,614 surveyed servers |
| Command injection exposure | 34% | Same 2,614 servers |
| SSRF exposure | 30–36.7% | BlueRock / Equixly |
| Zero-days found by automated repo scan | 106 | VIPER-MCP, 39,884 repos |
The authentication figure is the one to sit with. Roughly four in ten internet-accessible MCP servers accept requests from anyone, and of the remainder, half use a single long-lived credential with no expiry and no per-operation scope.
Meanwhile, GitGuardian found 24,008 secrets in MCP-related configuration files on public GitHub, of which 2,117 remained valid.
None of this is exotic. Path traversal, command injection and missing authentication are classic web application failures wearing new clothes. The novelty is the blast radius: these servers sit inside agent workflows with access to whatever the agent can reach, a mapping problem covered in the five hidden layers of the AI attack surface.
Reading MCP Security Statistics Critically
Here is the part most coverage omits, and it matters if you plan to cite any of these numbers.
Reported tool-poisoning prevalence ranges from about 5.5% of 1,899 servers in one academic study, to 23% of servers showing suspicious instruction-like patterns in an Invariant Labs scan, to 66% of community servers carrying at least one critical code smell in another analysis.
Those are not the same measurement. “Contains an instruction-like pattern” and “is actively malicious” are different claims, and conflating them inflates the problem.
More pointedly: an independent audit in April 2026 found roughly a 78% false-positive rate from YARA-based MCP scanners. Any raw “X% of servers are vulnerable” figure should be read against the detection method that produced it.
Unauthenticated-server counts vary the same way — 1,862 in a July 2025 scan, 8,247 in an Invariant Labs scan in January 2026, around 40% of 12,520 in Censys data. Different populations, different dates, different definitions of exposure.
The direction is unambiguous and the magnitude is contested. Both facts belong in any honest summary.
The MCP Security CVE Record
Between January and February 2026 alone, researchers filed more than 30 CVEs against MCP servers, clients and tooling. The breakdown is instructive: 43% were exec or shell injection, 20% were flaws in tooling infrastructure such as clients and inspectors, and 13% were authentication bypass.
Four are worth knowing by name.
CVE-2025-6514 (CVSS 9.6) affected mcp-remote, a package downloaded more than 437,000 times. Disclosed by JFrog in July 2025, it allowed remote code execution triggered by a malformed response from a compromised server — described at the time as the first real-world full RCE on a client operating system through an untrusted remote MCP server. Fixed in version 0.1.16.
CVE-2025-49596 (CVSS 9.4) hit Anthropic’s own MCP Inspector, enabling RCE via browser and DNS rebinding.
CVE-2026-30623 is the structurally interesting one. A command injection flaw in the STDIO transport interface across all four official SDKs — Python, TypeScript, Java and Rust — affecting a reported 200,000+ instances across 7,000+ public servers, with proven exploits against LiteLLM, LangChain and IBM LangFlow. At least ten CVEs trace to this single class.
Anthropic’s position on it was that this is expected behavior, with input sanitisation the developer’s responsibility. That is a defensible reading of a transport-layer specification and a genuine problem for everyone who assumed the SDK handled it.
CVE-2026-26118, an SSRF in the Azure MCP Server, exploited OAuth proxy trust. Authentication existed; the authorization boundary did not.
Supply Chain Incidents Worth Knowing
Two incidents show the ecosystem risk rather than the protocol risk.
postmark-mcp. In September 2025, Snyk documented a malicious npm package version that silently blind-copied every processed email to an external domain. It was the first tracked malicious-MCP-server supply-chain incident, and the mechanism required no protocol flaw at all — just a package doing something extra.
IDE auto-execution. A vulnerability class concerning the conditions under which developer IDEs execute MCP servers was reported to Amazon on 20 April 2026, received an initial fix on 12 May, and was publicly disclosed under Security Bulletin 2026-047-AWS on 26 June. Combined with description poisoning, auto-execution creates a compound surface reaching well beyond a single workstation.
The pattern to take away: the protocol’s security properties and the ecosystem’s security properties are separate things, and the ecosystem is where most incidents originate.
How the July 2026 Spec Changes MCP Security
A large amount of published MCP security guidance is now describing a specification that no longer exists. This is worth correcting carefully.
Early MCP made authorization effectively optional, which is where the widely repeated criticism comes from. That changed in stages. The June 2025 revision separated the MCP server (resource server) from the authorization server role and replaced fallback endpoints with mandatory Protected Resource Metadata under RFC 9728. The November 2025 revision required OAuth 2.1 with PKCE for remote servers.
The 2026-07-28 revision — released as a candidate on 21 May and described by maintainers as the largest since launch — went furthest. It removes sessions, drops the initialization handshake, deprecates three core features, rewrites authorization, and introduces an extensions framework.
For security specifically: MCP servers are now formally OAuth 2.1 resource servers, must implement RFC 9728 so clients can discover the correct authorization server automatically, and must use audience-bound tokens so a token issued for one server cannot be replayed against another. Clients must send resource indicators regardless of whether the authorization server supports them.
The caveat that matters: a specification requirement is not a deployment reality. Only about 8.5% of servers implement OAuth 2.1, and local STDIO servers sit outside the remote-server requirements entirely. The spec has largely caught up. The installed base has not.
Where MCP Security Enforcement Should Live
One architectural question decides whether the checklist above is achievable or aspirational: where does enforcement happen?
Three options exist, and only one scales.
In the model. Prompt the agent to ignore suspicious tool descriptions. This fails for the same reason every instruction-based defense fails — the poisoned description is also an instruction, and the model has no reliable way to rank them.
In each server. Ask every MCP server to validate its own inputs and scope its own permissions. This is correct in principle and unachievable in practice, because you do not control most of the servers you connect to, and 43% of early-2026 CVEs were shell injection in exactly these servers.
In a gateway between them. A proxy that intercepts every tool invocation, checks the caller’s identity, evaluates the requested operation against policy, and forwards the call only if it passes.
The gateway is the only position with both the visibility and the authority to enforce anything. It sees every call regardless of which server would handle it, and it can refuse.
This is the same reference-monitor pattern security has used for decades, applied at a new boundary. A production arrangement circulating in 2026 pairs workload identity for the agent, a relationship-based authorization service holding the permission graph, and a gateway that consults that service before forwarding any tool call.
Two practical notes. A gateway does not stop tool poisoning — a poisoned description still reaches the model — but it does stop the resulting call if that call falls outside policy. And it gives you the per-request logging that OWASP flags as absent by default, which is what makes incidents reconstructable afterwards.
Adoption friction is real. Roughly 38% of organisations report that security concerns are actively blocking MCP adoption, and 50% of MCP builders name access control as their hardest problem. A gateway addresses both, at the cost of a component someone has to run.
An MCP Security Checklist That Holds Up
Ordered by what actually reduces exposure rather than what is easiest.
Treat every MCP server as an untrusted third party. This is the Cloud Security Alliance’s framing and the correct default, including for internal servers.
Pin tool versions and signed schemas at install. Then alert on any description drift afterwards. This is the only control that addresses rug pulls, because it targets the change rather than the content.
Require authentication on everything reachable. OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, audience-bound tokens. If you inherited static API keys, that is the first migration.
Never forward a token you did not validate. Token pass through is a named anti-pattern for good reason.
Isolate sensitive servers from general-purpose ones. A poisoned tool should not be able to reach across into a privileged server without crossing another boundary.
Show the full tool call, not a friendly summary. Users cannot approve what they cannot see. Where automated enforcement is immature, human-in-the-loop approval on the tool list is doing real work.
Log every tool call with arguments and output. OWASP includes insufficient logging in its Top 10 because most clients and servers log almost nothing by default. Without per-request logs there is no forensic trail.
Inventory shadow servers. A developer installs a community server for convenience, it works, nobody audits it, and it inherits everything the agent can reach.
Primary sources
- Model Context Protocol specification
- OWASP MCP Top 10
- Cloud Security Alliance — MCP Security Crisis research note
- Microsoft — The state of MCP security in 2026
- CSA — MCP tool poisoning and auto-execution
Frequently Asked Questions
Is MCP inherently insecure?
No. MCP standardizes a connection that previously happened through ad-hoc custom code, which was not safer — just less visible. The issue is that early revisions left authorization optional and the ecosystem grew faster than its security practices.
Does the 2026-07-28 spec fix MCP security?
It substantially improves the authorization model. It does not address tool poisoning, which lives in the description field rather than the author layer, and it cannot force existing deployments to comply.
How do I detect a poisoned tool description?
Read the raw metadata, not the UI label. Then pin the schema and alert on changes. Automated metadata scanning helps but carries high false-positive rates, so treat alerts as triage input rather than verdicts.
Are local STDIO servers safer than remote ones?
Not automatically. They avoid network exposure but sit outside the remote authorization requirements, and CVE-2026-30623 affected the STDIO transport across all four official SDKs.
What single control gives the most MCP security benefit?
Authentication on every reachable server, given that roughly 40% currently have none. After that, pinning tool schemas and alerting on drift.
Keep reading
Here are the latest posts from the blog.
MCP Security: Where the Model-to-Tool Boundary Fails
AI Agent Identity: The 4 Critical Risks of Shared Credentials
AI Agent Security: The Hidden Gap Between 14% and 89%
