Why do MCP servers create a bigger secrets risk than ordinary package installs?

Why This Matters for Security Teams

MCP servers are not risky simply because they add another dependency. They are risky because they are often granted the same runtime context as the user, which means a compromised server can reach live secrets instead of inert build artifacts. That changes the blast radius from package integrity to immediate credential exposure, especially when secrets are stored in shell history, environment variables, config files, or local credential stores.

This is why the issue maps more closely to OWASP Non-Human Identity Top 10 and Guide to the Secret Sprawl Challenge than to ordinary package risk alone. In the first year of widespread adoption, NHIMG reported that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, a sign that the protocol surface itself has become a credential concentration point. A malicious package may sit on disk; a malicious MCP server can act inside trust boundaries already holding production access.

In practice, many security teams encounter the breach only after the assistant has already read keys, tokens, or cloud profiles rather than through intentional review of the server install.

How It Works in Practice

An ordinary package install usually raises concern around code provenance, dependency confusion, or supply chain tampering. MCP servers are different because they are expected to be interactive, persistent, and tool-enabled. Once launched, they can operate with the same filesystem visibility and environment access as the invoking user, so a server does not need to “escape” to steal secrets. It can simply request them, read them, or log them while continuing to appear functional.

That is why current guidance suggests treating MCP servers as active execution surfaces, not passive libraries. Security teams should separate installation trust from runtime trust, then bind access to the minimum set of tools and secrets needed for the specific task. The strongest pattern is short-lived, per-task authorization using ephemeral credentials, with revocation when the session ends. Where available, workload identity should be used to identify the server instance itself, while policy engines evaluate each request in context rather than relying on a one-time allowlist.

• Use isolated execution contexts for each MCP server, especially when local credentials are mounted or inherited.
• Prefer JIT secrets and short TTLs over static API keys in configuration files.
• Limit tool permissions to the smallest viable scope and log every secret-read path.
• Apply runtime policy checks for file access, outbound network calls, and credential retrieval.

NHIMG’s The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which is exactly the pattern that turns a convenience integration into a secrets incident. That risk is amplified in agentic environments discussed in the OWASP Agentic Applications Top 10 and the OWASP Top 10 for Agentic Applications 2026, where tool access and execution authority can expand quickly. These controls tend to break down when MCP servers are run on developer desktops with broad inherited shells and shared cloud profiles because the server can read whatever the user can read.

Common Variations and Edge Cases

Tighter MCP control often increases setup overhead, requiring organisations to balance developer speed against runtime containment. That tradeoff is real, especially when teams want local experimentation without breaking workflows. Best practice is evolving, but there is no universal standard yet for how aggressively to sandbox every MCP deployment.

One common edge case is a “trusted” internal server that still exfiltrates secrets indirectly. For example, a server may not open credential files explicitly, but it can chain tool calls, query local metadata services, or capture tokens from process memory and logs. Another edge case is shared workstation use, where a single compromised MCP server can access multiple accounts, cloud contexts, or synced browser sessions. The risk is not just malicious code on disk; it is code executing with a live human session attached.

Security teams should also be careful not to overfit package scanning alone. Signature checks and dependency reviews help, but they do not solve runtime credential reach. A stronger control set combines secret inventory, local filesystem restrictions, egress controls, and revocation-ready secrets management. The NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce the same operational lesson: secrets should be assumed exposed the moment a runtime can read them, not only after a defect is discovered.

Related resources from NHI Mgmt Group

• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do MCP-based agents create a bigger risk than ordinary documentation tools?
• Why do MCP servers create more NHI risk than ordinary service integrations?
• Why do MCP servers create more NHI risk than ordinary API integrations?