Slopsquatting is when an attacker registers a package name that an AI coding assistant tends to invent, then waits for developers to install it. You block it by refusing unknown dependencies by default: verify a package exists and has history, route new names through review, and install only from a controlled registry.
How big is the problem?
A research paper, We Have a Package for You, tested 16 popular code generating models with two prompt datasets and 576,000 code samples in two programming languages. It found 205,474 unique hallucinated package names. Hallucinated packages averaged at least 5.2% for commercial models and 21.7% for open source models. The paper is slated for USENIX Security 2025, and the authors report mitigation strategies that cut hallucinations while keeping code quality.
Those numbers come from a controlled study, not from your assistant on your codebase. Treat them as proof the behavior is real and measurable, not as a forecast of your own rate.
MITRE ATLAS names the attack pattern Publish Hallucinated Entities (AML.T0060): an adversary creates an entity they control, such as a software package, website or email address, at a source an LLM hallucinated. The attack can proceed when the victim interacts with it. That entry covers package names, commands, URLs, company names and email addresses, per the ATLAS data.
Mistake 1: Trusting the install command in a chat answer
The assistant writes an install line, the developer pastes it, done. Nothing in that flow asks whether the name is real. The fix is a step between suggestion and install.
Mistake 2: Checking only that the name resolves
If an attacker already registered the name, it resolves fine. Existence is the weakest check. Look at age, publisher, release history, linked repository and download pattern. A package published last week with one version and no repository link deserves a human look.
Mistake 3: Letting developer machines talk to the public registry directly
When every laptop and CI job installs straight from the public index, every hallucinated name becomes a live risk. Route installs through a proxy or internal mirror that holds only approved packages. A new name then fails loudly instead of silently succeeding.
Mistake 4: No review gate on dependency file changes
Treat a change to a manifest or lockfile like a change to code. Require a second person to approve additions. Make the pull request show new packages in a clear list, with age and publisher beside each name.
Mistake 5: Relying on a scanner for known vulnerabilities
A typical scanner matches packages against advisories. A freshly registered malicious package has no advisory yet. Scanning is needed, but it will not catch this alone. OWASP's LLM supply chain guidance recommends vetting suppliers, keeping an up to date and signed inventory of components, and using integrity checks with signing and file hashes. See LLM03 Supply Chain. Note that the page does not discuss hallucinated packages specifically, so the match is to the general control set.
Mistake 6: Giving agents permission to install
An autonomous coding agent that can run an install command has made the decision for you. Limit agent permissions so that adding a dependency needs approval, and run agent shells without secrets in the environment so a bad install finds nothing to steal.
Mistake 7: Never testing your own assistant
You can measure the behavior yourself. Ask your assistant to write code for ten niche tasks and collect every package it names. Check each against the registry and against your allow list. Count how many do not exist. That number tells you how much the control matters in your setup. Do not publish or register any invented name, since that is the attacker's move. Just record it.
What a layered block looks like
- At suggestion time: an IDE or MCP check that looks up a package before the assistant proposes it.
- At commit time: a pull request check that flags new packages with age and publisher.
- At install time: a registry proxy that serves only approved names.
- At runtime: an inventory so you can find and remove a bad package fast.
Safeguard's free in-browser scan at gold.safeguard.sh/scan can check a dependency list of up to 100 packages, which is a quick way to review what a project already pulls in. The MCP server at mcp.safeguard.sh works with Claude, ChatGPT, Cursor or your own agent, with unlimited tool calls on every plan.
What to do
- Run the ten task test on your assistant and record names that do not exist.
- Move installs behind an internal mirror or proxy with an allow list.
- Require review for every manifest and lockfile change.
- Show age, publisher and repository link for new packages in the pull request.
- Remove install permission from autonomous agents unless a human approves.
- Keep a current inventory of every package in every service.
- Rerun the test when you change models or assistants.
Quick check
Does a package that exists on the registry count as safe?
No. An attacker may have registered it. Check age, publisher, release history and linked source before you trust it.
Can better prompts stop hallucinated packages?
They may reduce them, and the study above reports mitigations that helped, but you still need a technical gate before install.
Sources
- We Have a Package for You, arXiv 2406.10279
- MITRE ATLAS data, technique AML.T0060
- OWASP LLM03 Supply Chain
Last reviewed: 18 October 2026.
