How to Check AI-Suggested Packages Before You Install

To check AI-suggested packages before you install them, confirm the exact name exists and belongs to the project you meant, then read its age, repository and install scripts. Install with scripts disabled until you've decided. Then make every new dependency a reviewed change in the pull request, not something an AI coding tool adds on its own.

Cursor, Claude Code, Lovable, Bolt and Replit add dependencies as readily as they write functions, and a suggested import can be wrong in ways that still compile.

Why AI-suggested packages need their own check

Models suggest packages from patterns in their training data, and that goes wrong in distinct ways:

• The package doesn't exist. The name sounds plausible, the install fails, and someone tries a variant.
• Someone registered the invented name. OWASP's LLM09:2025 Misinformation entry describes the attack: attackers find package names that coding assistants commonly hallucinate, publish malicious packages under them and wait for developers to install them.
• The name is close to a real one. A swapped letter, an extra hyphen or a missing @org/ scope can point to a typosquat.
• The package is real but stale: deprecated, renamed, or an old major version with known vulnerabilities.
• The agent installs it itself, running npm install in the middle of a task before anyone reads the diff.

That last case raises the stakes. By default, npm runs a dependency's preinstall, install and postinstall scripts during installation, as the developer, with access to .env files, cloud credentials and SSH keys on that machine. That is why dependencies appear among the security mistakes in apps built with AI tools: a bad one can do damage before it ships.

How to check AI-suggested packages in five minutes

Run through these steps before you accept a new dependency. The commands use npm; PyPI, crates.io and other registries show the same information on each project page.

1. Confirm the exact name exists. npm view <name> returns a 404 for a package that doesn't exist. Treat that as a stop. Trying spelling variants until one resolves is how people install a squatted name.
2. Confirm it's the project you meant. Find the library's official documentation yourself, not through the AI tool, and check that its install instructions use the same name and scope.
3. Read the age and history. A package created recently, with one or two versions, standing in for a common need deserves suspicion.
4. Follow the repository link. It should lead to a real repository with matching code and a visible history.
5. Look for install scripts. Any preinstall, install or postinstall script executes code on install. Read it before you allow it.
6. Ask whether you need it. A short helper in your own codebase is often easier to own than a new package and its dependency tree.

One command covers most of the registry checks. Replace some-package with the suggested name:

npm view some-package time.created time.modified repository.url scripts --json

Registry signals and what they tell you

No single signal proves a package is safe. Read them together:

High download counts say little about a brand-new version. If a maintainer account of a well-known package is compromised, the malicious release carries the package's full reputation.

For installed packages, npm audit signatures verifies registry signatures and provenance attestations, as the npm audit documentation describes. Provenance links a version to the repository and build that published it, so a package that suddenly stops publishing with it is worth a look.

Stop install scripts from running before you decide

When you're evaluating a candidate, install it with scripts disabled:

npm install some-package --ignore-scripts

This also skips your own project's pre- and post-scripts for that command, so use it for evaluation only.

The lasting fix is a package manager policy. pnpm's supply chain security guide documents two controls: dependency build scripts don't run unless the package is approved in allowBuilds, and minimumReleaseAge delays installing newly published versions. Current pnpm versions enable both by default. Setting them explicitly documents the policy and survives a default change:

# pnpm-workspace.yaml
minimumReleaseAge: 1440   # minutes; skip versions newer than one day
strictDepBuilds: true     # fail the install on unreviewed build scripts
allowBuilds:
  esbuild: true           # example: a reviewed package that needs its build step

Setting names have changed between pnpm major versions, so check the docs for your version. Recent npm releases document comparable controls, min-release-age and an allowScripts field in package.json.

A release-age delay protects against a compromised new version of a real package. It does nothing against a hallucinated name registered months ago.

When the AI coding agent installs packages itself

Agents that run commands need limits that don't depend on the model getting it right.

• In AGENTS.md, CLAUDE.md or .cursor/rules/, tell the tool to ask before adding a dependency and to link the official docs. Rules files steer the tool; they don't enforce anything.
• If your agent can run terminal commands without confirmation, keep npm install, pnpm add, pip install and their equivalents off the auto-approve list.
• Run agents in a dev container or cloud workspace without production credentials, long-lived cloud keys or personal SSH keys, so an install script finds little.
• Watch for the retry loop. After a 404, an agent may try alternative names until one installs. A 404 should end the attempt.

Catch new dependencies in the pull request

Local checks depend on each developer. Every change passes through the merge, so enforce the rules there.

1. Route package.json and lockfiles to a code owner, as in our guide to reviewing AI-generated code before you merge.
2. Turn on dependency review in CI. GitHub's dependency review shows which dependencies a pull request adds, removes or updates, with release dates and known vulnerabilities, and its action can fail the check.
3. Install from the lockfile in CI with npm ci or pnpm install --frozen-lockfile, then run npm audit signatures.
4. Compare the lockfile diff with the package.json diff. One added package that pulls in a long list of transitive packages needs a second look.

Common mistakes when vetting AI-suggested packages

• Trusting the README, which a malicious package can copy from the one it imitates.
• Checking the package but not the version. The version pinned in the lockfile is the one that runs.
• Installing to "just try it" on a laptop that holds production credentials.
• Asking the same AI tool whether its suggestion is safe, and accepting the answer.
• Running npm audit and stopping there. A newly registered malicious package usually has no advisory yet.

What to do if you installed a package you shouldn't have

1. Remove the package and record the exact version and when it was installed.
2. Read its install script, if it had one. If the script ran, treat the machine as exposed.
3. Rotate every credential that machine or CI runner could reach: .env values, cloud keys, registry and GitHub tokens, SSH keys.
4. Check whether the package reached the main branch, a build or a deployment, and review those environments if it did.
5. Report the package to the registry.

If nobody has reviewed what an AI-built app already depends on, our security audit for AI-built apps is a fixed-scope review covering dependencies alongside secrets, access control and LLM features, with a written report and a prioritized fix list. To check on your own first, use our security checklist for AI-built apps.

Frequently asked questions

What is slopsquatting?

Slopsquatting is registering package names that AI models tend to invent, so anyone who follows the suggestion installs the attacker's code. It works like typosquatting, but relies on model mistakes instead of typing mistakes.

Does npm audit catch malicious packages?

Only after the package has been reported and an advisory published. npm audit compares installed versions against known advisories, so a package registered last week for an attack usually passes.

Is it safe to let an AI coding agent run npm install?

It's safer when each install needs your approval and the agent runs without production credentials. With install scripts blocked and a release-age delay, a bad suggestion has little to reach before review.

Should we only allow packages from an approved list?

For larger teams or regulated products, an internal registry proxy with an allowlist gives one point of control and an audit trail. For a small team, code-owner review of lockfile changes plus the install settings above covers most of the same risk.