MCP supply chain attacks show why runtime isolation matters

At a glance

What this is: Stacklok examines how npm supply chain attacks can reach MCP servers through indirect dependencies and npx execution, with runtime isolation emerging as the key containment control.

Why it matters: IAM and platform teams need to treat MCP servers as executable workloads with inherited access, not just packages, because compromise at the dependency layer can become host-level exposure.

Context

npm supply chain compromise becomes materially more dangerous when the affected code is not just imported but executed locally. In MCP environments, server runtimes can inherit the user’s machine, network, and data access, which turns dependency compromise into an execution and containment problem rather than a simple patching exercise. That is especially relevant where MCP servers are distributed as indirect dependencies and launched through npx.

The security gap is not unique to MCP, but MCP makes it sharper because the protocol sits close to tools, data sources, and local context. When runtime boundaries are weak, a malicious package can move from repository compromise into live execution with surprisingly broad reach. That pattern is common wherever software supply chain control and runtime isolation are treated as separate problems.

Key questions

Q: What fails when MCP servers are run directly from npm packages?

A: They inherit the same trust boundary as the local user, so a compromised dependency can execute with access to the host, connected networks, and any data already available to that session. The failure is not only code integrity, but the lack of runtime separation between untrusted package content and trusted local privileges.

Q: Why does runtime isolation matter more than package hygiene for MCP?

A: Package hygiene reduces the chance of compromise, but runtime isolation limits what a compromised server can actually reach. If the server is executed locally without containment, a malicious package can still interact with host resources even after dependency review has passed.

Q: What are the warning signs that an MCP deployment is overexposing enterprise tools?

A: Warning signs include overly broad tool discovery, agents reaching adjacent data without a fresh policy check, and responses being reused after user permissions change. Those symptoms show the protocol is enabling reach faster than the governance model can constrain it.

Q: Should teams prioritise container isolation or dependency scanning for MCP?

A: Both matter, but container isolation is the more immediate containment control when the server executes locally. Scanning helps detect bad packages earlier, while isolation limits the blast radius if a malicious version still reaches runtime.

Technical breakdown

How npm compromise reaches MCP execution paths

npm supply chain attacks matter to MCP because many servers are built from the same JavaScript and TypeScript dependency graph, including indirect dependencies pulled in through an SDK. When a maintainer account is compromised, attackers can publish malicious package versions that look normal to package managers and CI pipelines. If the server is then launched with npx, the package is fetched and executed on the local host, which means the runtime inherits whatever access the user already has. That changes the risk from library contamination to active code execution in a trusted environment.

Practical implication: Treat MCP servers as executable workloads, not static dependencies, and review how they are started before they are trusted.

Why containerisation changes the blast radius

Containerisation separates the MCP server process from the host so that a compromised package cannot freely interact with the user’s filesystem, network stack, and local secrets. Without that boundary, the server runs with ambient authority, which is exactly what supply chain attackers want. Container isolation does not prevent malicious code from running, but it limits how far that code can move once it is executing. In practice, this is the difference between a bad package and a broadly exposed workstation or developer environment.

Practical implication: Run MCP servers inside containers by default so compromise is contained to the smallest feasible runtime boundary.

Why network isolation matters alongside runtime isolation

Runtime isolation reduces what a compromised MCP server can reach locally, but network isolation narrows what it can exfiltrate or contact externally. If outbound access is unrestricted, malicious code can still attempt credential theft, telemetry leakage, or command-and-control communication. Combining container boundaries with outbound allow-listing creates a layered control model that is much harder for an attacker to bypass. For MCP, this matters because the server often sits close to high-value APIs, user context, and operational data flows.

Practical implication: Apply outbound network restrictions to MCP servers so local compromise does not become uncontrolled data exfiltration.

Threat narrative

Attacker objective: Exploit trusted dependency execution to reach local data, credentials, and network access through an MCP server runtime.

1. Entry occurs when compromised npm packages are pulled into the MCP dependency chain and executed through npx on a local system.
2. Credential and data access follow because the MCP server inherits the user’s machine, network, and data permissions unless it is isolated.
3. Impact is achieved when malicious code can act from inside a trusted runtime boundary, increasing the chance of secret theft or broader environment exposure.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

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

