Catch AI-invented dependencies before they ship.
pip install is all it takes.One name a model made up = a way in.
LLMs don’t know which packages exist — they predict plausible names. That predictability is the attack, and it runs in three moves.
The model invents a name
An AI agent imports a package that sounds right — but was never published. The same fake names recur across prompts.
An attacker registers it
Adversaries watch for commonly-hallucinated names and claim the empty slot on PyPI or npm with malicious code.
Your install runs their code
The next install in CI pulls and executes it — at install or import time, inside a credentialed pipeline.
It asks the one question a scanner can’t.
Provenance reads the files where dependencies are declared — package.json, requirements*.txt, pyproject.toml — not your source, and asks the registry: does this name resolve? A 404 on PyPI and npm is a fact.
No LLM in the loop — a name either resolves or it doesn’t.
We caught a real one on the first scan.
Pointed at a live estate, the first full scan flagged an invented dependency — and we closed it before it could ever be weaponized.
First full scan flagged pyodbc-binary — coined by analogy to the real psycopg2-binary. PyPI 404 · npm 404.
One-line rename to pyodbc — merged inside the safe window, before anyone could register the name.
Next sync confirmed the estate resolves clean — caught → fixed → green, recorded as evidence.
The questions teams ask.
What is slopsquatting?
Slopsquatting is a supply-chain attack that exploits AI coding assistants. Large language models routinely 'hallucinate' dependency names — they confidently import a package that sounds plausible but does not exist. Attackers watch for these commonly-hallucinated names, register the empty name on a public registry (PyPI, npm), and publish malicious code under it. The next time an AI agent suggests that import and a developer runs an install, the attacker's code executes. The term is a play on 'typosquatting' — but instead of relying on a human typo, it relies on an AI's mistake.
Why is a hallucinated dependency dangerous if the name doesn't exist yet?
Today an unregistered name is just a broken build. The danger is the window: the moment an attacker registers that (currently empty) name, the next `pip install` or `npm install` in that repository's CI or a developer's machine pulls and executes the attacker's code at install or import time — inside a credentialed pipeline. That is remote code execution leading to credential theft and supply-chain compromise. Catching it while the name is still unregistered means the fix is free — you rename the dependency before anyone can weaponize it.
How is this different from a normal dependency scanner (SCA)?
Software Composition Analysis tools check the packages you depend on for known vulnerabilities (CVEs) and license issues — they assume the package exists and ask 'is it safe?'. Provenance asks a prior question: 'is it real?'. A hallucinated dependency has no CVE because it has no code — an SCA scanner has nothing to flag. Provenance reads your dependency manifests and checks each declared name against the live public registry. A name that resolves nowhere is the finding. It's a complement to SCA, not a replacement.
Does Provenance use an LLM to detect hallucinated dependencies?
No — and that's deliberate. The check is deterministic: Provenance reads your declared dependencies (package.json, requirements*.txt, pyproject.toml) and asks the registry whether each name resolves. A 404 on PyPI and npm is an observed fact, not a model's guess. Using an LLM to judge whether a package is 'real' would reintroduce the exact hallucination problem we're catching. The verdict is honest by construction: a genuine 404 is flagged; a registry error is reported as unverified, never accused; a repo scanned with no manifests is reported as out-of-scope, never a false 'clean'.
Which package ecosystems does it cover?
Today Provenance reads Python (requirements*.txt, pyproject.toml) and JavaScript/TypeScript (package.json) manifests and checks names against PyPI and npm. It deliberately ignores non-registry references (local paths, git URLs, workspace and catalog protocols) so those never produce false flags. More ecosystems (go.mod, Cargo, Gemfile) are on the roadmap — the underlying registry-existence engine is the same one that powers Provenance's unregistered-package control.
What about internal or private packages — won't those be flagged?
Provenance distinguishes an honest 404 from an unverifiable one. Private-registry and scoped packages that the public registry can't confirm are reported as unverified rather than flagged as hallucinated, so your internal packages don't generate noise. The hard flag is reserved for names that genuinely resolve in no registry — the slopsquatting signature.
What do I do when Provenance flags one?
Rename the dependency to the real package — while the hallucinated name is still unregistered, the fix is a one-line change with no exposure. Then pin and lock (a lockfile / `uv lock`) so the resolved set is frozen. Provenance records the flag and, after your next sync, confirms the manifest resolves clean — the caught-to-fixed loop is itself part of your governance evidence.
Related from Provenance.
See your evidence this afternoon.
Connect your first repo in minutes — read-only, no credit card, no sales call. Your Provenance Score, your blind spots, and your first board-ready briefing, from your own estate.