MCP Servers: What We Found When We Actually Looked

The Question Nobody Was Asking

Over the past year, we kept hearing the same pattern from security teams: "Our developers are more productive than ever with AI assistants, but we can't shake the feeling we're missing something."

They were right.

Between October 2024 and November 2025, Model Context Protocol servers went from 3 published implementations to 6,878. That's 2,200% growth in 13 months. November alone added 996 new servers - that’s more than the protocol's entire first six months combined.

Developers installed these servers everywhere. Security teams saw nothing.

So we decided to look.

What We Actually Found

The numbers tell a story that should concern every security team:

In a typical 10,000-person organization, 15.28% of employees (1,528) are running an average of 2 MCP servers each. That's 3,056 total deployments. Of these, 38% (1,161 servers) are unofficial implementations from unknown authors. These are not official vendor-published tools, they're community packages from npm, GitHub repositories with anonymous authors, that appeared in search results.

Every one of these servers requires Non-Human Identities to function. AWS access keys. GitHub personal access tokens. Database passwords. Service account credentials. OAuth tokens. Developers store these in plaintext .env files, JSON configs, and environment variables. The MCP server reads them directly when it starts.

But here's what makes this different from typical shadow IT: 86% of users choose local MCP server architecture despite remote alternatives being available from major vendors. Local architecture means the code runs on developer endpoints with full privileges. No sandboxing. No credential isolation. Direct filesystem access to every location where developers store secrets.

The installation experience requires no approval and generates no security alert. A developer types npm install -g salesforce-mcp-enhanced or npx -y github-automation-pro, and within seconds, arbitrary code from an unknown author is running with full access to their credentials. Some developers use the npx -y flag, which auto-accepts all prompts. It's the "I'm feeling lucky" approach to security.

95% of these servers run on employee endpoints where traditional security tools have no MCP-specific detection capabilities. The remaining 5% run in production - CI pipelines, cloud workloads, Kubernetes pods, all with access to deployment keys and credentials that have broader privileges than individual developer accounts.

The Services at Risk

The 3,056 servers we found connect to 115 distinct enterprise services. And there are not a collection of some obscure tools, these are the systems that run modern enterprises:

• AWS leads cloud infrastructure at 5.0% of deployments.
• Atlassian dominates collaboration tools at 12.3%.
• GitHub represents 3.6% of deployments.
• Docker accounts for 4.7%.
• Then there's Terraform, Postgres, Snowflake, Slack, Notion, and 107 others.

Each deployment represents non-human identities at risk. Each unofficial server (38% of the total) represents unvetted code with direct access to those credentials.

Why This Happened

The architecture creates the vulnerability. MCP servers operate in two modes: remote and local.

Remote servers run in vendor-controlled environments. Your AI assistant sends requests to secure infrastructure, the server executes actions, credentials never leave the hosting environment. The trust boundary holds.

Local servers run as arbitrary processes on endpoints. They're installed via package managers, configured with local credentials, executing with developer privileges. This is where 86% of adoption concentrates.

Developers choose local despite remote alternatives for a reason. Local servers provide flexibility, immediate access, and no intermediary infrastructure. The market has spoken: 86% local, 14% remote. This isn't going to reverse.

The package managers that distribute these servers (npm, PyPI, GitHub), provide no meaningful verification. npm doesn't require code signing. GitHub repositories can be created anonymously. Package names aren't protected. You can publish @mcp/server-salesforce without Salesforce's permission. Download counts and GitHub stars are easily manipulated.

On a side note, our analysis found that 3% of published MCP servers contain valid, hardcoded credentials in their source code. AWS keys, GitHub tokens, Anthropic Claude API keys, Stripe keys - active credentials embedded in packages published to npm and GitHub. This give us a good sense of the ecosystem's baseline security posture.

The Detection Gap

Traditional security tooling wasn't designed for this. Endpoint security tools see a node or python process started by Claude Desktop, a legitimate application starting a legitimate interpreter. The process reads files, makes HTTPS requests, nothing unusual. Firewalls see encrypted egress to domains with neutral reputation. CASB or SASE tools don't categorize developer tools as SaaS applications requiring monitoring.

The installation pathway bypasses security review entirely. Package managers are trusted development infrastructure. Developers install packages constantly. Security teams have no visibility into which npm packages land on endpoints, what those packages do, or what credentials they access.

The result: security teams cannot answer basic questions. What MCP servers exist in our environment? Which are official vendor implementations versus community packages? What credentials have been configured? What network connections are they making? What actions are they performing?

What This Means

We're not writing this to create fear. We're writing this because the data demands it.

• The MCP ecosystem will continue growing. December will add more servers. January will add more.
• The 38% unofficial rate will remain stable because registries don't verify packages.
• The 86% local preference will persist because developers choose it for legitimate productivity reasons.

This research provides the baseline. Download the full report here for the complete analysis, including service distribution breakdowns, and the behavioral patterns we observed across enterprise deployments.

There’s no debate over whether MCP servers provide value. They do, and developers adopt them because they work. What remains to be seen is whether security teams will build visibility into this adoption before it becomes a crisis or an unplanned incident response exercise.

At Clutch, we built our platform to provide that visibility and governance. Not because we predicted MCP servers specifically, but because we understood that non-human identity security requires seeing how credentials are actually used in modern development workflows. MCP servers are the latest example of a pattern we've been tracking: developers will always find faster ways to work, and those ways will always involve credentials.

The 2,200% growth rate proves the pattern isn't slowing down. The 38% unofficial rate proves the risk is anything but theoretical. The 86% local adoption rate proves the architecture isn't changing.

Security must adapt to this reality. The alternative is operating 1,161 unofficial servers with access to your infrastructure credentials while hoping none of them are malicious.

That's not a strategy. That's a gamble.

Ready to understand your MCP exposure? Talk to our team about how Clutch provides visibility into MCP servers, non-human identities, and the AI agents using them.