MCP supply chain attacks show why runtime isolation matters

At a glance

What this is: This is an analysis of npm supply chain attacks and their impact on MCP servers, with the key finding that dependency compromise can turn routine server execution into local system exposure.

Why it matters: It matters to IAM and NHI practitioners because MCP servers often inherit the caller’s access, so a compromised dependency can become an identity and privilege problem as much as a software one.

👉 Read Stacklok's analysis of npm supply chain attacks and MCP exposure

Context

npm supply chain attacks expose a familiar governance gap: organisations often trust package provenance more than runtime containment. In MCP environments, that gap widens because the server is frequently executed locally and can inherit the user’s network and data access. The article’s primary point is that dependency compromise becomes materially worse when the runtime is treated as trusted by default.

For identity and access programmes, the intersection is straightforward. MCP servers are not only code artifacts, they are execution contexts that can operate with borrowed privilege, which makes them part of the broader NHI and machine access estate. The practical baseline here is atypical for many teams: too many deployments still assume that package integrity alone is enough to manage operational risk.

Key questions

Q: How should security teams contain MCP supply chain risk in developer environments?

A: Security teams should treat MCP servers as execution environments with privilege, not as harmless utilities. The baseline should be containerized execution, pinned dependency versions, and restricted outbound network access. That combination limits what a compromised package can reach, even if a malicious release slips into the dependency tree.

Q: Why do npm-based MCP servers increase the impact of package compromise?

A: They often resolve dependencies at runtime and inherit the permissions of the user who launched them. That means a poisoned package can move directly from download to execution, then into local files, network resources, or other trusted tooling. The issue is not only supply chain exposure, but privilege inheritance.

Q: What do security teams get wrong about MCP servers and package registries?

A: They often treat them as technical dependencies instead of governed trust boundaries. That mistake leaves a gap in ownership, approval, and monitoring. If an MCP bridge or package can execute code, access secrets, or influence build output, it needs lifecycle control just like any other high-risk access path.

Q: Who is accountable when an MCP connector exposes sensitive data or actions?

A: Accountability should sit with the team that owns the server, connector, and downstream access policy, not with the protocol itself. Organisations need clear ownership for approval, monitoring, incident response, and revocation. Without that assignment, agentic access grows faster than governance can follow it.

Technical breakdown

How npm compromise propagates into MCP server execution

npm and npx create a wide trust surface because packages are fetched, installed, and executed dynamically, often with transitive dependencies pulled in at runtime. When an attacker compromises a maintainer account or publishes a malicious patch release, downstream consumers may execute that code before it is detected. In MCP deployments, the official TypeScript SDK and its indirect dependencies can amplify exposure across many servers. The risk is not limited to direct package installation. It is the combination of dependency resolution, runtime execution, and inherited local permissions that turns a software compromise into an access event.

Practical implication: treat package execution as a privilege-bearing action and restrict where npx-based MCP servers can run.

Why containerization changes the blast radius

Containerization separates the MCP server from the host by constraining filesystem access, process visibility, and credential reach. Without that boundary, a compromised server may read local data, access network resources, or interact with developer tooling as if it were trusted code. The article’s point is not that containers eliminate software supply chain risk, but that they create a smaller failure domain when dependency compromise occurs. Network isolation strengthens that boundary by reducing outbound paths an attacker can abuse for exfiltration or command-and-control.

Practical implication: run MCP servers in containers with network controls, not directly on developer workstations or shared hosts.

Why version pinning and reproducible builds matter for MCP maintainers

Version pinning limits exposure to malicious patch releases, while lock files and reproducible builds make it easier to prove what was actually deployed. In a fast-moving supply chain incident, even a small version range can silently admit a poisoned dependency. The maintainer problem is therefore lifecycle governance, not only package selection. Regular audits, automated updates, and rapid rebuilds after a registry incident all help, but the architectural safeguard is making the build output deterministic enough to inspect and replace quickly.

Practical implication: pin direct dependencies, check lock files into version control, and rebuild published images after any dependency incident.

Threat narrative

Attacker objective: The attacker aims to execute malicious code through trusted MCP dependencies and use that access to steal data, propagate further, or widen compromise across developer environments.

1. Entry occurred when attackers published malicious npm package versions through compromised maintainer access and hijacked dependency trust.
2. Escalation followed when npx-based MCP execution pulled direct and transitive dependencies into a local runtime that inherited the user’s permissions.
3. Impact came from code execution inside trusted MCP workflows, creating a path to local data access, exfiltration, and broader ecosystem propagation.

NHI Mgmt Group analysis

