Hallucinated Dependencies: Nothing Installs on the Model's Say-So
19.7% of packages recommended by code-generating LLMs do not exist. That figure comes from a USENIX Security 2025 study of 16 models across 576,000 Python and JavaScript samples, summarized by Socket: open-source models hallucinated at ~21.7%, commercial models at ~5.2%, with CodeLlama above 33% and GPT-4 Turbo at 3.59%. The study observed 205,000+ unique hallucinated names. An agent that installs dependencies autonomously turns each of those names into an executable event, because package installation can run publisher-controlled code inside the agent's environment.
An LLM's output is untrusted input to the build system, and must be validated like any other. This is the last of the decision gates this section assembles, and the only one that operates on package identity rather than on a person's approval. The others (review as a gate, author never approver, auto-approval graded by risk, scope discipline) decide whether a change is allowed to advance. This one decides whether a name the model invented is allowed to execute. It is also a prescription, not observed industry practice.
The hallucinations repeat, so attackers pre-register them
A hallucination that never recurs is noise. These recur. Re-running 500 hallucination-triggering prompts ten times each, 43% of hallucinated package names reappeared on every single run, and 58% reappeared more than once. So an attacker prompts a model, records which fake names it reliably invents, and registers those exact names as malware. The practice has a name, slopsquatting, coined by PSF Developer-in-Residence Seth Larson.
It works in the wild. Researcher Bar Lanyado registered huggingface-cli, a name LLMs frequently hallucinated, as an empty PyPI package. It drew over 30,000 downloads in three months, including from major companies' pipelines. The names are plausible by construction: ~51% of hallucinated names in the study were entirely fabricated yet contextually plausible, ~38% were conflations of real packages, only ~13% were simple typos.
The other half of the threat is the wrong-version problem: a package you already trust ships a poisoned release. In the August 2025 Nx "s1ngularity" attack, a stolen npm token published malicious Nx versions whose postinstall script harvested credentials, even driving locally installed AI CLIs with --dangerously-skip-permissions and --yolo flags to hunt the filesystem. The poisoned versions lived roughly four hours and still hit 400+ organizations and 5,500+ repositories. Full incident writeups: slopsquatting and Nx s1ngularity.
Lockfiles don't stop agents
Lockfile-only CI (npm ci, frozen lockfiles) stops silent drift and @latest auto-pulls. It would have stopped the Nx Console amplifier, which auto-installed nx@latest on editor open. It does nothing against an agent introducing a new dependency, because the agent legitimately edits the manifest and the lockfile in its own branch. The lockfile then faithfully pins the slopsquatted package.
Merge-time review fares only slightly better. GitHub's dependency review action diffs dependencies per PR and can block the merge, but in an agent workflow the postinstall already ran in the agent's sandbox during iteration, before any PR existed. Merge gates protect the codebase; only install gates protect the environment.
Domain allowlists don't either, and they are most of what platforms ship
The dominant platform control gates the host, not the package. OpenAI Codex names "downloading malware or vulnerable dependencies" as a risk and offers a domain allowlist with a "Common dependencies" registry preset as the mitigation. Claude Code and Cursor cloud agents likewise gate at the domain level. Allowing registry.npmjs.org allows all ~3 million packages on it, slopsquats included; the malicious package is served by the allowlisted host.
The one documented exception: GitHub Copilot's coding agent checks newly introduced dependencies against the GitHub Advisory Database for malware and High/Critical CVEs before the PR completes. That is real agent-specific dependency gating, but it is known-bad detection: a freshly registered slopsquat has no advisory yet. No vendor we surveyed documents package-identity verification, in-sandbox cooldown enforcement, or registry-proxy integration as a first-class feature. The gate has to come from the environment you control. (Disclosure applies to the sponsor too: Wallfacer, the sponsor of this guide, does not ship this control either. Nobody does.)
The three gates that cover both chains
No single control covers both the wrong-identity and wrong-version chains. The minimal covering set is three gates, at install time, publish-age time, and review time:
| Gate | Slopsquatting (wrong identity) | Nx-style (wrong version) |
|---|---|---|
| Deny-by-default registry path (curated proxy) | Prevents: a hallucinated name fails closed, before any install script | Prevents known-bad; needs cooldown for fresh poison |
| Release-age cooldown | Prevents fresh registrations; a patient attacker who ages the package defeats it | Prevents: the ~4-hour Nx window never becomes installable |
| Dependency diff at the review gate | Detects: new package is a reviewable event with name, age, publisher, advisory status | Detects version bumps explicitly |
The cooldown is the cheapest win and already a quiet industry consensus: npm shipped minimumReleaseAge in 11.10.0 (February 2026), pnpm and yarn have equivalents, and Andrew Nesbitt's Package Managers Need to Cool Down catalogs the same idea under at least ten configuration names. Honest caveats: npm's implementation has no exclusion for urgent security fixes, and Lanyado's proof-of-concept package sat collecting downloads for three months, well past any sane cooldown.
The three gates span all three acts of this handbook. The review-gate diff is a decision gate in this section: it plugs into review as a gate so a new package is never merged solely because the model named it. The registry proxy is a property of the environment you build, the same egress boundary covered under egress control. And the whole set is the compliance argument's seventh property, dependency provenance, stated here as process: the agent's environment already mediates its credentials, network, and code; the package registry should not be the one unmediated channel left.
Producer-side controls (npm trusted publishing, 2FA-gated staged publishing, SLSA attestations) closed the exact link the Nx attacker exploited, and Nx adopted them post-incident. They do nothing for slopsquatting: the attacker is the legitimate publisher of their own malicious package, provenance and all. Provenance proves origin, not intent. The consumer-side gate is the control.