Hallucinated Dependencies

Hallucinated dependencies are fake packages, libraries, or registries that an AI model invents while trying to solve a coding task. They create real security risk because attackers can register those names on public package managers and place malicious code there, turning a model error into a software supply chain compromise.

Expanded Definition

Hallucinated dependencies are a supply chain risk created when an LLM or AI coding assistant invents a package name, library, module, or registry that does not exist, or misstates an existing one. In practice, the output can look plausible enough that a developer searches for it, installs a similarly named package, or copies a dependency reference into build tooling. That turns a model error into an opportunity for dependency confusion, typosquatting, or direct malware distribution.

The concept sits at the intersection of AI security and software supply chain security, so the security meaning is narrower than a generic “wrong answer.” It is about fabricated software artefacts that may become operationally real once a developer trusts them. Guidance across vendors is still evolving, but the risk pattern is already clear: AI-generated code suggestions can create a false sense of package legitimacy. The most useful lens is to treat every model-suggested dependency as untrusted until verified against a source of truth such as repository metadata, internal allowlists, or a trusted package registry reference like the NIST Cybersecurity Framework 2.0.

The most common misapplication is assuming a dependency is real because the model names it confidently, which occurs when teams skip package verification during rapid prototyping.

Examples and Use Cases

Implementing controls for hallucinated dependencies rigorously often introduces friction in developer workflows, requiring organisations to weigh faster AI-assisted coding against the cost of validation and dependency governance.

• An AI assistant suggests a Python library with a believable name for PDF parsing, and a developer installs the first matching package from a public index without checking whether it came from a trusted maintainer.
• A code generation tool references a JavaScript module that does not exist, and a team creates the package internally without reviewing whether the name collides with an external registry entry later published by an attacker.
• An LLM proposes a dependency version and import path that resemble a real internal component, causing a build pipeline to pull the wrong artifact into a release candidate.
• A security engineer uses OWASP Top 10 for LLM Applications guidance to add human review and source verification before any AI-suggested package is accepted into the dependency tree.
• A procurement or platform team checks a package against internal allowlists and repository provenance before approving it for use in production, reducing the chance that a hallucinated name becomes a real supply chain entry point.

Why It Matters for Security Teams

Hallucinated dependencies matter because software supply chain compromise often begins with trust in a name, not trust in a binary. Once a fake package name is accepted, an attacker can register the name, publish malicious code, and rely on normal developer behaviour to do the rest. That makes this issue relevant to AppSec, DevSecOps, and identity-adjacent controls around repository trust, package provenance, and build integrity. Teams should pair AI usage policies with dependency verification, signed artifacts, internal mirrors, and allowlisted registries.

The risk also connects to NHI governance when automation uses service accounts, build identities, or agentic coding tools to fetch dependencies without human review. In those cases, a non-human workflow can propagate a hallucinated package straight into CI/CD. Frameworks such as OWASP Non-Human Identity and the NIST Cybersecurity Framework 2.0 both reinforce the need for controlled access, provenance checks, and monitoring around software acquisition paths. Organisations typically encounter the consequence only after a build system has already resolved, downloaded, or shipped the wrong dependency, at which point hallucinated dependencies become operationally unavoidable to investigate and contain.

Related resources from NHI Mgmt Group

• How should security teams handle hidden AI framework dependencies in enterprise environments?
• What breaks when teams rotate secrets without mapping dependencies first?
• Why do third-party dependencies make auth outages worse?
• What breaks when cryptographic dependencies are not inventoried?