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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Bishop Fox's blog post: MCP server supply chain risk begins at install time, not when an attacker later abuses a running tool.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now have to govern trust in code provenance, update paths, and runtime egress before an MCP server ever reaches a developer machine.

Context

MCP server supply chain risk is the failure of install-time trust, where a tool that looks legitimate can still behave maliciously once it runs with the developer's privileges. In practice, the governance gap is not discovery of bad behaviour after execution but assurance that the package being installed is the same code that was reviewed.

For identity security teams, this is an NHI problem because the server runs as a non-human identity bound to the user's local context and can inherit access to secrets, credentials, and other high-value files. The question is how to govern trust, provenance, and update control for machine-executed tooling that can act on behalf of the operator without further approval.

The article uses otto-support's selfpwn demonstration, plus the postmark-mcp and ClawHub cases, to show that malicious functionality can hide inside otherwise working integrations. That is not an edge case; it is the structural weakness of community-distributed tool ecosystems when install-time verification is missing.

Key questions

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: Why do malicious MCP servers create such a large security gap?

A: They create a large gap because the model often trusts the server path once it is connected, even if the server has not been deeply vetted. That makes the integration layer a hidden access channel for tool misuse, output manipulation, and exfiltration. The problem is delegated trust without equivalent identity and lifecycle controls.

Q: How do security teams know if an MCP deployment is outside its intended boundary?

A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch. Strong warning signs include localhost servers accessible from the browser, public endpoints with no auth, and tool catalogs that exceed the intended use case.

Q: Who should be accountable for governing MCP client registration controls across authentication and authorization workflows?

A: Security, identity, and platform teams should share accountability, but the authorization server owner usually carries operational responsibility. Governance should cover which registration methods are allowed, which domains are approved, how metadata is validated, and how exceptions are reviewed. Without clear ownership, MCP onboarding becomes a blind spot rather than a controlled access boundary.

Technical breakdown

Why MCP package trust fails at install time

MCP defines how tools are discovered and called, but not whether the implementation reviewed yesterday is still the implementation running today. That means name, schema, and normal behaviour can stay intact while the server silently adds exfiltration paths in the background. Functional testing is therefore a poor trust test because the malicious code can preserve expected output while changing what happens off the user-visible path. The review problem is compounded by default update behaviour in package managers, where accepting a new version can quietly replace a clean package with one that now behaves differently.

Practical implication: Treat code review alone as insufficient and require provenance checks before any MCP server is allowed onto developer endpoints.

How a hostile MCP server turns local access into exfiltration

When an MCP server runs via stdio in the user's context, it can read whatever the user can read, including SSH keys, cloud credentials, tokens, shell history, and wallet data. The critical point is that no privilege escalation is required if the server is already executing under the right identity. The attacker does not need to break the host if the package itself is the compromise point. This is why the article's selfpwn output matters: it quantifies the credential surface available to any installed server and shows how quickly that surface maps to lateral movement and direct theft.

Practical implication: Inventory which secrets are readable by MCP-run processes and reduce the local file surface available to those identities.

Why egress controls matter when code review misses the malicious path

A malicious MCP server can look normal on inbound use while making unapproved outbound requests in the background. That shifts detection from application behaviour to network behaviour, where the signal is whether the server talks to destinations that do not belong in its approved function. Allowlist-only egress, dedicated execution environments, and runtime monitoring are not add-ons here; they are the only practical way to catch data leaving a tool that otherwise appears to work correctly. Without them, exfiltration can blend into ordinary tool traffic and remain invisible until the damage is done.

Practical implication: Constrain MCP server network access so unexpected outbound connections become detectable rather than silently successful.

Threat narrative

Attacker objective: The attacker wants to turn a trusted tool installation into silent access to credentials, internal systems, and financial assets.

