What are AI hallucinated dependencies and how should generated packages be verified?

A 'hallucination dependency' refers to software package names generated by AI in code or installation recommendations that appear reasonable but do not exist. If these names are later registered by third parties and developers install them without verification, it can turn a false recommendation into a new software supply chain entry point.

How hallucinated packages differ from malicious packages

'Hallucination dependency' primarily involves inconsistencies between generated content and the real package ecosystem. Malicious packages, on the other hand, involve publishers embedding harmful behavior in software. While they can be connected, they are not equivalent: a non-existent package does not mean an attack has occurred, and a genuine package is not necessarily trustworthy.

Researchers observed the phenomenon of package hallucination in 16 models' generation of 576,000 Python and JavaScript samples. This study supports the existence of this risk but cannot directly explain its proportion based on all current AI code, as it depends on the model, prompt, and experimental setup Original Paper.

Step one: identify the recommended project

Don’t just search for the presence of package names. Follow official project documentation to find installation commands, and verify if the package repository links back to the same project. Verify the maintainer organization, name spelling, version history, and code source; pause access for new packages with unclear installation scripts or missing explanations.

Downloads and recent commits can help determine review order, but they cannot independently prove security. Mature components may be stable over long periods without frequent updates, while a new project is not necessarily untrustworthy; the key is whether the source and purpose are explainable.

Step two: pin the reviewed artefact

After verifying a package, record its exact version and dependencies, retain lock files and preserve the review conclusion. For Python projects, pip’s hash-checking mode can be enabled in the build process and transitive dependencies can be pinned. Hashes help verify that the expected file was retrieved; they cannot make a malicious file safe. pip secure installation guide

Step three: test installation and execution in isolation

During the installation process, scripts for building might be executed. Therefore, do not allow unvetted dependencies to come into contact with production keys. Verify that the actual APIs provided by a package align with requirements; pay attention to external connections, file writes, and additional downloads during the installation and testing phases before deciding whether to permit entry into controlled dependency repositories.

Step four: treat new dependencies as review events

The code evaluation should highlight changes in new packages and versions, rather than just looking at business codes. The screening is complemented by the SCA, malicious package intelligence and warehouse strategy, and the team still has to record the risk judgement and those responsible. The subsequent publisher, source address or downloader is rechecked when the work changes.

Let AI confirm the name again? A lead can be provided, but it cannot be a substitute for independent verification of access to official documents and warehouses.

Is using only approved packages enough? We also need to fix versions, track advisories and evaluate upgrades. Approval comes from specific sources with usage conditions, not a permanent guarantee of package safety.