Runtime isolation is the real control boundary for MCP supply chain risk. Package hygiene reduces exposure, but it does not stop an attacker from executing code inside a trusted local context once a malicious dependency lands. In MCP environments, the security question is no longer just whether a package is safe, but whether the server is prevented from inheriting the full host trust boundary. Practitioners should treat runtime containment as the control that converts a compromise into a contained event.

MCP runtime inheritance gap: when local execution silently imports host trust, the blast radius becomes the control problem. That is the governance failure this article exposes. npx execution, transitive dependencies, and default local permissions create a hidden trust chain that is easy to overlook during procurement or code review. The practical lesson is that identity and access assumptions must be evaluated at execution time, not only at dependency review time.

Containerisation plus outbound control is the minimum viable containment pattern for MCP servers. A container alone limits host exposure, but it does not address exfiltration paths or malicious callbacks. Adding network isolation turns a compromised server into a far more constrained workload, which is particularly important when MCP servers can reach developer data or connected tools. Teams should judge MCP deployment patterns by how tightly they bound execution, not by whether the code is open source or widely used.

Supply chain resilience for MCP now depends on runtime governance, not just build hygiene. The broader market signal is that AI-adjacent tooling is collapsing classic software supply chain risk into identity and access risk at runtime. That makes control design more operational and less theoretical: if a server can execute, it needs a bounded identity, bounded network reach, and a clearly defined revocation path. Practitioners should expect security reviews of MCP to move from repository posture toward runtime policy enforcement.

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: OWASP Agentic Applications Top 10

What this signals

MCP runtime inheritance gap: the article shows that local execution can silently convert a dependency issue into host-level exposure. That shifts governance from package review alone to the question of what a server can reach once it starts, which is the control boundary many teams still miss.

The practical signal for IAM and platform owners is that MCP servers need the same scrutiny as other execution environments that can inherit user context. A container boundary and tight egress policy are not add-ons here; they are the difference between a compromised package and a compromised workstation.

Supply chain attacks against developer tooling are increasingly a privilege and containment problem, not just a code provenance problem. Teams should therefore review execution paths, network reach, and secret exposure together rather than treating them as separate controls.

For practitioners

• Pin MCP package versions Replace @latest usage with explicit versions and review lock files so a compromised patch release cannot change server behaviour unexpectedly.
• Run MCP servers in containers Require containerised execution for MCP servers so a compromised dependency cannot freely inherit the host filesystem, network, and local context.
• Restrict outbound network access Apply network allow-lists or isolated egress rules so an MCP server can only reach the services it genuinely needs.
• Rebuild and republish affected servers If your server or build chain consumed the compromised npm packages, publish a clean rebuild to eliminate any malicious dependency that may have slipped in during the attack window.

Key takeaways

• MCP supply chain attacks become far more serious when servers are executed locally and inherit host-level trust, because the compromise can extend beyond code into data and network access.
• The article shows that runtime isolation changes the blast radius, with container boundaries and outbound restrictions reducing the impact of malicious dependency execution.
• For practitioners, the key decision is not whether to scan packages, but whether an MCP server is prevented from acting like the host when it runs.

Key terms

• Runtime Isolation: A containment pattern that separates risky execution from the main application so compromise has limited blast radius. For AI systems, it is the practical control that keeps a manipulated model response from inheriting full application or infrastructure privileges.
• Supply chain attack path: A supply chain attack path is any route by which a trusted external tool, dependency or partner becomes the mechanism for compromise. It matters because attackers often abuse legitimate integrations instead of exploiting the core system directly, which makes detection and containment harder.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Network Isolation: Network isolation is the practice of restricting what external connections a workload can make and observing those connections when they occur. For MCP servers, it limits unauthorized outbound access, reduces exfiltration paths, and improves containment and auditability if a server behaves unexpectedly.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security teams design controls for secrets, workload identity, and access governance across modern software environments.