1. Entry occurs when a user installs or updates an MCP server package that has been modified to preserve normal functionality while embedding hidden exfiltration behaviour.
2. Credential access follows immediately because the server runs in the user's context and can read SSH keys, cloud credentials, API tokens, wallet files, and similar local secrets.
3. Lateral movement and impact emerge when those credentials are used for infrastructure access, service impersonation, or direct financial theft after the secrets leave the host.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
• ClawHub malicious skills 2026: Hundreds of malicious ClawHub skills for the OpenClaw agent pushed credential stealers in early 2026; Koi found 341 of 2,857 in the ClawHavoc campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time trust is the real control boundary for MCP servers: The article shows that a package can pass review, testing, and even normal user workflows while still changing behaviour in ways that matter to security. That means the governing assumption that installation is a reliable trust event no longer holds for community-distributed tool ecosystems. Practitioners should treat provenance as a security control, not a procurement detail.

Credential exposure is a property of execution context, not just of compromise: Once an MCP server runs under the user's identity, it inherits the user's readable secrets and becomes a machine-executed access path to assets that IAM teams often assume are protected by repository or endpoint boundaries. That is why local execution boundaries, not just secret vaulting, shape the effective blast radius. The practitioner conclusion is to govern what the process can read, not merely what the package claims to do.

Supply chain trust debt accumulates when update paths outrun review: The postmark-mcp example demonstrates that a previously clean package can become malicious through a small version change, while default update behaviour silently expands exposure. That creates a trust debt where each accepted update is another opportunity for unreviewed behaviour to enter production use. Practitioners should assume the update channel is part of the attack surface.

Shadow MCP servers are an identity problem as much as a software problem: If teams allow ad hoc installation from public registries, they lose inventory of which machine identities exist, who owns them, and what egress they are allowed to use. That makes lifecycle governance impossible because there is no durable boundary around approved tooling. The implication is that internal registries and explicit approval workflows are necessary to preserve identity accountability.

Runtime controls matter because malicious MCP traffic often looks legitimate: The article's own conclusion is that the difference between routine tool use and active exfiltration may be impossible to see without intentional logging. That means detection strategy cannot depend on payload inspection alone. Practitioners need to consider egress policy, execution isolation, and approved boundary enforcement as the operational minimum.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Install-time governance is now the decisive control plane for MCP adoption: The article's core lesson is that package trust cannot be inferred from functionality, because a server can remain operational while silently changing what it does with the user's data. That means identity programmes need approval, provenance, and revocation workflows before adoption, not only logging after deployment.

Identity blast radius is the right concept for local toolchains: Once an MCP server inherits the user's context, the question becomes how far that process can reach into secrets, APIs, and downstream systems. Teams should map the read surface of each approved server and treat every new integration as a new blast-radius decision, not a convenience feature.

Version pinning is a governance control, not a deployment preference: The postmark-mcp example shows that a small update can flip a trusted package into an exfiltration path without changing user-visible behaviour. In a local tool ecosystem, update approval must be explicit, version-controlled, and reversible because the package manager's default behaviour is not a security boundary.

For practitioners

• Implement an internal MCP registry Allow only reviewed MCP servers from an approved registry, and require verified commits or signed packages before onboarding any tool into developer workflows.
• Pin and re-review every MCP update Lock package versions internally, verify checksums or lockfiles, and force a fresh review before any update can replace a previously accepted server.
• Restrict MCP execution environments Run approved servers in dedicated environments rather than on general developer endpoints so a compromised package cannot inherit broad local access by default.
• Enforce allowlist-only egress Apply outbound network allowlists to MCP server processes and alert on unfamiliar destinations during tool execution.
• Reduce local secret exposure Remove unnecessary SSH keys, cloud credentials, tokens, and wallet files from the files readable by processes that host MCP servers.

Key takeaways

• Hostile MCP servers can inherit a user's local access and turn everyday tooling into a credential and data exposure path.
• The article ties that risk to real cases, including postmark-mcp and ClawHub, showing that normal functionality does not prove benign intent.
• Provenance checks, internal registries, version pinning, and egress restrictions are the controls that change the outcome before compromise becomes visible.

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.
• Install-Time Trust Inversion: Install-time trust inversion is the security failure that happens when an environment executes unreviewed dependency code before validating whether it is safe. The trust decision happens too early, allowing a compromised package to act with higher privilege than the reviewer intended.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Control Provenance: The traceable origin of the evidence used to prove a control is operating. In practice, provenance matters when auditors need to know whether reports were generated independently, whether data was altered, and whether the proof can be reproduced later.

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.