How to Stop AI Package Hallucinations Before Production

AI package hallucination prevention sounds like a niche supply-chain chore until you remember how modern software gets written: a coding assistant suggests an import, a developer trusts the vibes, and pip install or npm install does the rest. That workflow is wonderfully fast. It is also how a fake package name can become a real production dependency before lunch.

The uncomfortable 2026 update: better models did not erase the problem. A June 11 revision of the arXiv paper “The Range Shrinks, the Threat Remains” tested Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, and DeepSeek V3.2 across 199,845 paired Python and JavaScript prompts. The measured hallucination rates compressed to 4.62%–6.10%, which is progress. It is not victory confetti.

The same study found 127 package names invented identically by all five models. After coordinated disclosure, 53 remained registrable by attackers: 41 on PyPI and 12 on npm. That is the awkward part. Frontier models are becoming more consistent, and consistency is useful to attackers when five systems hallucinate the same plausible dependency name.

This tutorial gives you the practical guardrails: a dependency intake rule, Python and JavaScript verification commands, CI gates, and a prompt pattern that keeps AI-generated package suggestions in the draft lane where they belong.

Why package hallucination is still alive

Package hallucination is simple: an LLM suggests a package that sounds real but does not exist in the registry. Slopsquatting is the attack that follows: someone registers that invented name with malicious code and waits for developers, or their AI assistants, to install it.

The original Spracklen et al. study, published for USENIX Security 2025 and available on arXiv, generated 576,000 code samples and found hallucinated-package rates of at least 5.2% for commercial models and 21.7% for open-source models. The 2026 replication is better news, but only in the way a smaller hole in the boat is better news.

The risk is not that every AI-generated dependency is malicious. The risk is that dependency creation has become too casual. For adjacent AI coding-agent context, see our SWE-CI benchmark coverage. Dependency files are just another place where a confident suggestion needs boring verification.

The AI package hallucination prevention rule

Use one rule: never install an AI-suggested package directly from the chat window or generated diff. Treat it as a candidate, not a dependency.

Before a package enters requirements.txt, pyproject.toml, package.json, or a lockfile, verify four things:

• Existence: Does the package exist on the registry under the exact suggested name?
• Ownership: Is the maintainer, organization, repository, or publisher plausible?
• History: Does it have releases, download history, docs, issues, or normal project metadata?
• Intent: Does the package actually solve the problem, or did the model invent a name that sounds like the problem?

That last check matters. A package can be real and still be the wrong package. AI tools are excellent at producing plausible dependency diffs. They are less excellent at knowing your threat model.

Python workflow: verify, pin, hash

For Python, start with registry verification before installation. This is the boring checkpoint that prevents the most theatrical failure mode.

# 1. Verify the exact package name exists.
python -m pip index versions suspicious-package-name

# 2. Generate an install report without changing the environment.
python -m pip install --dry-run --report /tmp/pip-report.json suspicious-package-name==1.2.3
python -m json.tool /tmp/pip-report.json

# 3. Install only after review, pinned to the selected version.
python -m pip install suspicious-package-name==1.2.3

For deployable environments, go stricter. The official pip docs on secure installs recommend two controls: enable hash-checking mode with --require-hashes, and disallow source distributions with --only-binary :all:. Hash-checking is intentionally annoying: every requirement and every transitive dependency must be pinned and hashed. That is the point.

# requirements.txt
requests==2.32.4 \
  --hash=sha256:<actual-hash-from-pip-hash>

# CI or production install
python -m pip install --require-hashes --only-binary :all: -r requirements.txt

Do not pretend this belongs in every notebook. It belongs in production builds, release branches, and any service where an AI-generated dependency diff could become part of the shipped artifact. For app teams, this is the difference between “the assistant suggested it” and “we can reproduce exactly what we installed.”

JavaScript workflow: freeze the tree first

JavaScript has a different failure mode: install scripts. A fake npm package does not need to wait for your app to import it. It can run code during installation if lifecycle scripts are enabled.

Start by inspecting the package before adding it:

# Check the registry record before install.
npm view suspicious-package-name name version time repository maintainers dist-tags --json

# If you need a sandbox install, disable lifecycle scripts first.
npm install suspicious-package-name --ignore-scripts --package-lock-only

# Rebuild from the lockfile in CI.
npm ci

The npm ci command is built for automated environments. It requires an existing lockfile, fails when package.json and the lockfile disagree, removes node_modules, and does not write to package files. Translation: it makes dependency drift visible instead of silently helpful.

Then add signature checks. The npm docs say npm audit signatures verifies registry signatures and provenance attestations for downloaded packages. Provenance is not a magic morality detector; the npm provenance docs are careful about that. It links a package to source and build instructions. That is still useful friction when an AI assistant invents a suspiciously perfect package name.

npm ci --ignore-scripts
npm audit --audit-level=moderate
npm audit signatures

If a package genuinely needs postinstall scripts, review them explicitly. The default should be skepticism, not panic. Panic makes bad security policy. Skepticism catches typos, abandoned packages, and freshly registered nonsense before they get a badge and a build cache.

Put the checks in CI

Manual discipline is a wonderful fantasy. CI is where this becomes real.

Add two gates. First, scan dependencies with OSV-Scanner, which is an officially supported frontend for the OSV vulnerability database and can run in a terminal or CI/CD pipeline. Second, use GitHub Dependency Review so pull requests show added, removed, and updated packages with vulnerability and release data.

# Local or CI scan from the repository root.
osv-scanner scan -r .

# Lockfile-focused scan.
osv-scanner scan -L package-lock.json --format json

Your policy can stay simple:

• Any new direct dependency needs human review.
• Any package created recently needs extra scrutiny.
• Any dependency added by an AI-generated diff gets labeled as such in the PR.
• Any install script runs only after a reviewer reads it.

This is the same lesson from the Amazon Kiro senior sign-off story: the control point belongs at the moment an automated system can change real infrastructure. Dependencies are infrastructure. They just arrive wearing friendlier file extensions.

Use a safer prompt pattern

Prompts cannot replace verification, but they can reduce junk before it reaches the diff. Use this when asking an AI coding assistant to add a library:

You may suggest dependencies, but only if they exist on PyPI or npm.
For each dependency, include:
1. Exact package name
2. Registry URL
3. Current stable version
4. Why this package is needed
5. A no-new-dependency alternative

Do not edit dependency files until I approve the package list.

The “no-new-dependency alternative” line is the sleeper hit. Many AI assistants reach for a package because package-shaped answers look complete. Sometimes the right answer is 14 lines of standard library code and one fewer supply-chain liability.

This also helps when comparing coding tools. Our Cursor, Windsurf, Claude Code, and Codex workflow guide is useful background for teams deciding where AI coding assistants belong. The dependency rule here is narrower: keep review gates where the risk actually lives.

The checklist

If you remember nothing else, keep this checklist next to your AI coding setup:

• Never install an AI-suggested package directly.
• Verify the exact package name on the registry.
• Check ownership, release history, repository, and documentation.
• Install in a sandbox first, with lifecycle scripts disabled where possible.
• Use frozen lockfiles in CI: npm ci for JavaScript, pinned hashed requirements for Python production builds.
• Run vulnerability and dependency-review checks before merge.
• Require human approval for every new direct dependency.

The 2026 model cohort is better. Good. Take the win. But the paper’s headline is exactly right: the range shrank, the threat remains. AI package hallucination prevention is not about distrusting AI coding assistants. It is about refusing to let the package manager become the place where everyone stops checking.