Dependency Hallucination

Dependency hallucination happens when a generative model invents a package, library, or module name that sounds real but does not exist. Attackers can register those names on public registries and turn the mistake into a supply chain attack, making verification of generated dependencies a critical control.

Expanded Definition

Dependency hallucination is a software supply chain risk in which an AI system generates a dependency name that looks legitimate but is not actually published. In practice, this matters when engineers copy generated code, package manifests, or installation instructions without validating that each package exists, is trustworthy, and matches the intended source. The issue is closely related to hallucinated citations or code outputs, but the security impact is sharper because a fake dependency can become a real foothold if an attacker registers it first.

Within security operations, the term is used most often when reviewing AI-assisted development workflows, dependency hygiene, and build integrity. It is not limited to a single language ecosystem. Any public registry, internal artifact store, or package mirror can be affected if teams rely on generated output as though it were verified software. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because the risk sits at the intersection of asset governance, secure software practices, and supply chain resilience. Definitions vary across vendors on whether dependency hallucination includes only nonexistent packages or also misnamed, outdated, and dependency-confused references.

The most common misapplication is treating hallucinated dependencies as harmless code-quality issues, which occurs when teams skip registry checks and trust generated manifests during rapid prototyping.

Examples and Use Cases

Implementing controls against dependency hallucination rigorously often introduces extra review and tooling overhead, requiring organisations to weigh developer speed against the cost of false or malicious packages entering the build.

• An engineer asks an AI assistant to scaffold a Python service, then copies a generated LLM-assisted requirements list into production without confirming that every package exists on the official registry.
• A CI pipeline accepts an AI-generated dependency name from a pull request, and the release process later discovers that an attacker has already published a package with the same name.
• A security team reviews a generated Terraform or container build file and finds a fabricated module reference that would have broken the build or redirected downloads to an untrusted source.
• An internal developer platform allows AI code generation, but maintainers require dependency allowlisting, checksum validation, and registry verification before merge.
• A threat modeller evaluates a software development workflow and maps dependency hallucination to software supply chain abuse, especially where package names are auto-suggested and copied without human review.

Authoritative guidance on software supply chain risk is also reinforced by NIST software supply chain security resources, which help teams distinguish valid dependencies from untrusted or fabricated ones.

Why It Matters for Security Teams

Dependency hallucination turns generative AI from a productivity tool into a supply chain risk if verification is not built into the workflow. Security teams need to treat dependency resolution as a control point, not a clerical step, because the damage can begin the moment a build system fetches a malicious package under a convincing name. The problem is especially relevant in agentic AI and NHI-heavy environments, where autonomous tools may generate manifests, open pull requests, or trigger builds with little human supervision.

This is also where policy and engineering controls meet. Teams should combine signed artifacts, registry provenance checks, pinned versions, software composition analysis, and least-privilege access to package publishing systems. The security objective is not simply to block bad code; it is to ensure that generated dependencies are verified before they influence a build, deployment, or runtime environment. For broader governance context, CISA secure software development guidance is useful when formalising review and attestation expectations.

Organisations typically encounter the impact only after a build fails, a malicious package is installed, or incident response traces an unexpected dependency back to generated code, at which point dependency hallucination becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What are cascading hallucination attacks?
• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?