Topic starter
02/01/2026 11:40 am
TL;DR: MCP servers grew from 3 published implementations to 6,878 in 13 months, while a typical 10,000-person organisation now runs 3,056 deployments and 38% are unofficial packages from unknown authors, according to Clutch Security. The governance gap is not discovery alone: local execution, plaintext credential handling, and no package verification turn MCP adoption into a standing NHI risk.
Editorial analysis by NHI Mgmt Group, based on content published by Clutch Security: “MCP Servers: What We Found When We Actually Looked”.
By the numbers:
- MCP servers went from 3 published implementations to 6,878 in 13 months, according to Clutch Security.
- November alone added 996 new servers, more than the protocol's entire first six months combined, according to Clutch Security.
- Clutch Security found that 38% of MCP servers, or 1,161 deployments, were unofficial implementations from unknown authors.
Key questions
Q: What breaks when MCP servers run as local processes on developer endpoints?
A: Local execution breaks the assumption that package installation is separated from credential access.
Q: Why do unofficial MCP packages increase credential exposure risk?
A: Unofficial packages increase risk because authorship, provenance, and code integrity are weakly verified in common registries.
Q: How should teams detect MCP-related credential use they cannot currently see?
A: Teams should combine endpoint telemetry, package inventory, and secret-access monitoring to identify which processes read credential stores and which services they contact.
Practitioner guidance
- Establish an MCP server inventory Catalogue every MCP package running on employee endpoints, including source, author, install method, and the credential stores it can access.
Bottom line: MCP server adoption is turning developer endpoints into identity-rich execution environments where local code can reach enterprise secrets directly.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
06/10/2026 10:22 pm
Local MCP execution is the governance assumption that breaks first: the model assumes code running on a developer endpoint is still bounded by endpoint trust and ordinary software installation controls. That assumption fails when the server can directly read the same plaintext secrets that power enterprise access. The implication is that MCP governance is not a plugin review problem but a runtime identity boundary problem.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
A: They should do so as soon as MCP servers can read enterprise credentials or interact with production systems. At that point, the control problem is no longer about developer productivity or app installation. It is about who can use non-human credentials, from which runtime, and under what governance.
👉 Read our full editorial: MCP server sprawl is exposing enterprise credentials at scale