MCP server sprawl is exposing enterprise credentials at scale

At a glance

What this is: This analysis shows that rapid MCP server adoption is creating an NHI governance problem, with unofficial packages, local execution, and plaintext secrets combining into a broad enterprise credential exposure surface.

Why it matters: IAM, NHI, and platform teams need to treat MCP servers as governed workloads, because install paths, secret handling, and execution context now determine who can reach enterprise credentials.

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.

Context

MCP server sprawl is an identity governance problem because each server can read and reuse enterprise secrets, not just process prompts. When local servers run as arbitrary code on developer endpoints, the trust boundary shifts from controlled service infrastructure to workstation execution, where ordinary IAM and endpoint assumptions no longer hold.

The article argues that this is now a mainstream deployment pattern, not an edge case. Most adoption is local, unofficial packages are common, and traditional security tools have little MCP-specific visibility, which leaves organisations unable to inventory where credentials are stored, how they are accessed, or which packages are responsible.

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. The server can inherit endpoint privileges, read plaintext secrets from files or environment variables, and use them immediately without crossing a managed trust boundary. That makes the endpoint itself part of the identity control plane, which most teams are not governing today.

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. Security teams cannot assume popularity equals trust. If a package can be installed without meaningful review and then read local secrets, the supply path itself becomes a credential-access path.

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. Traditional EDR alone is not enough if it only sees a normal interpreter. Detection has to connect package provenance to secret consumption and outbound use.

Q: When should organisations treat MCP adoption as an NHI governance issue rather than a developer tooling issue?

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.

Technical breakdown

Why local MCP execution changes the trust boundary

MCP servers can run remotely in vendor-controlled infrastructure or locally as arbitrary processes on a developer endpoint. Remote mode preserves a clearer trust boundary because credentials can stay inside the server environment. Local mode collapses that boundary: the package manager installs unverified code, the process inherits endpoint privileges, and the server can read files, environment variables, and configuration stores where secrets already live. That makes credential exposure a runtime consequence of deployment choice, not just of poor secrets hygiene. Practical implication: treat local MCP execution as a governed runtime surface, not a developer convenience layer.

Practical implication: Classify local MCP execution as a governed runtime and restrict where unverified packages can run.

How MCP servers access enterprise credentials

The article describes a direct secret consumption model. Developers place AWS keys, GitHub tokens, database passwords, and OAuth tokens in plaintext .env files, JSON configs, and environment variables, and the MCP server reads them at startup. That means the server does not need to break authentication to obtain access. It inherits access from the local environment and then uses those credentials to reach downstream systems. In NHI terms, the server becomes the execution context for non-human identities already sitting on the endpoint. Practical implication: inventory where secrets are stored and map every MCP server to the credential sources it can read.

Practical implication: Map each MCP server to the credential stores it can read and remove plaintext secret exposure paths.

Why package trust and detection both fail

The ecosystem's distribution model creates two related gaps. Package registries do not meaningfully verify authorship or code integrity, so unofficial packages can look legitimate enough to attract installation. At the same time, endpoint and network tools often see only a normal interpreter process and encrypted outbound traffic. That leaves security teams blind to provenance and runtime behaviour at the same time. The result is not just shadow IT but shadow credential access, where the organisation cannot prove what code touched which NHI secrets. Practical implication: add package provenance checks and MCP-aware telemetry before allowing broad endpoint installation.

Practical implication: Add package provenance controls and MCP-aware telemetry before allowing broad endpoint installation.

Threat narrative

Attacker objective: The objective is to obtain reusable enterprise credentials and use them to reach connected systems through an apparently legitimate MCP runtime.

1. Entry occurs when a developer installs an MCP package from npm, GitHub, or another registry, sometimes with auto-accept flags that suppress prompts.
2. Credential access follows immediately because the locally running server reads plaintext secrets from files, environment variables, or JSON configs on the endpoint.
3. Escalation happens when the server uses inherited tokens and keys to reach cloud, code, collaboration, or data platforms with broader enterprise privileges.
4. Impact is enterprise credential exposure at scale, because unvetted local code can operate across multiple services without meaningful review or isolation.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

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

NHI Mgmt Group analysis

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.

Unofficial MCP packages create a provenance gap, not just a software supply chain gap: the issue is not only whether code is malicious, but whether the organisation can prove who published it and what credentials it can reach. Package names, download counts, and repository popularity do not establish trust. Practitioners need to stop equating developer convenience with implied authorisation.

Credential storage becomes the attack surface when MCP servers run locally: the article shows that AWS keys, GitHub tokens, database passwords, and OAuth tokens are being consumed from plaintext files and environment variables. That pattern collapses the distinction between secrets management and application runtime. The practical conclusion is that NHI governance must move from static inventory to access-by-execution context.

Detection failure is structural because current tooling observes the wrong layer: endpoint security sees a legitimate interpreter, firewall tools see normal encrypted egress, and CASB tools often miss development workflows altogether. The result is a governance blind spot where the organisation cannot answer basic questions about which servers exist, which credentials they touch, or which packages created them. That is a visibility failure, not just a logging issue.

MCP adoption is becoming an identity blast-radius problem: once a local server can read multiple credential types, the compromise domain is no longer a single tool or team. It extends across cloud, code, collaboration, and data systems tied together by shared NHI secrets. Practitioners should therefore govern MCP as part of the broader non-human identity perimeter, not as a separate developer productivity topic.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Credential access now follows package installation, not just user authorisation: when local MCP servers run with endpoint privileges, the practical control point shifts to where the package came from and what secrets it can reach. Teams that still govern MCP as developer tooling will miss the identity boundary where the risk actually starts.

Shadow MCP is becoming shadow NHI: the same package sprawl that expands developer convenience also expands the number of machine identities, tokens, and service accounts exposed on endpoints. Organisations need a single view of package provenance, runtime location, and secret usage if they want to keep the blast radius bounded.

For practitioners

• 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.

Key takeaways

• MCP server adoption is turning developer endpoints into identity-rich execution environments where local code can reach enterprise secrets directly.
• The biggest risk is not just unknown packages but unknown package provenance combined with plaintext credential access and weak runtime visibility.
• Security teams need to govern MCP through inventory, provenance, and secret-use monitoring, or the control surface will keep expanding faster than review cycles.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Local MCP: Local MCP is a Model Context Protocol deployment that runs on a device or within a local environment instead of a remote service. It lets an AI agent connect to tools, files, or data sources through a standardized interface, while keeping control, trust boundaries, and data handling closer to the host system.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.