MCP server sprawl is exposing enterprise credentials at scale

At a glance

What this is: MCP server adoption has surged rapidly, and the central finding is that most deployments run locally with weak visibility, unofficial packages, and exposed NHI credentials.

Why it matters: IAM teams need to treat MCP servers as a non-human identity governance problem because the deployment model changes who can see credentials, who can approve access, and how quickly sprawl becomes exposure.

By the numbers:

• Between October 2024 and November 2025, Model Context Protocol servers went from 3 published implementations to 6,878.
• Of these, 38% are unofficial implementations from unknown authors.
• 86% of users choose local MCP server architecture despite remote alternatives being available from major vendors.

👉 Read Clutch Security's analysis of MCP server sprawl and credential exposure

Context

MCP server security is a non-human identity problem because every server depends on credentials, tokens, or service accounts to do useful work. The risk starts when those identities are stored in plaintext, inherited by local processes, or used by code the organisation has not vetted.

The primary failure is not that developers are adopting AI tooling. It is that the current control model does not reliably see where MCP servers are installed, which credentials they touch, or whether the package behind them is trustworthy. That makes MCP deployments a visibility and governance gap, not just a tooling trend.

Key questions

Q: What breaks when MCP servers run locally without governance?

A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point. That breaks the assumption that credential use is limited to known services. The practical result is hidden NHI sprawl, with no reliable inventory or review path for the identities doing the work.

Q: Why do MCP servers increase non-human identity risk so quickly?

A: MCP servers connect directly to enterprise services using credentials such as API keys, tokens, and service accounts, so every new deployment expands the number of identities that can reach sensitive systems. The risk rises quickly when those servers are unofficial, locally installed, and invisible to security teams. That combination turns convenience into unmanaged access.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Should organisations block local MCP servers or govern them differently?

A: Blocking may be appropriate for high-risk environments, but most organisations will need to govern local MCP servers rather than assume they can eliminate them. The decision should follow the value of the use case, the sensitivity of the connected systems, and the maturity of secret handling. If local execution is allowed, it needs compensating controls and strict package approval.

Technical breakdown

Why local MCP servers widen the credential attack surface

Local MCP servers run as processes on developer endpoints, so they inherit whatever the user can reach on disk and in environment variables. That means AWS keys, GitHub tokens, database passwords, and OAuth tokens can be read directly at startup or during runtime. In practice, the trust boundary shifts from a controlled service to an endpoint process that can access plaintext secrets and arbitrary code from package registries. When the server is installed with no approval gate, the risk is not only compromise but uncontrolled credential use across the workstation.

Practical implication: restrict local MCP execution to tightly governed endpoint populations and remove plaintext credential access from developer workspaces.

Why package trust is missing in the MCP distribution model

Most MCP servers are distributed through npm, GitHub, or similar registries without meaningful code signing or author verification. That creates a supply chain problem where package names can be copied, authors can be anonymous, and download popularity can be manipulated. Security teams then cannot reliably distinguish official implementations from community packages with similar names. The result is an identity governance gap around provenance: the server may be technically functional while still being unauthorised, unreviewed, or unverifiable from a security standpoint.

Practical implication: introduce a formal allowlist for approved MCP packages and require provenance checks before any deployment reaches endpoints or CI.

What the detection gap looks like in practice

Traditional endpoint and network tools often see MCP activity as normal developer behaviour. A local process launched by an approved desktop app reads files and opens encrypted sessions, so the telemetry does not always look malicious. That means security teams can miss the key questions: what servers exist, what credentials they use, and what services they contact. In governance terms, the control failure is not just missing alerts, but missing inventory and usage context for the identities that make the protocol work.

Practical implication: build MCP-specific discovery and credential-use monitoring into your NHI visibility stack, not just into endpoint detection.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP servers are becoming an ungoverned non-human identity layer. The article shows that MCP adoption is no longer a niche experiment but a distributed runtime pattern tied directly to credentials and service access. When 38% of deployments are unofficial and most run locally, the issue is identity sprawl with no reliable registration boundary. Practitioners should treat every MCP server as an identity object that must be discoverable, attributed, and governed.

Package trust is the missing control plane for MCP distribution. This ecosystem relies on registries that do not reliably prove who published a package or whether the code matches the claimed purpose. That means security teams cannot assume that a familiar package name equals a trusted implementation. The implication is a governance model built on provenance, not popularity, because download counts do not establish entitlement to enterprise access.

