GlassWorm shows why runtime control matters for MCP packages

At a glance

What this is: GlassWorm has evolved from an extension-based supply chain worm into a campaign targeting MCP packages, with the key finding that runtime enforcement is the only layer that still constrains damage after malicious code executes.

Why it matters: This matters because identity and access decisions for AI tooling now extend into the execution layer, where package trust, agent permissions, and network controls determine whether a compromised tool can act as an unwatched identity.

Context

GlassWorm is a software supply chain attack that moved from visible code review failures into the runtime layer where AI toolchains actually execute. The core issue is not just package trust, but whether an agent-adjacent dependency can read files, open network connections, and spawn processes once installed.

For teams building around MCP, the governance gap is that package approval still assumes humans can inspect what they are authorising. In practice, a malicious package can look legitimate in an editor and still behave maliciously after installation, which makes execution-time control a necessary second boundary.

Key questions

Q: What breaks when a malicious MCP package is already installed and running?

A: Pre-install review is no longer enough because the package can act inside the agent's execution context after approval. At that point, the control that matters is what the runtime allows it to do, especially file access, network egress, and process creation. Behaviour enforcement becomes the real boundary.

Q: Why do compromised AI dependencies create such a large security risk?

A: Because a compromised dependency can inherit the credentials and trust of the environment it runs in. If that package sits inside a pipeline, IDE, or runtime with access to secrets or cloud services, the attacker gains an authenticated execution path. The result is wider blast radius than a normal code integrity issue.

Q: What signals indicate that runtime controls are actually catching supply chain attacks?

A: Look for denied credential reads, blocked outbound connections, and prevented process spawns from tool runtimes. Those events show the environment is intercepting hostile behaviour at execution time rather than relying on code review alone. A useful control produces auditable denials, not just policy intent.

Q: How should security teams balance package review with runtime enforcement for MCP?

A: Use review to reduce exposure, but do not rely on it as the last gate. For MCP and agent toolchains, runtime enforcement should be the decisive control because it governs the behaviour that emerges after installation. Review answers what a package looks like; runtime controls answer what it can do.

Technical breakdown

Why invisible payloads defeat pre-execution review

GlassWorm uses Unicode variation selectors to hide malicious JavaScript inside apparently blank lines. That means the threat survives ordinary source review, static inspection, and code-signing workflows because the representation of code is deceptive even when the package name looks legitimate. The deeper failure is not just obfuscation, but a mismatch between what reviewers think they are approving and what the runtime actually executes. In supply chain terms, the attack exploits the gap between intent review and behaviour enforcement. See the AI Coding Agents Security Guide.

Practical implication: review workflows need a runtime backstop, because code that cannot be seen reliably cannot be governed by inspection alone.

How MCP package compromise extends agent trust

An MCP package is not just another dependency. It becomes part of the tool layer that an AI agent can invoke, which means compromise gives the attacker access to the agent's execution context rather than only the host application's code path. That shifts the risk from software tampering to delegated authority abuse. Once installed, the package can operate with whatever filesystem and network access the environment granted at setup, so the trust boundary is the tool runtime, not the repository alone. See the AI Agent Authorisation Guide.

Practical implication: treat MCP packages as governed execution surfaces and scope their permissions as if they were privileged integrations.

Why syscall-level enforcement still works after installation

Runtime enforcement operates below the package layer by intercepting system calls such as open(), connect(), bind(), and process spawn. That matters because it governs what the malicious code actually does, not what it claims to be. In GlassWorm's case, denied file reads stop credential theft, denied outbound connections stop command-and-control, and denied process creation blocks secondary payloads. This is a behaviour control, not a content control, so it remains effective after a malicious package is already present and executing.

Practical implication: put policy at the kernel boundary when you need control that survives compromised packages and unreadable payloads.

Threat narrative

Attacker objective: The attacker wants durable footholds in developer environments, credential theft, and self-propagation through trusted package ecosystems.

