Slopsquatting: When Your AI Coding Assistant Installs a Package That Doesn't Exist
- Slopsquatting is a supply-chain attack that exploits LLM package hallucinations - the tendency of coding assistants to recommend or install dependencies that do not exist.
- Research has shown hallucinated package names are often repeatable and predictable, so attackers can pre-register them in public registries like npm and PyPI and publish malware there.
- When an AI coding assistant later suggests the same name and a developer or an auto-running agent installs it, the malicious package is pulled - no typo required.
- The distinction from classic typosquatting matters: typosquatting relies on human typos, while slopsquatting relies on model hallucination, so the fake name arrives with the model's confidence attached.
- Autonomous or YOLO-mode agents that install dependencies without human review turn a suggestion into an execution, removing the last check that would have caught the phantom package.
- The defenses are lockfiles and pinned versions, dependency allowlists, human review of installs, disabling auto-install, verifying a package exists and is reputable, and gating install commands at the hook level.
The phantom dependency problem
Ask an AI coding assistant to solve a problem and it will sometimes reach for a library that sounds exactly right - a clean, plausible name that fits the language's naming conventions and the task at hand. The only issue is that the library does not exist. This is a package hallucination, and on its own it is a nuisance: the install fails, the developer picks a real package, everyone moves on.
Slopsquatting turns that nuisance into an attack. It is a supply-chain attack that exploits LLM package hallucinations. An attacker pre-registers the hallucinated name in a public registry - npm, PyPI, or another - and publishes malware under it. Now the next time a model recommends that same phantom package and a developer or an autonomous agent installs it, the install succeeds, and the malicious code runs. The gap between 'this package does not exist' and 'this package exists and is hostile' is exactly the gap slopsquatting exploits. It belongs to the broader family covered in the AI supply chain attacks defender's guide.
Why hallucinated names are predictable
The attack only works at scale if the hallucinations are reusable, and research has shown they frequently are. The same model, asked the same kind of question, tends to invent the same plausible name - the hallucinations are often repeatable and predictable rather than one-off noise. A model that decides a certain utility 'should' be called by a particular name will keep reaching for that name across many runs and many users.
That repeatability is what makes slopsquatting economical. An attacker does not have to guess blindly. They can run popular models against common prompts, collect the phantom names that recur, register the highest-frequency ones, and then simply wait. The model becomes an unwitting distribution channel, recommending the attacker's package to a stream of developers who never typed the name themselves. Each victim receives the suggestion wrapped in the assistant's confident tone, which is precisely why it lands.
Slopsquatting vs typosquatting
Slopsquatting is often described as a cousin of typosquatting, but the mechanism and the psychology differ in ways that matter for defense. Typosquatting waits for a human to fumble a keystroke. Slopsquatting waits for a model to fabricate a name. The table lays out the contrast.
| Dimension | Typosquatting | Slopsquatting |
|---|---|---|
| Root cause | Human mistypes a real package name | LLM hallucinates a package name that never existed |
| Trigger | A typo at the keyboard | A confident AI recommendation |
| Target name | A near-miss of a real, popular package | A plausible-sounding name the model invented |
| Predictability for the attacker | Guess likely typos of popular names | Enumerate recurring, repeatable model hallucinations |
| Victim's guard | Higher - they typed the name themselves | Lower - the name came from a trusted assistant |
| Amplifier | Manual installs | Autonomous agents that auto-install without review |
The single most important row is the victim's guard. When you type a package name, you have a mental model of what you meant, and an unfamiliar result can look wrong. When an assistant hands you the name, you are inclined to trust it - the whole point of the tool is that it knows things you do not. Slopsquatting weaponizes that trust.
Why autonomous agents make it worse
In a traditional workflow there is a human between the suggestion and the install. A developer reads the recommended pip install or npm install line, and an unfamiliar name is at least a chance to pause. Autonomous and YOLO-mode agents remove that pause. They install dependencies as part of getting the task done, without surfacing each command for approval, so a hallucinated name goes straight from suggestion to execution on the machine.
This is the same excessive-autonomy risk that runs through agentic security generally. An agent that can run arbitrary install commands has, in effect, arbitrary code execution gated only by whatever the registry will serve it - and slopsquatting is a technique for making the registry serve something hostile. Constraining what these agents can install, and requiring review for anything new, is core to securing AI coding agents and CLIs, and the specific allow and deny limits are covered in Cursor auto-run YOLO limits. The underlying discipline is least privilege for AI agents: an agent that cannot reach the network or run installs unsupervised cannot be slopsquatted.
How to defend against slopsquatting
There is no single switch. The defense is a layered set of habits and controls, each closing part of the gap between a hallucinated suggestion and executed malware.
- Use lockfiles and pinned versions. Commit a lockfile and pin exact versions so an agent cannot silently add a dependency outside the vetted set. This blocks the easy path where a phantom package is quietly appended to an established project.
- Maintain a dependency allowlist. Restrict installs to an approved set of packages and registries, so a name the model invented is rejected by default rather than fetched.
- Keep a human in the loop for installs. Require review and approval of any new dependency an assistant proposes, especially names no one on the team recognizes.
- Disable auto-install for autonomous agents. Turn off YOLO or auto-run behavior for package installation so the agent proposes rather than executes.
- Verify the package exists and is reputable before installing. Check that it is real, and inspect its age, download counts, maintainer, and repository. Distrust brand-new packages with no history - a freshly registered name matching a hallucination is a red flag.
- Gate package-install commands at the hook level. Intercept install commands before they run and evaluate them against policy, so a phantom-package install is caught even when a human is not watching.
A useful mental default: treat any dependency that originated with the model, rather than from your team's known-good set, as unverified until proven otherwise. The cost of confirming a package is real is trivial next to the cost of running attacker code with your developer's privileges. Pair this work with the broader supply-chain playbook and with LLMjacking stolen-key cost abuse, since a malicious dependency is one common way a plaintext key gets stolen.
Where continuous visibility fits
Every control above assumes you know which coding agents and CLIs are running, in what mode, on which machines. In practice that inventory rarely exists. Developers adopt assistants bottom-up, enable auto-run to move faster, and no one in security has a list of which tools across the fleet will install a package without asking. You cannot enforce a no-auto-install policy on an agent you have never seen.
This is where Anomity sits. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, and Linux) and inventories eight AI artifact types - agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - sending metadata only over HTTPS, never source code and never prompts. That surfaces which coding agents are present and which are configured to install without review, so the auto-install exposure becomes a query rather than a guess.
On agents that expose a hook, Anomity applies runtime governance: it evaluates each tool call before it runs and returns allow, deny, or log, so a package-install command for a name that fails policy can be denied at the moment of execution rather than after the malware has run. Continuous policy evaluation routes violations to your SIEM, Slack, email, and Jira, and every added, removed, or modified artifact lands in a queryable 90-day audit trail. Anomity complements - it does not replace - your registry controls, SCA tooling, and code review; it makes the agent behavior those tools assume actually visible and enforceable on the endpoint.
You can't govern what you can't see.The Anomity principle
For the wider picture, start with the AI supply chain attacks defender's guide, then read securing AI coding agents and CLIs and Cursor auto-run YOLO limits. To see which of your coding agents install packages unsupervised and what runtime governance would deny, book a 30-minute demo.
Frequently asked questions
What is slopsquatting?
Slopsquatting is a supply-chain attack that exploits LLM package hallucinations. AI coding assistants sometimes recommend or auto-install dependencies that do not exist. Attackers register those hallucinated names in public registries and publish malware under them, so that when an assistant later suggests the same name and someone installs it, the malicious package is pulled. The name comes from combining 'slop' - low-quality AI output - with the older idea of squatting on package names.
How is slopsquatting different from typosquatting?
Typosquatting relies on a human mistyping a real package name - registering 'expres' to catch people who meant 'express'. Slopsquatting relies on the model inventing a plausible name that never existed at all. The critical difference is the delivery vehicle: with slopsquatting the fake name arrives inside a confident AI recommendation, so the developer's guard is lower than when they are typing a name themselves.
Why are hallucinated package names dangerous if they are random?
They are not random. Research has shown that these hallucinations are often repeatable and predictable - the same model will invent the same plausible name for the same kind of request across many runs. That repeatability is what makes the attack economical: an attacker can enumerate likely hallucinations, pre-register the ones that recur, and wait for the model to recommend them to someone else.
What makes autonomous agents especially risky here?
Autonomous or YOLO-mode agents install dependencies without pausing for human review. In an interactive session a developer might notice an unfamiliar package name before running the install. An auto-running agent skips that check entirely, turning a hallucinated suggestion directly into a code-execution event on the machine. See Cursor auto-run YOLO limits for how these modes behave.
Can lockfiles alone stop slopsquatting?
Lockfiles and pinned versions are a strong defense for established projects because they prevent an agent from silently adding a new dependency outside the vetted set. They do not help at the moment a genuinely new dependency is being introduced, which is exactly when a hallucinated name can slip in. That is why lockfiles need to be paired with human review of new installs and a verification step that the package actually exists and is reputable.
How do I verify a package before installing it?
Confirm the package genuinely exists in the registry, check its age, download counts, maintainer, and repository, and be suspicious of a package that appeared very recently or has almost no history. If an AI assistant suggests a dependency you have never heard of, treat that as a prompt to verify rather than a reason to trust it. Prefer well-known, widely-used packages over novel ones the model produced on its own.
How does Anomity help with slopsquatting?
Anomity inventories eight AI artifact types on every managed endpoint - including the coding agents, CLIs, and skills that run installs - so you can see which tools are operating in auto-install modes across the fleet. On agents that expose a hook, Anomity evaluates each tool call before it runs and can allow, deny, or log a package-install command, so a phantom-package install can be gated rather than executed. Every artifact change is recorded in a queryable 90-day audit trail for later review.