Package trust is no longer the control boundary for MCP security. The article shows that dependency integrity alone does not contain risk when the runtime can inherit the caller’s access. MCP servers executed through npm or npx turn code delivery into a privilege-bearing event, which means the governance question is about where code is allowed to run and what it can touch. Practitioners should treat runtime containment as part of identity and access control, not as an afterthought.

Runtime isolation is the named control gap this attack pattern exposes. The failure mode is not simply a malicious package, but the assumption that a locally executed MCP server should see the same resources as the developer session. That assumption breaks least-privilege thinking and enlarges the blast radius of any poisoned dependency. The practitioner conclusion is clear: access scope must shrink before execution begins, not after compromise is detected.

MCP is becoming an identity-adjacent workload class that needs lifecycle governance. When an MCP server can act with borrowed access, it behaves more like a managed workload identity than a simple utility script. That places it squarely in the overlap between NHI governance, secrets exposure, and software supply chain risk. This is where frameworks such as OWASP NHI and MITRE ATT&CK become relevant, because the real issue is credentialed execution under weak runtime controls.

Containerization is now a governance pattern, not just an implementation choice. Stacklok’s analysis reinforces that secure defaults matter because most teams will not consistently harden every local execution path. Container boundaries and outbound network restrictions reduce the operational consequences of dependency compromise even when prevention fails. The practitioner takeaway is to design MCP deployment paths so the safe option is also the default option.

Dependency propagation window: the short period between malicious package publication and downstream removal is the window where exposure is decided. In fast-moving open source incidents, control quality is measured by how much of that window your deployment model can absorb. Teams that can rebuild, repin, and redeploy quickly have a materially better chance of limiting exposure.

What this signals

MCP security is starting to look like workload identity governance. Once a tool server can inherit user permissions and execute dependencies at runtime, the control problem shifts from software distribution to runtime authority. Teams that already manage NHIs, secrets, and privilege boundaries should extend those controls to agent-adjacent infrastructure before the estate grows faster than governance can track it.

Container boundaries will matter more than package reputation in the next wave of MCP adoption. The article points to a broader pattern: secure defaults are now a prerequisite for safe developer use, especially where local execution touches sensitive data. That aligns with the discipline described in the OWASP NHI Top 10, where identity and tool access are inseparable from runtime control.

Policy teams should expect MCP to be assessed alongside secrets exposure and identity lifecycle controls. The practical signal is that a package incident can become a privilege incident if the server is not isolated and its dependencies are not reproducible. The OWASP Non-Human Identity Top 10 remains relevant because the governance challenge is less about JavaScript and more about what software is allowed to do with borrowed access.

For practitioners

• Enforce containerized MCP execution Run MCP servers in containers by default and block direct host execution for package-based servers. This reduces the host access available to any compromised dependency and creates a smaller blast radius if malicious code reaches runtime. Apply this first to npx-driven deployments and developer-facing MCP services.
• Pin dependency versions and lock files Pin direct dependencies, commit lock files, and reject floating updates such as @latest in production MCP builds. This makes it easier to review the exact package set in use and prevents silent admission of malicious patch releases during a registry incident.
• Rebuild and republish after supply chain incidents If you maintain an MCP server, rebuild and publish a fresh version after any upstream registry compromise, even when you believe you were not directly affected. That shortens the malicious dependency window and gives consumers a clean artifact to trust.
• Limit outbound network reachability Apply network isolation so MCP servers can only reach the destinations they genuinely need. This reduces exfiltration paths and constrains any attempt by malicious code to contact external infrastructure from inside a trusted runtime.

Key takeaways

• MCP supply chain compromise becomes a runtime security problem when servers inherit local access by default.
• Containerization, version pinning, and network isolation meaningfully reduce blast radius when package trust is broken.
• Identity and access teams should treat MCP servers as part of the managed non-human workload estate, not as disposable scripts.

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.
• 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.
• Dependency trust chain: The connected set of third-party services, integrations, and internal systems that can pass access or data between each other. When one link is compromised, the trust relationship can expand the incident far beyond the original point of entry.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact MCP package handling steps Stacklok recommends after a malicious npm release.
• The ToolHive containerisation and network-isolation model used to reduce blast radius.
• The maintainer runbook for rebuilding, republishing, and pinning MCP server dependencies.
• The specific CLI toggle example Stacklok uses to restrict outbound access for GitHub MCP servers.

👉 Stacklok's full post covers the MCP deployment controls, maintainer actions, and containment model in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps practitioners translate identity controls into operational guardrails across modern software and AI-enabled environments.