For fifteen years, npm package security rested on one assumption so obvious nobody wrote it down: a human sat between the decision to add a dependency and the moment it landed on disk.
Agentic coding assistants quietly removed that checkpoint. They decide a package is needed, pick one, and run the install — mid-task, without review. The pause that was doing security work without anyone noticing is no longer in the workflow.
That matters more than it sounds, because npm was already the most attacked package ecosystem in software development before agents showed up.
What's actually happening at the registry level
Research across 16 LLMs generated two million code samples and found nearly 1 in 5 recommended packages didn't exist. The same hallucinated names recurred predictably across models and prompts. Predictable enough to register in advance. Predictable enough to weaponize before your agent asks for them. That attack has a name: slopsquatting.
On top of that, a critical RCE vulnerability in a widely used MCP bridge fired the moment a client connected to an untrusted server. An agent makes that connection autonomously. No user interaction. No existing tool in a standard AppSec stack intercepts it before it happens.
Why your current tools don't see it
SAST parses code. SCA checks what's already in your dependency tree. Neither has visibility into what an AI agent just decided to install two minutes ago, or what an MCP server is doing mid-task.
This isn't a configuration gap. It's a category gap that opened quietly as autonomous agents became standard in how software gets built.
The full breakdown — what changed in the npm threat model, what the MCP attack surface looks like, and what actually closes the gap at the registry and install layer — is here:
👉 npm Package Security: What Changes When Your AI Agent Runs the Install
If you're running any agentic tooling or care about supply chain threats, it's worth the read.
Top comments (0)