Topic starter
20/08/2026 5:35 pm
TL;DR: Supply chain risk can quickly turn into local code execution and data access when the September npm compromises reached MCP servers through transitive dependencies and npx execution, according to Stacklok. The core issue is not just package hygiene but whether MCP runtimes are isolated enough to contain compromise.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Examining the impact of npm supply chain attacks on MCP”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP supply chain attacks show why runtime isolation matters