Catching AI-Hallucinated Package Names Before npm install

A plausible name is not a real package

Ask an LLM for a library to solve a specific problem and it will sometimes invent one -- a name that sounds exactly like something that should exist, built from the same naming patterns real packages use, because the model is predicting a plausible next token, not looking anything up. This is well-documented enough to have a name: slopsquatting. Attackers register the invented names on public registries and wait for someone to npm install or pip install them straight out of an agent's suggestion.

The check that takes less time than the install

Before installing anything a model suggested that you haven't personally used before: open the registry page for it. npmjs.com/package/<name> or pypi.org/project/<name>/. Look at three things -- publish date, download count, and whether the README reads like it belongs to a real, maintained project or like it was thrown together to look legitimate. A package with a two-week-old first release and near-zero downloads, suggested by name with total confidence, is exactly the shape of a hallucinated dependency that got squatted.

Why "it installed fine" proves nothing

A malicious package installing without error tells you nothing -- that's the whole point of a supply-chain attack. The payload runs from a postinstall script or on first import, not at the moment npm install prints a green checkmark. The registry check has to happen before the install, not as a reaction to how it went.

Make it a gate, not a habit you'll forget

A habit you have to remember every time is a habit that lapses under deadline pressure. Where it's practical, put an allowlist or a minimum-download-count check in CI for any new dependency added to a lockfile, so a hallucinated package name gets caught by a machine instead of by whoever happens to remember to look.