Slopsquatting is the registration of package names that AI coding tools tend to invent, so that anyone who installs the suggestion gets the registrant's code. Mitigate it at four points: where packages come from, how new names are reviewed, what agents may install, and which names you reserve yourself.
How is this different from the hallucination itself?
The model's mistake is the cause. The attack is what happens next. OWASP's guidance on misinformation in LLM applications lists suggesting non-existent code libraries as an example of unsafe code generation, and says unverified trust in outputs magnifies the harm. You cannot fix the model's behaviour from the outside. You can make the consequence harmless.
That framing sets the strategy. Assume the assistant will sometimes name a package that is not real, and build so that following the suggestion does nothing dangerous.
Control 1: control the source
Developers and CI should install from an internal registry or proxy, not directly from the public index. The proxy serves approved packages, and anything new triggers a review request instead of a silent fetch. This single control turns most slopsquatting attempts into a blocked request that a person sees.
Use lockfiles with integrity hashes, and fail the build if a manifest changes without the lockfile changing.
Control 2: review new names
A new dependency is a decision. Require the pull request to state why it is needed and link the registry page. Reviewers check age, maintainer history, source repository, release count and whether a similar approved package already exists. Automate the signals: flag packages younger than a set age, with no source link, or whose names are close to an existing dependency.
NIST's SSDF, SP 800-218, includes practices on reviewing and verifying third-party components before use, which is the formal home for this step.
Control 3: constrain agents
An agent that installs packages while it works is the fastest path from a hallucination to code execution. Options include denying network installs from agent sessions, allowing only packages already on the approved list, running agents in a sandbox without secrets, and disabling install scripts by default. Any exception should need a human click.
Log every package an agent adds, with the prompt that led to it.
Control 4: reserve your own names
If you have internal packages, publish placeholders for those names on public registries, or configure the package manager to resolve internal scopes only from your registry. That prevents confusion attacks, where a public package with the same name wins.
A constructed example
A team's assistant suggests pip install fastjson-validate for a task. In an unprotected setup, the developer runs it. In the protected setup, the request goes to the internal proxy, which has no such package approved, so the install fails with a message pointing to the review form. A reviewer sees the registry page was created three days ago with no source link, and the team uses the standard library instead. Total cost: five minutes, and no code ran.
How to check or apply this
- Route all package installs through an internal proxy and block direct public index access from CI.
- Commit lockfiles with hashes and enforce that they match manifests.
- Add a pull request check that flags new dependencies and shows age, source and maintainers.
- Maintain an approved list for common needs so that approval is fast.
- Block or sandbox package installation by autonomous agents, and disable install scripts where possible.
- Reserve internal package names on public registries and scope internal packages explicitly.
- Monitor for newly published packages whose names match suggestions you see in your own logs.
- Train developers: a name from an assistant is a lead to check, not a fact.
Where do tools help?
Scanning the dependency graph on each change catches new, unknown or flagged packages before merge, and policy gates can block them until reviewed. Safeguard provides dependency scanning with policies and gates, plus a free scan at gold.safeguard.sh/scan for up to 100 dependencies.
Quick check
Does using only well-known packages avoid the risk?
It lowers it, but a hallucinated name can look close to a well-known one. Verify the exact name against the registry and your approved list.
Is blocking install scripts enough?
No. A malicious package can run code when it is imported. Blocking scripts reduces one path, while review and the proxy stop the package from arriving.
Sources
Last reviewed: 18 October 2026.
