For fifteen years, npm package security assumed one thing: a human sat between the decision to add a dependency and the moment it landed on disk. Someone typed the package name; someone hit enter. That assumption is quietly disappearing, and it’s happening at the exact moment npm has become the most targeted package ecosystem in software supply chain history.
npm’s target-rich history, before AI even entered the picture
npm was already the ecosystem attackers gravitated toward, and the last twelve months show why. In September 2025, Shai-Hulud became the first self-propagating worm to spread through npm, turning developers themselves into the delivery mechanism. In March 2026, axios, a package pulled more than 100 million times a week, was compromised with nation-state malware hidden inside it. A month later, a near-identical worm pattern hit the npm ecosystem again through SAP packages, the same playbook, repeated at scale. Three major incidents in eight months, all in one registry. That’s the baseline. AI agents change what happens next.
It’s also what we’ll be talking through on the ground at German OWASP Day 2026, September 23-24 in Karlsruhe. More on that at the end!
What changes when the install isn’t typed by a human
Agentic coding assistants don’t just suggest code anymore. Increasingly, they decide a dependency is needed, choose a package, and run the install, mid-task, without a human reading the package name first. Two things about how they do it should worry any team relying on npm package security practices built for a human-in-the-loop world.
- Agents hallucinate package names, and attackers know it. Large-scale academic research generated more than two million code samples across sixteen LLMs and found that nearly one in five recommended packages didn’t exist at all, over 200,000 unique hallucinated names. Worse, researchers found the same hallucinated names recurring across repeated prompts, which means they’re farmable: an attacker can register the name an AI model is statistically likely to suggest before anyone else does, and wait.
- The install itself has become an attack vector. A critical vulnerability in a widely used MCP bridge, downloaded more than 437,000 times, allowed full remote code execution the moment a client connected to an untrusted MCP server, the kind of connection an autonomous agent can make on its own. The traditional npm package security checkpoint, a person pausing to look at what they’re about to run, doesn’t exist in that workflow. The agent decides and executes in the same step.
Two layers of npm package security that don’t depend on a human noticing
This is where npm package security has to move from “a developer reads carefully” to “the platform decides, automatically, every time.” Xygeni AI Security covers this with two distinct layers.
- MEW (Malware Early Warning) watches the registry itself. It continuously scans newly published packages across npm, PyPI, and Maven, and flags malicious ones through behavior analysis, not signature matching, which means it catches malware before a public signature exists for it at all. Flagged packages are researched, confirmed, and reported back to the public registry to help stop further distribution. This applies equally to a package a developer adds by hand and one an agent selects on its own, since MEW doesn’t care who initiated the install, it cares what the package does. It’s also part of Xygeni’s free Developer tier.
- Shield enforces policy at the exact moment the install happens. It intercepts npm, PyPI, and Maven traffic at the operating system level, transparently, with no reconfiguration of the package manager required. Every install is checked against your organization’s policy before the package ever reaches disk and before any install script executes. And because Shield attributes every decision to the exact process, PID, executable, and command line that requested it, it doesn’t matter whether that request came from a developer’s terminal or an agent running autonomously in the background, the policy applies the same way, every time. Decisions resolve in single-digit milliseconds from cache, so it doesn’t slow anyone, human or agent, down.
Together, that’s registry-level detection and install-time enforcement, covering the two moments where npm package risk actually materializes.
This is the AI Security conversation, not a side note to it
npm package security is one visible slice of a larger shift: AI is now part of the attack surface, not just a tool developers use. The same models, agents, and MCP servers that decide to run an npm install are AI assets your organization runs and, in most cases, doesn’t fully inventory. Xygeni AI Security discovers those assets, scores their risk against the OWASP Top 10 for LLM Applications, and, through DevAI, fixes vulnerable code, AI-generated or human-written, inside the IDE before it ships. We wrote more about that discover-detect-fix framing, and why discovery alone isn’t enough, in a companion post on AI Security Posture Management.
Xygeni at German OWASP Day 2026
We’re bringing this exact conversation to Karlsruhe. Xygeni is a sponsor at German OWASP Day 2026, running September 23-24 at the IHK Haus der Wirtschaft, alongside roughly 200 application security professionals from across Germany and the region.
We’ll be talking through npm package security in an agentic world: what MEW and Shield actually catch, what the current MCP and slopsquatting threat data looks like, and how AI-generated code security fits into a program that’s already running SAST, SCA, and secrets scanning rather than sitting apart from it.
The same week, we’re also at OWASP AppSec Days Portugal 2026 in Porto, where we’re a Gold sponsor talking through AI Security Posture Management more broadly. Whichever event fits your calendar, we’d be glad to talk!
FAQ
Why does npm package security need to change because of AI agents?
Most npm package security practices assume a human reviews a package name before installing it. Agentic coding assistants can choose and install a dependency in the same step, with no human review in between, which removes the checkpoint that practice depended on. Detection and enforcement need to happen automatically, at the registry and at install time, regardless of who or what initiated the install.
What is slopsquatting?
Slopsquatting is when an attacker registers a package name that AI coding assistants are likely to hallucinate and recommend. Research generated over two million code samples across sixteen LLMs and found nearly one in five recommended packages didn’t exist, and that many of the same hallucinated names recurred across repeated prompts, making them predictable enough to register in advance.
What’s the difference between MEW and Shield?
MEW watches the registry: it scans newly published npm, PyPI, and Maven packages and flags malicious behavior before a public signature exists. Shield watches the install: it enforces your organization’s policy at the operating system level the moment a package install is requested, blocking it before it reaches disk if it violates policy. One is detection at publication time, the other is enforcement at install time.
Does this replace SCA scanning?
No. Xygeni’s AI Triage, Explanation, and Remediation apply to findings from Xygeni’s own scanners and to findings ingested from third-party SCA and AppSec tools already in place, so npm package risk gets covered without ripping out existing tooling.
Where can I talk to Xygeni about this?
Xygeni is at German OWASP Day 2026, September 23-24 in Karlsruhe, talking through npm package security and AI Security. We’re also a Gold sponsor at OWASP AppSec Days Portugal 2026, the same week, in Porto.
