Supply chain risk in MCP servers: why trust breaks at install time

At a glance

What this is: This is an analysis of MCP server supply chain risk, showing that a trusted-looking tool can read and exfiltrate sensitive local data as soon as it executes.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern developer-facing toolchains as identity-bearing execution paths, not just repositories and secrets stores.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Bishop Fox's analysis of MCP server supply chain risk and local credential exposure

Context

MCP server supply chain risk is what happens when the tool you installed is not the tool you think you reviewed. In practice, the package name, schema, and runtime behaviour can stay familiar while the implementation quietly changes, turning a normal developer workflow into an identity and secrets exposure path.

That problem matters to NHI governance because MCP servers run with the user's context and inherit whatever files, tokens, and credentials are already present on the machine. Once that boundary is blurred, classic code review and packaging checks no longer tell you whether a tool is safe to execute locally.

The article's central point is simple: trust at install time is not the same as trust at execution time. That is a typical failure mode in distributed tool ecosystems, and it becomes sharper when the tool itself can reach beyond its declared purpose.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

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

A: Because the threat is not only code on disk, but code that executes inside a real user context and can read live credentials immediately. A malicious MCP server can preserve expected functionality while harvesting SSH keys, cloud tokens, and configuration files in the background.

Q: What breaks when organisations trust MCP package review alone?

A: Review alone breaks when the reviewed package is later updated, repackaged, or modified in a way that keeps its interface intact but changes its behaviour. The result is a false sense of safety because the control evaluated the name and schema, not the running artefact.

Q: Who is accountable when a hostile MCP server steals developer secrets?

A: Accountability usually sits with the organisation that allowed the tool to run without sufficient provenance, isolation, and egress controls. In regulated environments, teams should also map the incident to secrets management, privileged access, and software supply chain control obligations.

Technical breakdown

How a malicious MCP server preserves functionality while exfiltrating data

An MCP server can remain functionally correct while performing secondary actions in the background. Because the protocol standardises discovery and tool invocation, not code provenance, a malicious update can keep the same name, schema, and expected responses while adding hidden behaviours such as BCC injection, credential forwarding, or quiet file access. Functional tests may still pass because the visible output looks normal. The security problem is therefore not obvious malware behaviour, but dual-use execution inside a trusted interface.

Practical implication: validate tool provenance and inspect runtime behaviour, not just outputs or package names.

Why version pinning and checksums matter for MCP supply chains

Version pinning reduces exposure to silent behavioural changes by keeping a known-good release in place until a new version has been reviewed. Checksums, lockfiles, vendored dependencies, and signed commits add a verification layer that tells you whether the installed artefact matches what was approved. Without those controls, the default update path becomes an unreviewed trust decision. In MCP environments, that matters because a small change in a tool can alter what data it can observe or transmit without changing the way it appears to users.

Practical implication: require pinned versions and integrity verification before any MCP server update reaches developers.

Why egress controls are the last line of defence for hostile MCP servers

If a hostile MCP server can reach the network freely, exfiltration can look like ordinary tool traffic. Egress filtering, dedicated execution environments, and runtime monitoring narrow the room for silent data transfer by restricting where the process may connect and what it may send. This is especially important when the server runs under a user account that already has access to SSH keys, cloud credentials, database passwords, or API tokens. The main lesson is that local execution without network restraint turns hidden data access into hidden data loss.

Practical implication: restrict MCP processes to allowlisted destinations and monitor for unexpected outbound connections during tool use.

Threat narrative

Attacker objective: The attacker wants to turn trusted local tool execution into credential theft and downstream account compromise without raising immediate suspicion.

1. Entry occurs when a user installs or runs a malicious MCP server package that looks legitimate but contains hidden behaviour.
2. Escalation happens when the server inherits the user's local context and reads accessible files such as SSH keys, cloud credentials, tokens, and configuration files.
3. Impact follows when the server silently forwards or exposes those secrets, enabling account takeover, lateral movement, or direct financial theft.

Breaches seen in the wild

• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
• GitHub Action tj-actions Supply Chain Attack — Compromised tj-actions/changed-files GitHub Action leaks thousands of CI/CD secrets from 23,000 repositories.

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

NHI Mgmt Group analysis

Supply chain trust in MCP is an identity problem, not just a software integrity problem. The central failure is that organisations often treat a local MCP server as an approved tool once it passes review, when in reality it inherits the user's working identity and everything that identity can touch. That means the tool becomes an extension of NHI exposure, not a separate software event. Practitioners should stop framing MCP governance as package hygiene alone and treat it as controlled execution of a credential-bearing identity.

