What Is Slopsquatting? AI Package Hallucination Attacks

Slopsquatting is a software supply-chain attack that exploits AI code generation. Large language models sometimes recommend packages that do not exist. If the same fake name comes up repeatedly, an attacker can register it on a public registry such as PyPI or npm and publish malicious code under it. The next developer or coding agent that follows the model's suggestion installs the attacker's package. The name is a play on typosquatting. The attacker does not rely on a human typo. They rely on the model's "slop": confident output that is wrong.

How a package hallucination becomes an attack

The attack has four steps:

The model invents a dependency. Asked to solve a task, a code model writes import or require statements and install commands for a package that sounds plausible but has never been published.
The name repeats. Some hallucinated names come up again across prompts or sessions. A name that a model produces consistently is a usable target.
The attacker registers it. Public registries accept new names on a first-come basis. The attacker publishes a package with that name, often with an install script or import-time code that runs immediately.
Someone installs it. A developer copies the suggested command, or a coding agent runs pip install or npm install itself. The malicious code runs with that user's or agent's permissions: environment variables, credentials, source code and network access.

Nothing in this chain requires the attacker to compromise the model. They only need to observe its mistakes and be first to the registry.

What the research shows

The core study is We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (Spracklen et al., 2024). The authors used 16 popular code-generation models and two prompt datasets to generate 576,000 code samples in Python and JavaScript. Their findings:

The average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models.
They recorded 205,474 unique hallucinated package names.
Mitigation strategies they tested significantly reduced hallucination, but did not remove it.

The paper frames package hallucination as a new form of package confusion attack. The practical point is that hallucinated names are common enough that some will be worth an attacker's time.

Why coding agents make it worse

When a human reads a suggestion to add fastapi-auth-helpers to requirements.txt, there is at least a chance they pause and check whether it exists. A coding agent with shell access has no such pause unless you build one. Agentic workflows make slopsquatting more dangerous for several reasons:

Execution is automatic. The agent writes the code, runs the install, and runs the tests. A malicious install script executes before anyone reviews the diff.
The blast radius is the agent's. Install scripts run with the agent's environment: cloud credentials, repository tokens, API keys. See preventing secrets leakage from AI coding agents.
Errors trigger retries. If an import fails, an agent may try to "fix" it by installing a package with a similar name, which makes the hallucination loop worse.
CI runs unattended. Agents in build pipelines can add dependencies with no human in the loop at all. The controls for that case are in securing AI agents in CI/CD pipelines.

Slopsquatting vs typosquatting vs dependency confusion

Attack	What the attacker exploits	Example source of the bad name
Typosquatting	Human typing mistakes	`reqeusts` instead of `requests`
Dependency confusion	Resolver preferring a public package over a private one with the same name	An internal package name leaked in a manifest
Slopsquatting	LLMs inventing package names that do not exist	A plausible name the model suggests repeatedly

The defences overlap. All three are stopped by resolving dependencies only from sources you control and by reviewing every new dependency.

Defences that work

Use an allow-listed registry or proxy. Point package managers at an internal mirror or proxy that only serves approved packages. A hallucinated name that is not on the list fails to resolve, even if an attacker has registered it publicly. This is the single most effective control.

Require approval for new dependencies. Adding a dependency is a supply-chain decision. Treat a change to package.json, requirements.txt, pyproject.toml or a lockfile as a change that needs human sign-off, the same way you treat infrastructure changes. The review patterns are in code review controls for AI-generated pull requests.

Restrict the install tool. If an agent has a shell, it can install anything. Give coding agents a narrower tool for dependency changes, or a policy on shell arguments that blocks direct pip install, npm install and similar commands outside an approved list.

Verify existence and history, not just existence. Checking that a package exists is not enough, because the attacker has made it exist. Look at publication date, download history, maintainers and repository link. A package first published last week with no history, under a name your agent just suggested, is a red flag.

Disable install scripts where you can. Package managers such as npm allow install-time scripts to be turned off. That removes the most direct execution path, although import-time code still runs later.

Log every install. Record which agent installed which package and version, when, and from where. If a package is later found to be malicious, you need to find every environment that pulled it.

If an agent already installed a suspect package

Treat it as a credential exposure, not just a bad dependency. Remove the package and pin the lockfile to a known-good state. Rotate every secret that was present in the agent's environment when the install ran, because install scripts commonly read environment variables and config files. Then use your install logs to find every other environment, branch and build that pulled the same name and version, and check outbound network logs from those hosts for the install window. Finally, report the package to the registry so it can be taken down for others.

Checklist: slopsquatting controls for coding agents

Package managers resolve only through an internal proxy or allow-list.
New dependencies in manifests or lockfiles require human approval.
Agents cannot run arbitrary package-install commands through a general shell.
New or unfamiliar packages are checked for age, maintainers and history before approval.
Install scripts are disabled where the ecosystem supports it.
Agent environments hold short-lived, scoped credentials, not long-lived secrets.
Every agent-initiated install is logged with agent identity, package, version and source.

How Praesidia helps

Praesidia does not run a package registry or scan packages. It governs the agent actions that lead to an install. Discover: the agent inventory shows which coding agents exist and which MCP servers and tools they can reach. Secure: each tool call is checked against the agent's permitted tools and argument policies before it is forwarded, so you can deny direct install commands. Human-in-the-loop approvals can gate dependency changes, and tool-level rate limits cap runaway retry loops. Prove: calls that pass through Praesidia, permitted or denied, are recorded with arguments, outcome and the policy decision in a tamper-evident audit trail. If a package turns out to be malicious, you can find which agent installed it and when.

For the wider control set, read securing AI coding agents and the AI agent security guide.