Short answer
AI coding models regularly invent functions, parameters and whole packages. In a USENIX Security 2025 study of 576,000 samples, 19.7% of recommended packages did not exist. Invented APIs are usually caught by the compiler; invented packages are a supply-chain risk called slopsquatting, stopped by dependency allowlists and sandboxed installs.
The agent’s code looks fine. It calls client.fetch_all(paginate=True), imports a helper package with a sensible name, and the explanation is confident. Then the build fails because fetch_all has never existed. Or worse, the build passes, because someone has registered that sensible-sounding package name on PyPI and filled it with something you didn’t ask for.
Both are hallucinations. They come from the same habit of the model, but they end very differently. One wastes ten minutes. The other is a supply-chain attack waiting for a victim.
What an AI code hallucination looks like
A code model writes the most plausible continuation of what it has seen. Usually that matches a real API. Sometimes it matches the shape of an API that ought to exist. The common forms:
- A method that sounds right but isn’t there, often borrowed from a sibling library or an older version.
- A real method with an invented parameter, like a
timeoutargument a function never took. - A configuration key or CLI flag that a similar tool uses.
- A package name assembled from plausible parts: the right vendor, the right noun, the wrong combination.
- A real package from the wrong ecosystem, such as a JavaScript package name suggested for a Python import.
One well-documented case: models repeatedly told people to run pip install huggingface-cli. The real command-line tool comes from a differently named package, installed with an extra. Security researcher Bar Lanyado published a harmless, empty package under the hallucinated name in January 2024 and saw about 30,000 downloads over the following three months.
Nothing malicious happened in that case, because the person who claimed the name was a researcher. That is the point of the experiment. The name was free, and thousands of installs were waiting for whoever claimed it.
How often models invent packages
The most thorough measurement is “We Have a Package for You!” by Spracklen et al., presented at USENIX Security 2025. The authors generated 576,000 code samples in Python and JavaScript with 16 popular code models and checked every package the code referenced.
Overall, 19.7% of the packages did not exist: 440,445 hallucinated references, including 205,474 unique invented names. Commercial models averaged at least 5.2%, open-source models 21.7%.
The models are a couple of generations old now, and current frontier models will do better than GPT-4 Turbo. But even the best commercial model in the study invented a package in more than 1 in 30 references. At the volume an agent produces dependencies, that is not a rounding error.
Three other findings from the paper matter for defence:
- Hallucinations repeat. 43% of hallucinated packages came back in all ten repeated queries, and 58% came back more than once. An attacker doesn’t need to guess. They can ask the model and register what it says.
- Ecosystems leak into each other. 8.7% of hallucinated Python package names were real JavaScript packages. The name existing somewhere doesn’t make it right here.
- Temperature makes it worse. At maximum temperature, GPT-3.5’s rate rose to 31.8%.
JavaScript (21.3%) fared worse than Python (15.8%) in the study, which fits its larger and messier package namespace.
From hallucination to slopsquatting
The attack built on this has a name. Seth Larson, the Python Software Foundation’s developer-in-residence, called it slopsquatting: registering package names that AI models hallucinate, so that the next developer or agent who trusts the suggestion installs the attacker’s code.
It differs from typosquatting in one useful way for the attacker. Typosquatting waits for a human to mistype. Slopsquatting can be farmed: run popular prompts through popular models, collect the repeated invented names, register them. The repetition rate above is what makes it practical.
How a hallucinated package reaches production
- Agent
- Person
Steps as text
| Step | What happens |
|---|---|
| 1. Model suggests a name | Agent — plausible but not real |
| 2. Attacker registers it | Step — name was repeated and free |
| 3. Agent installs it | Agent — no check that it is real |
| 4. Install script runs | Step — on a machine with secrets |
| 5. Review misses it | Person — one line in a lockfile |
Agents make this worse than autocomplete did. A person copying a snippet at least sees the import. An agent with shell access can run pip install or npm install as part of fixing a failing build, and the install scripts run before anyone reads the diff. By the time a reviewer sees one new line in the lockfile, the code has already executed on the agent’s machine.
Invented APIs: annoying but usually caught
Hallucinated methods and parameters are the more common kind and the less dangerous one, provided something actually runs the code.
In a typed, compiled language, the build catches most of them immediately. In Swift, TypeScript with strict settings, Kotlin or Rust, a call to a method that doesn’t exist simply doesn’t compile. In Python or JavaScript, they surface at runtime, so they get caught only on paths that are executed. That is why the controls look different:
- Make the agent run the build and the type checker, and attach the result. An agent that says “this should work” without compiling is the source of most invented-API bugs reaching review. Evidence over claims explains how to require proof.
- Turn on strict typing where you can.
mypy --strictorpyrightin Python,strictin TypeScript. Every invented attribute becomes a build failure instead of a runtime one. - Give the agent the real docs. The paper’s mitigation experiments showed retrieval helped: for CodeLlama, adding retrieved context cut the package hallucination rate roughly in half. Pointing an agent at the actual API reference or the installed package source works on the same principle.
- Test the paths the change touches. An invented parameter on an error path nobody exercises can sit there for months.
The interesting row is self-refinement: asking CodeLlama to re-check its own answer barely moved the rate. Some stronger models in the study did spot their own hallucinations with over 75% accuracy, but you can’t build a control on “the model will probably notice”. Checking against reality, the registry or the compiler, works better than asking the model to try harder.
How to stop hallucinated packages
The good news is that package hallucinations are easy to check mechanically. A package either exists in your approved set or it doesn’t. Here is the order I would put the controls in.
| Control | What it stops | Effort |
|---|---|---|
| Agents can’t run installs outside the sandbox | Install scripts executing on a machine with secrets | Low |
| Install from the lockfile only in CI | New dependencies sneaking in during a build | Low |
| New dependency check in CI: exists, minimum age, real maintainers | Freshly registered squatted names | Medium |
| Registry proxy or allowlist | Anything not approved by a person | Medium |
| A reviewer rule that every new dependency is justified | Packages added for something the standard library already does | Low |
The bad approaches are the ones that rely on attention. “Developers should double-check package names” fails because the hallucinated names look right; that’s why they were hallucinated. “Use a better model” lowers the rate but doesn’t remove it, and the rate is not zero for any model in the study.
The good approaches move the decision out of the model and out of the reviewer’s memory. A sandboxed agent can still try to install something odd, but the attempt fails at the network boundary or the allowlist. Anthropic describes the same reasoning for Claude Code’s sandbox: with both filesystem and network isolation, even a successful prompt injection stays inside the box. A hallucinated install is a milder version of the same problem, and the same box contains it. Guardrails for AI coding agents goes through how to set those boundaries.
Where this ends up
I don’t expect hallucinations to disappear. They are a side effect of how these models generate text, and rates will keep falling without reaching zero. What changes is where they get caught. In a pipeline where the agent compiles, tests, installs only through an allowlist and has its diff read by an independent reviewer, a hallucinated API costs one loop iteration and a hallucinated package costs one blocked request. Nobody has to spot it by eye.
That is the realistic goal: not a model that never invents things, but a pipeline where invented things can’t get far.
Questions
What is an example of an AI code hallucination?
A common example is a model suggesting pip install huggingface-cli, a package that did not exist at the time; the real tool is installed from a differently named package. Others include calls to methods a library never had, or invented parameters on real functions.
What is slopsquatting?
Slopsquatting is registering package names that AI models tend to hallucinate, so that developers or agents who trust the suggestion install the attacker’s code. The term was coined by Seth Larson of the Python Software Foundation.
How often do AI models hallucinate packages?
In a USENIX Security 2025 study of 576,000 samples from 16 models, 19.7% of referenced packages did not exist. Commercial models averaged at least 5.2% and open-source models 21.7%.
How do you prevent hallucinated dependencies?
Don’t let agents install packages outside a sandbox, install only from lockfiles in CI, and check every new dependency automatically against an allowlist or for age and maintainers. Relying on people to spot fake names does not work, because the names look plausible.