A Tool to Block AI From Installing Malicious npm Packages

Short answer: The reliable way to block AI from installing malicious npm packages is to enforce the block at the registry, not in the prompt. Point every package manager the agent uses (npm, yarn, pnpm, bun) at a registry firewall that refuses to serve known-malicious and known-vulnerable versions, so a bad tarball never reaches the machine in the first place. InstallSafe does this with two config lines (registry URL and token) and no change to the agent's workflow.

What happens when an AI agent runs npm install?

In January 2026, Aikido researcher Charlie Eriksen noticed something odd. An npm package called react-codeshift was being referenced in AI agent skill files. It had never existed. No human had typed it. A language model had invented the name by blending two real tools (jscodeshift and react-codemod), the hallucination got baked into a batch of agent instruction files, those files were forked and copied across 237 repositories, and coding agents had been dutifully trying to install the phantom package ever since.

Eriksen registered the name himself before anyone else could, and immediately saw downloads roll in. That is the only reason it did not become an attack. He called the pattern slopsquatting.

A few months later, attackers stopped waiting for luck. In August 2026, OpenSourceMalware tracked a single actor pushing more than 700 malicious packages to npm in about 48 hours, under AI-flavored, generated names. The Hacker News put the running total near 800. No install script needed. Each README tells the reader, human or agent, to require() the module, and that one line kicks off the WEL1DROPPER loader, which fetches a cross-platform remote access trojan and infostealer for Windows, macOS, or Linux.

If you let an AI coding agent run npm install on your machine or in CI, you are the target of that campaign.

Why are AI coding agents a softer target than developers?

• No instinct for "that name looks wrong." A human pauses, searches, checks GitHub stars, skims the README. An agent treats its own output as ground truth and shells out.
• Hallucinations are predictable. The Cloud Security Alliance's April 2026 research note cites work where roughly 20% of AI-generated code samples referenced packages that do not exist, and 43% of hallucinated names came back on every one of ten re-runs of the same prompt. An attacker can just ask a model, collect the recurring names, and register them first.
• Hallucinated names aren't typos. npm's name-similarity checks can catch lodahs next to lodash. They do nothing for react-codeshift, a brand-new string. The install succeeds cleanly, no error.
• Agents run unattended, with your privileges. In CI or a dev container they hold your npm token, SSH keys, and cloud credentials. By the time the diff is reviewed, the postinstall has run, or the package was imported during a test.

The conclusion is uncomfortable but simple: you cannot prompt your way out of this. "Only install well-known packages" in a system prompt is a suggestion, not a control. Verification has to move to the moment the install happens, not the moment the PR is opened.

How do you block AI from installing malicious npm packages?

Gate the install, not the intent. Every package manager, and every agent driving one, fetches metadata and tarballs from whatever registry URL is configured. That URL is the one chokepoint shared by your laptop, your CI runners, your Docker builds, and Claude Code, Cursor, Copilot, or any other agent that shells out to npm install. Put a firewall there and you enforce the rule everywhere at once.

InstallSafe is that firewall: a drop-in npm registry proxy. Here is how it works.

1. Every request is checked at the registry boundary. When npm asks for a package version, InstallSafe checks it against live OSV.dev advisory data and the OpenSSF malicious-packages feed.
2. Flagged versions are never served. A known-malicious package, or a known-vulnerable version of a legitimate one, is filtered out of the response. The bad tarball never reaches the machine, so there is no postinstall to run and nothing for the agent to require().
3. Safe packages are byte-for-byte identical. Allowed tarballs are the same bytes the public registry serves, so package-lock.json integrity hashes stay valid and nothing about your build changes.

Point your package manager at it. Two commands:

npm config set registry https://r.installsafe.io
npm config set //r.installsafe.io/:_authToken <your-token>

yarn, pnpm, and bun accept the same URL through their own registry settings or a shared .npmrc. Commit the .npmrc and every agent, CI job, and teammate working in that repo inherits it.

It is server-side, so there is nothing to install on the agent, no shell shim to maintain, no hook to wire into each tool, and no y/n prompt for an unattended process to ignore. It fails open by default, so an outage degrades to "plain npm" rather than a broken pipeline.

Why is a registry firewall the right layer for AI agents specifically?