1. Entry occurs through a legitimate-looking npm package or VS Code extension that installs into the developer environment and reaches the agent toolchain.
2. Credential harvesting follows as the malware reads .git-credentials, .npmrc, .aws credentials, SSH keys, local .env files, and wallet files from the filesystem.
3. Escalation and lateral use happen when stolen npm and GitHub credentials let the worm publish infected package versions and expand into new environments.
4. Impact is persistent propagation and criminal infrastructure support through SOCKS, HVNC, WebRTC, and DHT modules that turn infected machines into reusable attack nodes.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.

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

GlassWorm exposes an execution-trust gap, not just a package-trust problem: the important boundary is no longer whether a dependency was approved, but whether it can perform sensitive kernel operations once running. Pre-execution review can miss invisible payloads, while runtime enforcement sees the actual behaviour. The implication is that package governance must be paired with execution governance, because install-time trust is no longer sufficient.

Delegated tool access creates identity blast radius inside the agent runtime: an MCP package becomes part of the agent's tool authority, so compromise is functionally a delegated-identity event. The attacker is not only attacking code, but abusing the authority granted to a tool the agent can execute on demand. That makes the permission model around MCP packages a first-class identity control problem, not an application hardening detail.

Human review is no longer the primary verification control for supply chain safety: GlassWorm proved that reviewers can be forced to approve code they cannot visually inspect. That invalidates the assumption that static code review is the final gate for package trust. The implication is that organisations need to treat read-time, parse-time, and execute-time as different security moments with different controls, not as one review event.

Runtime enforcement turns compromise into observable policy failure: the most valuable control is not the one that promises the package is safe, but the one that records and blocks the dangerous action when it is attempted. GlassWorm's file reads, network beacons, and process spawns are all behaviour that can be constrained at execution time. The implication is that detection and prevention should converge around denied operations, because denied behaviour is the clearest signal of hostile code.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Zero Trust for AI Agents

What this signals

Runtime policy has become the practical control plane for AI toolchains: package approval, registry curation, and static analysis still matter, but they no longer close the gap once code is executing. The next governance question is not whether a dependency was sourced correctly, but whether its live behaviour stays inside an allowed execution envelope.

Execution-layer security: this article sharpens the case for treating tool runtimes as governed identity surfaces, because MCP packages can inherit authority at the point of action. For teams operating AI agents, the programme shift is from trust in the package to control over the syscall, the connection, and the process.

For practitioners

• Enforce execution-time policy on agent tools Place syscall-level controls around AI tool runtimes so file reads, outbound connections, and process spawns are mediated after installation, not only before approval.
• Inventory MCP packages and their trust boundaries Document which packages feed agent tools, which versions are installed, and which filesystem and network permissions each package can reach at runtime.
• Block credential paths from tool runtimes Deny reads of Git, cloud, shell, and environment credential locations from any process that executes as an AI tool or dependency.
• Require explicit approval for unknown outbound destinations Force unknown HTTPS destinations into an approval workflow so command-and-control beacons and hidden registry pushes cannot leave silently.
• Preserve denied-operation logs as forensic evidence Keep structured logs for blocked file, network, and process activity so attempted credential theft and propagation can be reconstructed after the fact.

Key takeaways

• GlassWorm demonstrates that supply chain compromise now reaches into agent tool runtimes, where the meaningful control is behaviour at execution time.
• The campaign's value as an indicator is the scale of compromised endpoints and the way hidden payloads bypass visual review.
• Security teams need runtime policy, denied-operation logging, and tighter trust boundaries for MCP packages if they want controls that still work after installation.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• MCP Package: An MCP package is a tool package used by an AI agent through the Model Context Protocol. In practice, it becomes part of the agent's delegated execution surface, so its permissions and behaviour need to be governed like a privileged integration, not treated as a routine library dependency.
• Execution Context: Execution context is the live operating state of an application, including which libraries run, which syscalls execute, and which network paths are used. In security practice, it helps separate theoretical exposure from code that is truly reachable and therefore more urgent to remediate.
• Service Supply Chain Attack: A service supply chain attack compromises trusted third-party providers, software dependencies, or managed services to reach downstream customers. In identity and security contexts, attackers abuse legitimate trust paths, such as updates, integrations, credentials, or APIs, to move through NHI, IAM, cloud, and application environments and affect many organizations at once.

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.