Version pinning changes the risk profile, but only if the review boundary is real. A pinned package reduces surprise, but it does not eliminate the possibility that the approved artefact is itself hostile or later repurposed through dependency drift. The more useful governance question is whether the internal approval process can prove that the running binary matches the reviewed binary. That shifts MCP governance from trust-based adoption to identity and artefact verification.

Hostile MCP servers create credential blast radius that traditional developer controls rarely measure. Once a server can read SSH keys, cloud credentials, CI/CD tokens, and wallet files from a local machine, the exposure is no longer confined to the package registry. The practical implication is that the organisation has to define which local identities may execute which tools, in which environments, with which network paths, and with what monitoring.

Registry controls matter because community distribution is not governance. A marketplace or package index may distribute tools efficiently, but distribution is not the same as lifecycle control. Internal registries, signed artefacts, and enforced re-review turn ad hoc adoption into a managed NHI process. The implication is that tool onboarding must be governed like privileged access, not like optional developer convenience.

Data exfiltration via MCP is easiest to miss when defenders assume the tool is honest infrastructure. That assumption collapses once the server itself can be the attacker, because the line between tool execution and breach becomes operationally thin. For practitioners, the lesson is to build controls around provenance, privilege scope, and egress restriction before they rely on any local agentic workflow.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For broader NHI governance context, see The 52 NHI breaches Report for recurring patterns in trust, privilege, and exposure.

What this signals

MCP server governance is converging with NHI lifecycle control. The next control question is not whether the tool works, but whether its provenance, privilege scope, and runtime path are all auditable before it touches developer data. Teams that already manage service accounts and secrets should extend the same discipline to local tool execution, because trust breaks at the boundary where code becomes a credential-bearing actor.

The practical signal for programmes is that registry review and endpoint hardening now have to operate together. If a developer can install, update, and execute a server without central visibility, the organisation has created an unmanaged identity path that bypasses normal access governance and makes exfiltration hard to distinguish from legitimate tool traffic.

Identity blast radius: when a tool inherits a user's full local context, the exposed scope is whatever that person can read, use, or forward. That makes egress allowlisting, signed artefacts, and dedicated execution environments part of identity risk management, not just platform hardening.

For practitioners

• Treat community MCP servers as untrusted until approved Require internal review, signed artefacts, and explicit approval before developers can run third-party MCP servers on managed endpoints.
• Pin every approved MCP server version Use lockfiles, checksums, and dependency verification so updates cannot land without a fresh security review and documented change control.
• Restrict MCP execution to dedicated environments Run approved tools in isolated workspaces or containers with no direct access to a developer's full local profile.
• Enforce allowlist-only egress for MCP processes Block unapproved outbound HTTP connections and alert on unexpected destinations during tool execution, especially from processes that can read secrets.
• Assume local secrets are exposed after a hostile run If a malicious or compromised MCP server executes, begin revocation for SSH keys, cloud credentials, API tokens, and other secrets visible to that user.

Key takeaways

• MCP supply chain risk is really a trust and identity control problem, because a malicious server can execute inside a real user context and read live secrets immediately.
• The strongest evidence in this category is not abstract speculation, but real examples showing normal tool behaviour alongside hidden credential harvesting and exfiltration.
• Practitioners need provenance checks, pinned artefacts, isolated execution, and network egress restriction before local MCP tooling can be considered survivable.

Key terms

• MCP Server Supply Chain Risk: The risk that a model context protocol server, package, or marketplace skill is modified, repackaged, or updated in a way that preserves normal function while changing what it can read or exfiltrate. In identity terms, the danger is that trusted execution inherits user context and becomes a covert data access path.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
• Model artefact provenance: Model artefact provenance is the chain of trust showing where a model file, tokenizer, metadata bundle, or derived package came from and whether it was modified. For autonomous and agentic deployments, provenance must cover the whole package, not just the neural weights.

What's in the full article

Bishop Fox's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact selfpwn workflow used to quantify what a hostile MCP server can read from a developer machine.
• Step-by-step mitigation guidance for internal registries, version pinning, checksum verification, and dependency control.
• Runtime and egress monitoring approaches for spotting suspicious outbound connections during MCP tool execution.
• Case-specific discussion of the postmark-mcp and ClawHub compromises as supply chain patterns, not just examples.

👉 The full Bishop Fox post covers the selfpwn demonstration, compromise examples, and mitigation controls in more depth.

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.