Most npm security tooling runs after the fact: a scanner in CI, a PR bot, a dashboard. Those are useful, but an agent working unattended has already executed the install by the time a scanner reads the lockfile. A registry firewall is the only control that acts before the bytes land, and it applies automatically to every install path without any workflow change:

• Local agents in Claude Code, Cursor, Copilot, Windsurf, or a terminal agent.
• CI runners (GitHub Actions, GitLab CI) and Docker builds that use the same .npmrc.
• Dev containers, Codespaces, and any sandbox that installs dependencies.

Treat every package name an AI hands you as a guess, not a fact. The registry firewall is where that guess gets checked against what the security community already knows is bad.

What does a registry firewall NOT solve?

Be honest with yourself about the coverage, because this is where teams get burned.

• Zero-hour hallucinated names. InstallSafe is advisory-based. It blocks a package or version once it is flagged in OSV.dev or the OpenSSF feed. A freshly registered slopsquat that nobody has reported yet will not be on those lists at minute zero. Campaigns like WEL1DROPPER get flagged quickly because researchers are watching for them, but there is a window, and you should assume it exists.
• A trusted package that turns malicious before advisories exist. When a maintainer account is compromised and a new version of a popular package ships malware, the first installs happen before anyone has published an advisory. Pair the firewall with lockfile pinning and integrity-hash verification (npm ci, committed lockfiles). InstallSafe preserves both, since the tarballs it serves are identical.
• Code analysis. InstallSafe filters on provenance and advisories. It is not a static analyzer and does not read the package's code. For behavioral and code-level signals, pair it with a scanner. Our free scan checks an existing dependency tree for known-malicious and known-vulnerable versions in seconds.
• Agent permissions. The firewall limits what gets installed, not what an agent can do with the credentials on the box. Keep least-privilege tokens in CI and scope agent sandboxes regardless.

The defensible claim is narrower than "stops every attack" and still worth a lot: for agents that install unattended, the registry is the one chokepoint where you can enforce "no known-malicious version reaches an install" across every agent, CI job, and dev box, automatically.

How do you set this up for your AI agents?

1. Baseline your exposure. Run the free InstallSafe scan against a project to see whether anything known-bad is already in the tree.
2. Set the registry. npm config set registry https://r.installsafe.io, or add registry=https://r.installsafe.io to a committed .npmrc so yarn, pnpm, bun, CI, and agents all pick it up.
3. Reinstall and confirm. Run your normal install. Lockfile hashes should match; the build should pass unchanged.
4. Keep lockfile discipline. Use npm ci (or the equivalent) in CI and agent sandboxes so installs are reproducible and integrity-checked.
5. Let the agents loose. Nothing to configure in Claude Code, Cursor, or Copilot. They call npm; npm calls the firewall.

Frequently asked questions

What is slopsquatting?

Slopsquatting is registering a package name that does not exist but that an AI model is likely to hallucinate, so that a developer or AI agent installs the attacker's package believing it is real. Unlike typosquatting, it does not rely on a human mistake, only on the model repeating the same invented name.

Can I stop AI agents from installing bad packages with a system prompt?

Not reliably. Prompts are suggestions; agents still treat their own hallucinated names as facts and run the install. The control has to sit at the install boundary, which is why a registry firewall works where instructions do not.

Does InstallSafe catch a brand-new hallucinated package immediately?

No. InstallSafe blocks packages and versions once they are flagged in OSV.dev or the OpenSSF malicious-packages feed. It is not a zero-hour heuristic detector. Its strength is enforcing known-bad blocks automatically across every agent, CI job, and developer machine.

Will switching registries break my lockfile?

No. Allowed tarballs are byte-for-byte identical to the public registry's, so package-lock.json, yarn.lock, and pnpm-lock.yaml integrity hashes stay valid.

Does it work with yarn, pnpm, bun, and CI?

Yes. Anything that fetches from an npm-compatible registry URL works. Set the URL once in a committed .npmrc and local installs, CI runners, Docker builds, and AI agents all go through the firewall.

What happens if InstallSafe is unreachable?

It fails open by default, so installs fall back to normal registry behavior rather than breaking your pipeline. Fail-closed (failOpen: false) is a registry-level setting for self-hosted registries; there is no per-team switch yet.

The bottom line

AI agents will keep inventing package names, and attackers will keep registering them. The fix is not better prompting; it is a gate at the one place every install passes through. Run the free scan to see your current exposure, then set the registry and let your agents install through a firewall.