An engineer asked an agent to add rate-limiting to a service. The code it produced was clean, idiomatic and immediately importable — it pulled in a small, sensibly named package, wired it in, and the tests went green. There was only one problem. The package had not existed the week before. An attacker had read the same statistical tea-leaves the model had, registered the name the model liked to invent, and filled it with code that exfiltrated environment variables on install. Nobody typed a wrong character. The agent simply trusted a name it had dreamed up — and so did everyone downstream of it.
What slopsquatting is
Slopsquatting is a supply-chain attack that exploits the tendency of AI coding tools to hallucinate dependencies — to confidently import or install packages that do not exist. Attackers register those hallucinated names on public registries such as npm and PyPI and fill them with malware. When the next developer’s agent suggests the same name, the install succeeds and the malicious package runs. The term is a play on typosquatting; the difference is that the victim never made a typo — the machine invented the target.
The scale is not hypothetical. Academic work presented at USENIX Security found that a large fraction of AI-suggested packages do not exist — on the order of one in five across a wide sample of models and prompts — and, crucially, that the hallucinations are not random noise. The same fabricated names recur: a large share repeat across runs, which hands an attacker a stable, rankable target list rather than a lottery. Security researchers have since documented real malicious packages, planted on the strength of that predictability, accumulating tens of thousands of downloads. OWASP’s guidance for agentic applications now lists slopsquatted dependencies explicitly among agent supply-chain risks.
Why it is worse than ordinary typosquatting
Classic typosquatting relies on human error — a fat-fingered “expres” instead of “express”. It is opportunistic and noisy. Slopsquatting is different in three ways, and each makes it more dangerous.
| Typosquatting | Slopsquatting | |
|---|---|---|
| Trigger | Human typo | Model hallucination |
| Predictability | Scattered, low-yield | Repeatable — the same fake names recur |
| Trust context | A careful reader may catch it | Arrives inside plausible, working-looking code |
| Scale | One mistake at a time | Every team on the same model shares the blind spot |
The third row is the sharpest. Agentic code arrives looking finished. A fabricated dependency does not announce itself — it sits inside otherwise correct code, with a name that looks exactly as it should. The reviewer’s eye, trained on human mistakes, slides right over it. This is the same difficulty that makes reviewing AI code different in kind from reviewing human code: the author cannot tell you where it was unsure, because it never was.
We spent a decade learning to sign artefacts and refuse a build whose provenance we could not establish — then we wired up agents and quietly trusted whatever name the model typed. The supply chain did not change; we just stopped guarding its newest entrance.
The defence is unglamorous, and it works
There is no reliable model-side trick that stops hallucinated dependencies; the fix is conventional supply-chain hygiene, enforced automatically at the gate.
- Pin and lock: commit lockfiles and verify integrity hashes, so a name alone is never enough to pull code — only the exact, known artefact is.
- Allowlist, do not denylist: agents may install only from a curated set of vetted packages; anything new requires a human-approved addition.
- Verify provenance at the gate: refuse a build that introduces a dependency without an establishable origin and signature (SLSA-style provenance, SBOM/AI-BOM checks).
- Flag the new and the non-existent: scan agent output for packages that do not exist or were registered days ago, and treat near-zero-history packages as suspect by default.
- Constrain the agent: where possible, point coding agents at an offline or mirrored registry so they cannot reach for an arbitrary public name at all.
None of this is new security science. It is the build-time supply-chain discipline of the last decade — provenance, signing, SBOMs, allowlists — applied to a new entry point: the code an agent writes while you watch. The mitigations belong at the merge gate, checked on every change, not in a separate scan that runs long after the dependency is already in main.
The principle underneath
Slopsquatting is a specific instance of a general rule for agentic delivery: an agent’s confidence is not evidence. The model is equally fluent whether it is naming a real package or one it wishes existed, and that fluency is exactly what disarms the reviewer. The posture that protects you here — verify provenance, trust the artefact not the name, enforce it automatically — is what keeps every other kind of agent output honest. Treat the things an agent reaches for with the same suspicion you have learned to apply to the things it produces.
Frequently asked
- What is slopsquatting?
- A supply-chain attack that exploits AI coding tools’ tendency to hallucinate package names. Attackers register the non-existent packages that models commonly invent and fill them with malware, so when an agent suggests the name, the install pulls hostile code. It is the AI-native relative of typosquatting — but the victim never makes a typo; the model invents the target.
- How common are hallucinated packages?
- Research presented at USENIX Security found roughly one in five AI-suggested packages did not exist across a broad sample, and that a large share of the fabricated names recur across runs — making them a predictable, reusable target for attackers rather than random noise.
- How do you defend against slopsquatting?
- With conventional supply-chain hygiene enforced automatically at the merge gate: lockfiles and hash verification, dependency allowlists, provenance and signature checks (SLSA, SBOM/AI-BOM), and flagging brand-new or non-existent packages before merge. Where possible, restrict agents to a mirrored or vetted registry.
- Why can the model not just stop hallucinating dependencies?
- Because it is equally fluent when naming a real package and an imagined one; there is no reliable internal signal that distinguishes them. That is why the control has to live outside the model — in the build and review pipeline — rather than in better prompting.