Local execution breaks the assumption that server-side controls can contain credential use. The article makes clear that 86% of deployments run on endpoints where arbitrary code can read local secrets and act with user privileges. That is a structural limitation of endpoint-held credentials, not merely a hygiene issue. Practitioners should recognise that endpoint-local MCP is already operating outside the assumptions of centralised review and sandboxing.

Identity blast radius is now determined by developer workspace access, not only by production systems. MCP servers can reach 115 enterprise services from environments security teams often do not monitor as identity-critical. That widens the blast radius from the workload to the workstation, where secrets are stored informally and visibility is weaker. The practical conclusion is that identity governance has to follow the credential wherever it is used, including the development endpoint.

Baseline security posture in the MCP ecosystem is weak enough to justify category-level controls. The article’s finding that 3% of published MCP servers contain hardcoded credentials is a named concept in itself: hardcoded credential persistence. That failure mode shows that some of the ecosystem is already shipping secrets as part of the package, which makes ad hoc review insufficient. Security teams should treat MCP as a category that needs policy before adoption expands further.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a broader control model, Top 10 NHI Issues frames the identity failures that appear when machine access grows faster than governance.

What this signals

Hardcoded credential persistence: MCP ecosystems are already showing the same failure pattern that has long driven NHI breaches: secrets embedded where runtime code can read them. The operational signal for practitioners is that development convenience is now a production-risk issue, because identity exposure is travelling through the workstation before it ever reaches the workload.

With 38% of deployments coming from unofficial implementations and 86% favouring local execution, the governance problem will not be solved by endpoint security alone. Security teams should expect the next phase of MCP management to look more like NHI lifecycle control, package provenance enforcement, and scoped credential distribution than traditional software allowlisting.

A useful comparison point is the NHI Lifecycle Management Guide, because MCP servers require the same disciplines around provisioning, rotation, and offboarding that service accounts do. Teams that already use NIST Cybersecurity Framework 2.0 can map this into identify, protect, and detect functions without treating MCP as a separate exception.

For practitioners

• Inventory every MCP server deployment Map where MCP servers are installed, which endpoints host them, which package sources they came from, and which enterprise services they touch. Without an authoritative inventory, you cannot separate official implementations from unofficial packages or understand the credential footprint on each device.
• Remove plaintext secrets from MCP-adjacent workflows Replace .env files, JSON configs, and loose environment variables with governed secret storage and scoped service accounts. The goal is to stop MCP processes from inheriting credentials that were never meant to live on a developer endpoint.
• Create a package allowlist for approved MCP servers Require provenance review before installation from npm, GitHub, or any other registry. Allow only named packages with validated ownership, change history, and a documented business need.
• Monitor endpoint processes for credential access patterns Detect when local MCP servers read secret-bearing files, enumerate environment variables, or initiate unusual service connections. Endpoint telemetry should answer which credentials were accessed, not just whether the process existed.

Key takeaways

• MCP server sprawl is now an identity governance issue because each deployment can carry secrets, service access, and unmanaged privilege into the developer endpoint.
• The data points to a dual problem of exposure and provenance, with unofficial packages and local execution combining to outpace standard visibility controls.
• The practical response is to inventory, approve, and constrain MCP servers as NHI objects, not to treat them as ordinary developer utilities.

Key terms

• MCP Server: An MCP server is a runtime component that exposes tools, data, or actions to an AI assistant through Model Context Protocol. In security terms, it is a non-human identity consumer and often an identity-bearing workload that can inherit credentials from the environment where it runs.
• Non-Human Identity: A non-human identity is any machine, workload, token, service account, certificate, or agent that authenticates and acts in a system. The governance problem is not just authentication, but ownership, scope, lifecycle, and whether the credential can be traced to a legitimate business purpose.
• Local Execution: Local execution means the software runs on an endpoint or workstation rather than in a controlled remote service. For identity security, that matters because the process can directly reach files, environment variables, and user-scoped credentials, often outside the controls used for hosted workloads.
• Package Provenance: Package provenance is the ability to prove who published software, how it changed, and whether it is the expected artifact. In MCP ecosystems, weak provenance turns a package name into an unreliable signal, so approval must be based on verifiable source and ownership.

Deepen your knowledge

MCP server governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring local AI tooling, package provenance, and secret handling under one governance model, it is worth exploring.

This post draws on content published by Clutch Security: MCP Servers: What We Found When We Actually Looked. Read the original.