TL;DR
When an AI agent suggests a package, check the exact project and version before allowing installation. A familiar name, a working download or a confident explanation is not enough. Start with the project’s own installation instructions, then confirm the package in the registry your team uses. Review its origin and whether it belongs in your application. If the identity cannot be established, pause that dependency change. Keep the evidence with the proposed code so the reviewer can check the choice.
In this article
Last updated October 15, 2026
6 min read
A package check can start with the wrong name. Python code may say from PIL import Image, while the installed project is called Pillow. Searching for a package with the same spelling as an import does not establish what the code needs.
That distinction matters when a coding agent proposes a new dependency. Before asking whether a name exists, establish which project the developer intended to use and how that project documents its installation.
A real name mismatch is not a hallucination
The Python Packaging User Guide distinguishes a distribution package, which you install, from an import package, which code loads. Names often match, but the relationship is not enforced. Its Pillow/PIL example shows why blindly turning an import name into an installation command can select the wrong project.
A read-only check of the environment used for this article returned the following on 15 October 2026, using Python 3.14.2:
This result establishes the mapping in that environment. It does not assess the package’s security or tell you which package to install for every possible import. For an unfamiliar dependency, use the project’s documented installation route and your repository’s existing dependency records to establish the mapping.
If the needed capability is already present, a new dependency may be unnecessary. The companion article on checking existing components before adding AI-generated code develops that earlier decision.
What package-hallucination research actually shows
Spracklen and colleagues’ USENIX Security 2025 study evaluated 16 code-generating models using 576,000 Python and JavaScript samples. Its abstract reports average hallucinated-package percentages of at least 5.2% for commercial models and 21.7% for open-source models.
Those figures describe the evaluated models and experimental method. They are not today’s failure rate for every coding agent, and they are not the percentage of production installations that contain malware. The practical concern is that generated code can recommend a nonexistent package name. A later package published under that name still needs an identity and trust review; appearing in a registry does not establish that it is the intended dependency.
Ask separate questions about identity and suitability
Treat the agent’s recommendation as a proposal. Ask it to provide the intended project, exact registry name and version, the documentation that connects those names, and the reason the application needs it. Keep source links and the time checked so a reviewer can repeat the lookup.
For npm, the official npm view documentation explains how to inspect registry metadata and individual fields for a specified package version. It also notes that an unspecified version defaults to the latest tag. A lookup of “latest” and a review of an exact release answer different questions. Match the lookup to the version proposed in the change.
Evidence and its limits
| Check | Useful evidence | Still unresolved |
|---|---|---|
| Identity | Project docs and exact name | Whether it fits the task |
| Release | Version in chosen registry | Whether its code is safe |
| Origin | Verified build/source link | Whether the source is safe |
| Fit | Licence, runtime and tests | Future defects or changes |
Review the publisher and release history, relevant advisories, licence, supported runtime and added dependencies according to your project’s policy. A missing field is a gap to investigate, not a favourable result. A large download count or familiar logo should not replace that review.
Provenance helps trace a release; it does not approve it
A provenance statement supplies evidence about where a package came from and how it was built. The npm provenance guidance explicitly warns that established provenance does not guarantee the absence of malicious code. It provides a verifiable connection to source and build instructions that people can assess.
Keep that result separate from the decision to accept the dependency. A verified origin may still lead to code that does not meet the application’s requirements. Conversely, unavailable provenance is not, by itself, proof that a package is malicious. Apply the team’s stated policy and record any unresolved risk or exception.
Move the check before installation
The workflow needs a point where a proposed dependency can be reviewed before the agent executes its installation command. An instruction saying “check first” is useful guidance, but it does not establish that the tool actually blocks unapproved installation. Verify the permission boundary in the coding environment you use.
For a new dependency, retain the manifest change and the exact evidence used to accept it. After acceptance, inspect the resolved dependency changes, not just the direct name the agent suggested. Run the relevant compatibility and behaviour checks in the intended test environment. Record which checks ran and their limits; do not turn a missing security check into a clean result.
To test the workflow, give it a proposed dependency whose identity has deliberately been left unresolved. The expected outcome should be a visible request for evidence before installation. Then supply the evidence through the normal approval path and check that the accepted version is the one used. This is a proposed workflow test; no agent installation experiment was performed for this article.
The guide to AI tool security workflows covers the wider question of what an agent is allowed to execute. Dependency review belongs at that boundary, where the decision can still change the action.
If your team needs help putting these checks into its development process, request an AI Delivery Programme conversation.
Frequently Asked Questions
How do you prevent AI coding agents from hallucinating software packages?
You cannot establish that a model will never invent a name. You can require unresolved recommendations to remain proposals and stop them from becoming installation actions. Measure the workflow by what it permits and records, rather than by whether the agent says it is certain.
What registry evidence should an agent provide before adding a dependency?
Provide enough for another person to reproduce the resolution: the registry used, exact package and version, lookup result and time. Keep the project’s installation reference beside it. If a private registry needs access, name that limitation rather than presenting a failed public lookup as proof the package does not exist.
What if the package exists but the suggested function does not?
Check the API documentation for the exact release. The agent may have mixed versions or invented a function within a real package. A small behaviour check can expose that mismatch, but the remedy may be correcting the code rather than choosing a different dependency.
Does a lockfile make a new dependency trustworthy?
A lockfile helps record the resolved dependency set. It does not explain why the team selected those packages or whether they are suitable. Review new entries and changes in their source alongside the code change, then retain the rationale separately.
What if the registry is unavailable during review?
Keep the lookup unresolved. If your team permits an approved internal mirror or previously reviewed artifact, record that route and its limits. Avoid quietly switching to a different registry just to obtain a successful response; that changes the source being trusted.
Should a package without provenance always be rejected?
That depends on the dependency policy and the consequences of using it. Some teams require attestations for particular sources or workloads; others accept alternative evidence through review. Make the exception explicit, with a responsible owner, instead of treating absence as either automatic safety or automatic guilt.
