Verify AI-suggested packages before installing them

Package hallucination is a documented failure mode. Spracklen and colleagues studied 16 code-generating models using Python and JavaScript prompts and reported 205,474 unique hallucinated package names across their experiment. That USENIX Security 2025 result establishes a risk in the tested setting; it is not a current failure rate for every coding agent. ^[1]

Treat a dependency suggested by an agent as an unverified proposal. Before installation, establish the exact package and version, confirm that it belongs to the intended project, and decide whether its code and installation behavior are acceptable. A successful registry lookup answers only the first of those questions.

The defensive habit is useful even when the proposed name exists. Someone can publish an unrelated or malicious package under a plausible name. Existence, identity, and suitability need separate evidence.

Stop at the first new dependency

Consider a hypothetical CSV-import feature. An agent proposes a new parser and adds an import, a manifest entry, and a lockfile change. The code looks reasonable, but the project already has a maintained CSV parser with the required quoting behavior.

The first question is whether another dependency is necessary. Ask the agent to identify the capability missing from the existing package and cite the proposed package’s actual documentation. A short answer may eliminate the dependency entirely. If a new package is warranted, review it before the install becomes part of a routine command chain.

Our proposed repository rule is that a new external dependency needs an explicit identity record: ecosystem, exact registry name, selected version, canonical project, reason for addition, and expected installation behavior. This is an editorial workflow recommendation, not a built-in guarantee supplied by an AI instruction file.

OWASP’s secure-coding guidance specifically advises checking AI-generated dependency suggestions rather than blindly running package-manager installation commands. It also recommends dependency auditing and normal version-management practices. ^[2]

Ask five different questions

The table is a proposed review sequence. Download counts and repository stars can provide context, but neither answers these questions by itself. A newly published package may be legitimate; a familiar package can still ship a compromised release.

Keep the same distinctions when assessing validation tools. In an April Reddit post, tool maker edmillss promotes a registry checker; replies challenge the headline’s use of an older aggregate hallucination statistic as a current ChatGPT rate. The discussion supplies neither an independently verified bad-install incident nor a validation result for the tool. Its headline is not a dependency-risk estimate for your project. ^[3]

Check ecosystem details carefully. A Python import name need not match its distribution name; the Python Packaging User Guide explicitly warns against blindly installing a similarly named distribution. ^[4] Do not “repair” a failed lookup by installing the nearest spelling without verifying the upstream documentation.

Inspect metadata before executing package code

For npm, npm view retrieves package information. After replacing the placeholder with the independently verified name and version, a metadata query can expose useful review fields without installing that package: ^[5]

npm view 'PACKAGE@VERSION' name version repository.url maintainers dist.integrity scripts --json

This is an inspection template, not an instruction to install an unknown dependency. Registry metadata is publisher-supplied information. Follow the project’s canonical documentation back to the package and compare identities; a convincing repository URL in one metadata field is not sufficient authentication.

Inspect the resulting manifest and lockfile diff as well. A single direct dependency may introduce many transitive dependencies or change a registry origin. Keep those changes inside the review boundary rather than approving only the new import line.

For Python, distinguish a wheel from a source distribution. pip’s secure-install documentation explains that installation can involve running code from distributions and recommends hash-checking mode together with --only-binary :all: when that restriction fits the project. Refusing source distributions can also make installation fail when no compatible wheel exists; that is a constraint to resolve deliberately. ^[6]

Know what provenance and hashes establish

npm provenance exposes information such as the source commit, build workflow, and publishing context. The documented npm audit signatures command verifies registry signatures and provenance attestations for installed dependencies; npm lists installation as a prerequisite. It is therefore not a substitute for deciding whether to perform the first install. ^[7]

A valid statement about where an artifact came from is valuable. It does not establish that the publisher’s source code is safe or that the package implements the promised parser behavior. Treat provenance as one link in the identity chain, then review the code and dependency’s role separately.

Hashes address another question: whether the bytes match an approved artifact. pip’s hash-checking mode requires pinned requirements and hashes for dependencies as well as top-level packages. A hash copied from an unreviewed artifact faithfully identifies that same unreviewed artifact; it does not confer trust. ^[6]

Keep the approved version and integrity information in the normal dependency-management record. An agent should not replace them casually because a newer release makes its generated code easier to run.

Constrain installation, then test the actual capability

Perform the first approved install in a disposable environment without production credentials. For npm, --ignore-scripts prevents package scripts from running during operations that respect that setting. Commands explicitly intended to run a script, including npm test and npm run, still run the requested script. The setting is not a general execution sandbox. ^[8]

Some packages require installation scripts to build native components. Do not turn all scripts back on merely to clear an error. Identify the required script and review the narrower exception supported by the package manager and version your project actually uses.

Our analysis of changing an agent’s execution boundary^[9] covers why an enabled control and a verified restriction are different observations.

Likewise, wheels can contain code that executes when imported. Avoid interpreting “no source build” as “no executable risk.” Keep credential and network exposure proportionate to the reviewed dependency while exercising it.

For the CSV example, now test the exact features that justified the addition: quoted separators, embedded line breaks, encoding rules, malformed input, and resource limits appropriate to the application. These proposed acceptance cases establish suitability for this feature; they do not replace dependency security checks.

If the package’s identity cannot be established, stop the addition and use an already trusted dependency or a smaller implementation you can inspect. The useful deliverable from the agent is a working feature with an explainable dependency change—not a successful install command.