The Model Context Protocol connected AI to everything in record time — but it standardized connectivity, not trust. Here’s what the 2025–2026 research shows, and why the whole game now comes down to building MCP right and connecting only what you trust.
The 60-second version
MCP is the “USB-C for AI.” Instead of building M×N custom integrations between AI apps and tools, everything speaks one protocol. And it worked: the ecosystem grew from roughly 50 servers at launch in November 2024 to an estimated 8,000–12,000 by mid-2026, and 41% of software organizations now run MCP servers in production.
But every server you connect is, in effect, a new third party with ambient access to your model’s context — and often to the actions it can take on your behalf. MCP treats that access as trusted by default. That’s the gap this post is about.
M×N custom connectors collapse into M+N. Add an app or a tool once, and everything connected can reach it.
It standardized connectivity — not trust
When a server lists its tools, it sends natural-language descriptions, and those go straight into the model’s context. The model reads them as instructions.
So the channel between a server and your model is a trust boundary — and MCP leaves it open by default. That single design choice is the root of every failure mode below.
Everything crossing the dashed line into the model’s context is server-controlled input.
What goes wrong
None of it is exotic. It’s what happens when an untrusted channel is treated as trusted.
Failure mode | What it is | Evidence |
|---|---|---|
Tool poisoning | Instructions hidden inside tool descriptions — seen by the model, not the user | 36.5% attack success across 20 agents; more capable models were more vulnerable (MCPTox) |
Rug pull | A tool approved on day one silently redefines itself by day seven | Re-routes arguments or credentials with no re-consent |
Indirect injection | Private data + untrusted content + an exit path, through a trusted channel | 85% success in the “Agentjacking” proof of concept; real CVEs |
Open & confused-deputy auth | Servers exposed with no authentication, or tricked into acting outside intent | 40% of live servers have no authentication |
Measured, not theoretical:
41% of software organizations run MCP in production (Stacklok, 2026)
40.6% of live remote servers expose tools with no authentication (arXiv 2605.22333 — 7,973 servers)
96.6% of tested OAuth-enabled servers had a client-registration flaw (same study)
10%+ of 10,000+ scanned servers leaked credentials, API keys, or PII (MCPPrivacyDetector)
What it takes: two directions
You lower MCP risk from two directions — how servers are built, and which servers you trust. Neither side is optional.
A. Build it right — if your team operates MCP servers
Authenticate by default. No tool should be reachable without authentication. Two in five live servers fail this today — it’s the floor, not a feature.
Never pass a token through. Validate every token’s audience, and when you call an upstream API, mint a fresh, correctly scoped token instead of forwarding the caller’s. Least privilege per tool.
Treat tool descriptions as a security surface. The description text becomes model instructions. Version and sign it, publish provenance, and never let a definition change silently after approval.
Contain the blast radius. Human approval on high-impact tools, sandboxing, and central logging of every call — so a successful injection is visible and bounded, not silent.
B. Use trusted sources — if your team connects MCP servers
Inventory every server as a third party. Each MCP server on a production agent gets an owner, a data-access scope, and a review date. You cannot govern what you cannot see.
Prefer vetted providers over anonymous installs. Provenance is the control that matters most. A reputable, accountable source beats a one-click registry server of unknown origin — that anonymous long tail is exactly where the no-auth, poisoning, and leakage numbers live.
Pin versions and watch for change. Pin the version you approved and alert on any tool-definition change, so a safe tool cannot quietly redefine itself after you trust it.
Scope tight and log everything. Least-privilege scopes per server and central logging of tool calls. Track the NSA MCP hardening guidance (July 2026) as your baseline.
The honest read
MCP solved a real, painful problem — which is why it won so fast. It standardized connectivity ahead of trust. The teams that win with MCP will be the ones that build it right and connect only what they trust — because this is not a new category of risk. It’s third-party risk, arriving faster than most vendor processes were built for.
Sources
Share
