A hallucinated dependency trust gap is the risk created when an AI agent or software workflow trusts a library, service, or tool that was never actually required or verified. In practice, it exposes NHI, IAM, and CI/CD environments to unauthorized access, broken controls, and supply chain compromise through fabricated dependencies.
What a hallucinated dependency trust gap means
A hallucinated dependency trust gap appears when an AI agent or workflow assumes a library, service, or tool is real and trustworthy without verifying that it was actually needed, approved, or present. The result is a false trust anchor that can open paths into identity, build, and automation systems.
The key issue is not just that the dependency is missing, but that the system behaves as if the dependency exists and is safe. That can create hidden trust in code paths, permissions, and integrations that were never validated, which is especially dangerous in automated delivery and agent-driven environments.
Why fabricated dependencies are dangerous
Fabricated dependencies are dangerous because they blur the boundary between verified software composition and assumed software composition. When a workflow trusts a nonexistent or unverified component, it may skip security checks, import unsafe content, or grant access to tooling that should never have been reachable.
This is a supply chain problem as much as a runtime problem. A false dependency can become the justification for pulling packages, secrets, tokens, or CI/CD permissions into a process that was never designed to handle them.
Where that trust reaches credentials or automation privileges, the consequence can look like ordinary platform activity while actually enabling unauthorized access or control-plane abuse.
How organisations identify exposure
Exposure checks should start with inventory, because teams first need to know which agents, pipelines, package managers, and toolchains are allowed to resolve dependencies dynamically. The next question is whether those systems can fetch from public registries, internal mirrors, or opaque third-party sources without a verification step.
Organisations should also review build and deployment telemetry for unexpected dependency installation, package resolution failures that were silently bypassed, and tool calls that reference resources no approved workflow actually requires. Open source supply chain guidance from OpenSSF is useful here because it frames dependency integrity as a composition and trust problem, not just a package hygiene problem.
For agentic or automated systems, it helps to compare declared dependencies against observed runtime behavior. If the runtime is relying on tools, libraries, or services that were never explicitly introduced, the trust gap is already present.
Controls that reduce the trust gap
The safest pattern is to treat every dependency as untrusted until it is declared, verified, and constrained. That means enforcing allowlists for package sources, pinning where appropriate, and making approval of new tools or libraries a deliberate change rather than an emergent behavior.
Zero trust principles reinforce the same idea: do not extend trust simply because a workflow claims it needs a component. NIST SP 800-207 Zero Trust Architecture is relevant because it emphasizes explicit verification before access is granted, which is the right mindset for dependency trust as well.
Where workloads authenticate to services or agents, workload identity should be explicit and bounded. SPIFFE workload identity specification is a useful model for binding trust to verifiable workload identity rather than assumed dependency presence.
How to detect compromise and recover
Detection should look for the aftermath of a trust failure, not just the initial hallucination. Review package logs, pipeline history, access logs, and secret access events for signs that an agent or workflow used an unapproved dependency to reach code execution, credential material, or restricted internal services.
If a hallucinated dependency was ever acted on, assume the workflow may have broadened its attack surface. Review token use, service account activity, and any outbound requests the workflow made while it believed the dependency existed.
Because dependency trust gaps can hide in supply chain paths, post-incident review should include the provenance of every pulled artifact and the point at which the workflow first accepted the fabricated dependency as real. The LiteLLM package breach is a concrete reminder that supply chain manipulation can turn dependency trust into credential exposure.
Risk and Threat Considerations
Hallucinated dependencies create a dangerous mix of false assurance and implicit trust. The risk is that a system may grant code paths, privileges, or external access on the basis of a dependency that was never validated, which can weaken both security controls and operational integrity.
Failure mechanism: An AI agent or workflow invents or assumes a dependency, then uses that assumption to justify loading code, invoking tools, or accessing services that were never approved or required.
Impact: The resulting gap can enable unauthorized access, hidden supply chain compromise, secret exposure, and control failures that are difficult to detect because the workflow appears to be operating normally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Directly addresses verifying and controlling software supply chain dependencies and provenance. |
| CM-8 — System Component Inventory | Dependency trust gaps are easier to catch when software components and tools are inventoried and reconciled. | |
| AC-6 — Least Privilege | Unaudited dependencies can expand access paths, so least privilege limits blast radius. | |
| Recommendation — Require approved provenance and verification for dependencies before they can enter build and deployment pipelines. Maintain an authoritative inventory of components so fabricated or unexpected dependencies are visible. Restrict workflow and service permissions so unverified dependencies cannot broaden access. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party dependencies can become a trust and compromise path for non-human identities and automation. |
| NHI-06 — Insecure Cloud Deployment Configurations | Runtime trust in unverified dependencies often shows up as unsafe cloud and deployment settings. | |
| Recommendation — Assess third-party tools and services for trust boundaries before they are allowed to act in automated flows. Harden deployment settings so automated systems cannot consume unapproved services or tools. | ||
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | This term describes supply chain trust failures created or amplified by agentic workflows. |
| Recommendation — Verify agent tool and dependency chains before permitting autonomous execution. | ||
| SLSA | Supply chain integrity framework | SLSA is directly relevant because the term concerns build and artifact trust in the software supply chain. |
| Recommendation — Adopt provenance controls that prevent unverified dependencies from reaching builds and releases. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The risk is a supply chain compromise path created by trusting fabricated or unverified dependencies. |
| Recommendation — Map suspicious dependency behavior to supply chain compromise activity and investigate the provenance path. | ||
Practitioner Guidance
What to watch for: Treat any dependency introduced by an agent, generated plan, or autonomous workflow as suspect until it is reconciled with a real software bill of materials, registry record, or deployment manifest. The problem is often not a broken package alone, but a broken assumption about what the system is allowed to trust.
Governance implication: Ownership must cover dependency declaration, approval, and ongoing verification, especially where build systems or agents can create their own execution paths. If no one owns that verification step, the trust gap will persist even when other controls look strong.