How to check an AI-suggested package before you install it

Before installing a package an AI assistant suggested, confirm it exists on the registry, check who publishes it and when it was first released, read its install scripts, and compare the name against what you meant. Two minutes of checking costs far less than cleaning up a malicious install.

Why this check exists

Code generation models sometimes name packages that do not exist. A study of 16 code generation models and 576,000 code samples reported average hallucinated package rates of at least 5.2% for commercial models and 21.7% for open source models, with 205,474 unique invented names. If an attacker registers one of those names, your install command pulls their code.

The risk is not limited to invented names. An assistant can also pick a real but abandoned package, or a lookalike of the one you wanted.

The six steps

1. Confirm the name on the registry itself. Search the registry website, not the assistant. If the name does not resolve, stop. A missing package is the clean failure; a freshly registered one is the dangerous case.
2. Check the first release date. A package that first appeared days ago and matches a name the assistant just invented deserves suspicion.
3. Look at the publisher. Does the maintainer have other packages and a history? Does the listed repository exist and actually contain this code?
4. Read the manifest. Look for install time scripts. npm documents that preinstall, install and postinstall scripts run during npm install, so a package can execute code the moment you add it.
5. Compare against the name you meant. Typos and near matches are common. Read the name character by character.
6. Prefer what you already use. If the project already depends on a library that does the job, use it. The best new dependency is often no new dependency.

Provenance helps but does not decide

npm provenance links a published package to its source and build instructions, and npm audit signatures reports verified signatures and attestations. The npm documentation is direct about the limit: provenance does not guarantee the package has no malicious code. Treat it as a useful signal, not a verdict.

Make it a habit, then a gate

Individual vigilance fades. Put the checks where they cannot be skipped: a dependency review step on pull requests, a lockfile committed to the repository, and a rule that new packages need a human reviewer to approve them by name.

If you want a quick look at what a project already pulls in, you can run the free scan at gold.safeguard.sh/scan. Safeguard's SBOM and dependency scanning, plus policies and gates, can enforce the same rules on every pull request.

Quick check

Sources

• We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (arXiv)
• npm documentation: scripts
• npm documentation: generating provenance statements

Last reviewed: 19 October 2026.