Vetting an AI-suggested npm package before you install it

The risk lands before launch, on your own machine

The question worth answering before you type install is whether an AI-suggested npm package is safe to add at all. This risk is different from most launch risks in these notes: it does not wait for your production URL. It fires the moment you run the install command, on your laptop or your CI runner, often before a single line of your code uses the package.

An AI assistant suggests a package name in the same calm tone whether the name is correct, slightly misspelled, abandoned years ago, or invented on the spot. The model is predicting plausible text, not checking the registry. When the name is wrong but close to a real one, that gap is exactly what supply-chain attackers target.

Separate what is observable from what is only possible. Observable, right now: you can read the package name, its weekly download count, its last publish date, its linked repository, and whether it declares an install or postinstall script. Only possible, and not provable from the listing alone: that a given package is actively malicious. The point of vetting is to turn a confident suggestion into a few facts you checked yourself.

• An npm install can run an arbitrary install or postinstall script as your user, with your environment variables and your network access.
• That script runs before your app does, so "I haven't imported it yet" is not protection.
• This maps to the supply-chain dependency class in OWASP and the CWE family around untrusted dependencies. It is taxonomy for what to watch, not proof any one package is compromised.

Why AI-built apps walk into this

AI coding tools optimize for a working answer fast. When the model needs a date library, an auth helper, or a CSV parser, it writes an install line and an import with a name that looks right. Two failure modes follow from that.

The first is the wrong-but-plausible name. The model misremembers the package as a near-neighbor of the real one, a classic typosquat target. Attackers pre-register these look-alike names precisely because both humans and models reach for them.

The second is newer and specific to AI workflows: the model invents a package name that does not exist, a hallucination. Researchers have shown that assistants repeat the same made-up names consistently across prompts. An attacker who watches for those recurring hallucinated names can register the empty name and ship code into everyone who trusts the suggestion. This pattern is often called slopsquatting, and it only works because the suggestion sounds authoritative.

• Speed hides the missing step: there is no pause where someone confirms the name maps to the package they think it does.
• The model gives no signal of confidence. A real package and a hallucinated one are suggested identically.
• Copy-paste install lines move between projects, so one unchecked name spreads.

Vet it before you install

These are checks you run on your own terminal and browser against the package you are considering. None of them install or execute the package.

Look up the package without installing it. The command npm view your-package-name returns the registry metadata: version, last publish time, maintainers, repository link, and declared scripts. The command npm info your-package-name shows the same data. Read it before npm install ever runs.

The safe result across these checks: a name that exactly matches what you intended, download counts and a publish history consistent with a real library, a matching source repo, and no surprising install scripts. The suspicious result is any single mismatch, and several together mean stop.

• Name and downloads: open the package page on npmjs.com. A package with a few dozen weekly downloads where you expected a popular library is a suspicious result. A name one character off from a well-known package (an added letter, a dash, a swapped vowel) is a strong signal of a typosquat.
• Existence and history: if npm view returns nothing, the name does not exist on the registry. That is the hallucination case. Do not install a fix the model proposes for the missing name without re-checking it too. A package whose only version was published days ago, with no history, deserves more scrutiny than one with years of releases.
• Last publish date: an abandoned package (no release in a long time) is not malicious by itself, but it means no one is patching it. Weigh that against how central it will be.
• Linked repository: confirm the npmjs page links to a real source repo, and that the repo's star count and activity match the download numbers. A popular package with no source repo, or a repo that does not match the name, is a suspicious result.
• Install and postinstall scripts: npm view your-package-name scripts shows declared scripts. A small utility that declares a postinstall step is worth reading before you let it run. You can also install with the flag npm install --ignore-scripts to block lifecycle scripts during a first look, then inspect the package folder under node_modules before doing anything else.

Reduce the exposure, and what this does not cover

A few controls cut the blast radius without slowing normal work much.

Be clear about the limits. None of this proves a package is safe. Download counts can be inflated, a repo can look healthy and still ship a malicious version, and a clean npm audit only reflects known and reported advisories, not a fresh compromise or a deliberately hidden backdoor. Vetting lowers the odds of installing an obvious typosquat or hallucinated name. It is not a code audit of the dependency. For a package that will handle secrets, auth, or payments, reading the actual source is the only real assurance, and that is manual work.

• Pin and lock. Commit your lockfile so the exact resolved versions you vetted are what installs everywhere, including CI and production. A missing lockfile lets installs drift to a version you never checked; that gap is its own launch risk covered in the note on missing lockfiles and dependency drift.
• Disable scripts by default where you can. Running installs with scripts ignored, then enabling only the ones you trust, removes the most direct path from install to code execution.
• Prefer well-known, actively maintained packages over the first plausible name. If two packages do the same job, the one with a long history and a matching repo is the lower-risk pick.
• Audit known issues. After installing, npm audit reports advisories against your dependency tree. This is a separate, post-install step; for using it as a pre-launch gate, see the note on running npm audit before launch.

Where VibeCodeGuard fits, and what it does not prove

Be direct: this is not the job VibeCodeGuard does. Package vetting is a pre-install, repository-level step that happens on your machine before anything deploys. VibeCodeGuard's Launch Check inspects the deployed public surface of your live app, such as security headers, exposed deployment artifacts, source maps, and secret-shaped strings in the client bundle. It does not read your package.json, run your install, or judge whether a suggested dependency is a typosquat.

So for the question this note answers, the right tools are the local ones above: npm view, the npmjs package page, the source repo, your lockfile, and a careful read of install scripts. Use them before you install. VibeCodeGuard comes in later, once the app is built and you are about to share the URL, to check what an outside visitor can actually reach.

Next step: take the last package an AI assistant suggested to you, run npm view on its exact name, and confirm the name, the publish history, and the source repo all line up before it goes into your tree.