AI coding assistants now suggest more than code. They also suggest the packages that code depends on, and developers accept those the way they accept any autocomplete: quickly, and on trust. Most of the time the package is real. Sometimes it is a name the model invented, and if someone has registered that name in the meantime, it lands in your build without a single warning. The install succeeds, the tests pass, and a vulnerability scanner has nothing to flag, because the package has no CVE. It just has an owner you have never heard of. That is the newest form of AI software supply chain risk.

It is not a rare edge case. Researchers who generated 576,000 code samples across 16 code-generating models found hallucination rates of at least 5.2% for commercial models and 21.7% for open-source ones, producing 205,474 unique package names that do not exist. Each of those names is a slot an attacker can register. A 2026 re-test on the newest frontier models narrowed the range to between 4.62% and 6.10%, yet five models still invented the same 127 names, and 53 of them remained registrable after coordinated disclosure. Lower rates make AI software supply chain risk less frequent. They do not make it less targetable.

Let’s understand how a made-up package name becomes a working attack, and why a standard vulnerability scan never sees it. Then we look at what the July 2026 CISA SBOM minimum elements ask of AI-assisted builds, and close with five checks you can put in the pipeline before generated code ships.

What Is a Hallucinated Dependency, and Why Catch It Before Deployment?

A hallucinated dependency is a package name that an AI model invents, and a developer then installs. If nobody has registered that name, an attacker can register it and fill it with malware, an attack now called slopsquatting.

It is the most direct form of AI software supply chain risk, the exposure created when AI systems take part in choosing, writing or installing the code your product depends on. It is not the only form.

Generated code can also pull in real packages with poor provenance, abandoned maintainers or licences your legal team never approved, and an SBOM can list what a developer intended to ship instead of what the build machine resolved and installed.

The category matters because the existing tooling was designed for a different threat model. Software composition analysis assumes the package is real and asks whether it carries a known vulnerability.

Typosquatting defences assume a human mistyped a real name. Neither assumption holds when the name was produced by a language model that has no registry lookup, only a statistical sense of what a plausible package is called. That is why AI software supply chain risk needs its own controls. A longer scanner ruleset does not cover it.

How Does a Hallucinated Dependency Become an Attack?

The mechanism is short, and here’s how it plays out:

• model generates an import or an install command for a package that sounds right and does not exist.
• A developer, or an agent acting without review, runs the install. If an attacker has already registered that exact name on npm or PyPI, the install succeeds, and the attacker’s post-install script runs with whatever permissions the build has. In most CI environments that includes environment variables, cloud credentials and the deploy token.

Repetition is what turns this into a hallucinated dependencies attack with a target list. The USENIX study found the same fabricated names recurring across prompts and across models, and the 2026 re-test confirmed 127 names that five different frontier models produce identically. An attacker does not need to guess. They query the popular models with common tasks, harvest the names that keep appearing, and register the highest-value ones. The registry then does the distribution for them.

The incidents already match the pattern. In January 2026, a security researcher found the hallucinated npm name react-codeshift referenced across 237 repositories after it was written into a single commit of 47 LLM-generated agent skills that no human reviewed. The package still did not exist. The researcher claimed the name first to keep it out of an attacker’s hands, and it kept receiving daily downloads from agents following the stale instruction. An earlier test by a different researcher uploaded an empty package under a hallucinated name and recorded more than 30,000 downloads in three months. Nobody read it. The name was enough.

Why autonomous coding agents raise the exposure

A chat assistant suggests a package and a developer decides. An agent suggests a package and installs it in the same step. Tools such as Claude Code, Cursor and the growing set of agent skills can read a task, write the code, resolve dependencies and run tests without a person approving each command.

That is the workflow we use ourselves on delivery projects, and it is why the install step has to be gated by policy. Attention does not scale to every install. From our delivery experience, the pull requests most likely to carry an unknown package are the small, tidy ones an agent produced overnight. They are exactly the ones a reviewer approves fastest, which is how AI software supply chain risk gets past a diligent team.

Why Doesn’t a Vulnerability Scanner Catch This?

Scanners answer one question well. Does this known package, at this version, carry a known flaw? A slopsquatted package fails every input to that question, which is the gap at the centre of AI software supply chain risk. It is new, so it has no vulnerability history. It is often published with a plausible README, a real-looking version number and a licence file.

Several registries now run malware detection on upload. Sonatype’s research still counted more than 454,600 new malicious packages across public registries in 2025, taking the cumulative total of known and blocked open-source malware past 1.233 million, with over 99% of it on npm. Detection at the registry is a backstop. You cannot build a control on it.

The second reason scanners miss it is timing. Scans usually run after install, on the resolved tree. By then, the post-install script has already executed on the build agent. A control for AI software supply chain risk has to run before the package manager touches the network. That places it in the resolution step and in the agent’s sandbox, well ahead of any report that arrives with the test results.

What Do the 2026 CISA SBOM Minimum Elements Change?

On 29 July 2026, CISA and partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA baseline that most procurement language still references. The revision adds four new required data fields:

• Component Hash Algorithm
• Component License
• SBOM Tool Name
• SBOM Generation Context.

It also states plainly that the elements apply to all software, including open-source software, AI software and software-as-a-service.

Two of those fields change the job for teams shipping generated code. Component hashes mean the SBOM has to describe the exact artefact that was installed, which a manifest-based SBOM produced from package.json cannot do. Generation context means the SBOM has to say at what lifecycle phase it was produced. A source-phase SBOM that lists intended dependencies and a build-phase SBOM that lists resolved ones are now different documents. Only the second can prove that a hallucinated package did not make it in.

What AI-generated SBOM compliance looks like in practice

AI-generated SBOM compliance has two readings, and both apply:

• The first is an SBOM that covers code an AI tool wrote, or a dependency an AI tool chose.
• The second is an SBOM the pipeline generates automatically, with hashes, from the built artefact.

The 2026 elements push teams toward the second, because a hand-maintained bill of materials cannot keep up with a workflow where an agent adds a package on a Tuesday night. In our pipelines, the SBOM is produced by the build job, signed, attached to the release artefact, and diffed against the previous release. A new dependency then appears as a reviewable change instead of a line nobody notices in a 4,000-entry file. That diff is where AI software supply chain risk becomes visible to a security team.

One caution on scope. The CISA document sets minimum elements for federal procurement and the agencies that co-signed it. Whether it binds your contract depends on your customers and sector, and qualified counsel should confirm your obligations. Treating it as the working baseline is still the right engineering call, because it is the list your enterprise buyers will paste into their next security questionnaire.

What Are the Five Pre-Deployment Checks That Catch Hallucinated Dependencies?

These are the controls we run on delivery pipelines that use generated code to contain AI software supply chain risk. None of them depends on the model getting better. They assume it will keep inventing names and make the invention harmless.

1. Registry existence and age gate at resolution time

Before any install, a pre-resolution step checks every new package name against the registry. It rejects anything that does not exist, was published in the last 30 to 90 days, has a single maintainer with no other packages, or has a download history that begins after the model’s training cut-off.

The 90-day window is our own threshold from delivery experience and should be read as an internal lens. Teams with slower dependency churn can set it wider. The check costs seconds and removes the entire class of packages an attacker registered last month.

2. Lockfile-only installs with integrity hashes

CI installs run with frozen lockfiles: npm ci, pip install with hashes, or the equivalent for your ecosystem. Any dependency not already pinned, with its integrity hash, in the committed lockfile fails the build.

That moves the moment of decision from the agent’s terminal to a pull request where the lockfile diff is visible. A hallucinated dependencies attack needs a fresh network resolution to succeed, and a frozen lockfile denies it one.

3. Private registry proxy with an allowlist

All package traffic from build agents and developer machines goes through an internal proxy that mirrors approved packages and blocks direct access to public registries. New packages enter the mirror through a request that a named owner approves.

This is the control that also covers the human case, because a developer who copies an install command from a blog post hits the same wall the agent does. It is also the cleanest defence against a hallucinated dependencies attack that arrives through a contractor’s laptop.

It is the single change we recommend first when a client asks where to start on AI software supply chain risk, because it is one configuration change with organisation-wide effect.

4. Build-phase SBOM with hashes, diffed per release

The build job generates the SBOM from the resolved artefact and records component hashes and the generation tool. The pipeline fails if the SBOM diff against the last release contains a package that did not pass check 1.

This satisfies the new CISA fields and turns AI-generated SBOM compliance into a by-product of the build instead of a quarterly document exercise. The same diff is what we hand to a client’s security team when they ask what changed, and it answers the question in one screen.

5. Agent sandbox with no registry egress

Coding agents run in a sandbox whose network policy allows the source repository, the internal proxy and nothing else. The agent can still write code that imports a package.

It cannot install one the proxy has not approved, so a hallucinated name produces a failed install and a visible error where it would otherwise have produced a silent success. We combine this with the guardrails described in our guide to DevSecOps pipeline automation, where policy checks run as pipeline stages instead of reviewer reminders.

How Ariel Approaches AI Software Supply Chain Risk

We use AI coding tools on our own delivery work, including Claude Code across enterprise projects, so the controls above are ones we run rather than recommend from a distance. Our approach has three parts.

• Nothing installs from a suggestion. Every dependency, whether proposed by an engineer or an agent, enters through the proxy allowlist with a named approver. The agent’s job is to write the code. The pipeline decides what it may fetch.
• The SBOM is a build output. It is generated with hashes at build time, signed, attached to the release and diffed against the previous one. That is what we hand to a client’s security team when they ask for AI-generated SBOM compliance, and it maps directly to the 2026 CISA fields.
• Review capacity goes to logic. We pair the gates with AI code review at enterprise scale, so reviewers spend their attention on whether the change is correct, knowing that what it imports has already been checked.

The engineering behind this sits inside our AI development services, and the same secure-pipeline discipline applies whether the code was typed or generated. Teams that want to see how we structure agent workflows day to day can start with our guide on using Claude Code for coding. It covers the sandbox and permission model we use in practice, which is where our handling of AI software supply chain risk starts.

Gate the Install and Stop Waiting for a Better Model

AI software supply chain risk will not be solved by a better model, because the attack only needs one invented name and the models keep agreeing on which names to invent. It is solved at the resolution step. A gate checks existence and age, a lockfile refuses fresh resolution, a proxy serves only approved packages, an SBOM is produced from the build with hashes, and an agent sandbox cannot reach a public registry.

Put those five in place and generated code becomes as safe to merge as typed code, which is the only standard that makes sense once both are landing in the same repository. A hallucinated dependencies attack then fails at the first gate instead of the last. Talk to Ariel about a pipeline review, and we will show you where your first hallucinated dependency would get through, and how to close it before deployment.

Frequently Asked Questions

1. What is AI software supply chain risk?

AI software supply chain risk arises when AI tools select, write, or install code dependencies, potentially introducing hallucinated packages, malicious code, weak provenance, or inaccurate SBOMs.

2. What is a hallucinated dependencies attack?

A hallucinated dependencies attack, or slopsquatting, occurs when attackers register AI-invented package names containing malware, which developers or coding agents may install with build permissions.

3. How often do AI models hallucinate package names?

A 2025 USENIX study measured hallucination rates of 5.2% for commercial models and 21.7% for open-source models. A 2026 re-test found rates of 4.62 – 6.10%.

4. Do the 2026 CISA SBOM minimum elements apply to AI-generated code?

Yes. Published July 29, 2026, the CISA minimum elements cover AI software and SaaS, adding required fields for component hashes, licenses, SBOM tools, and generation context.

5. What is AI-generated SBOM compliance?

AI-generated SBOM compliance means producing accurate, build-generated inventories of AI-introduced code and dependencies, including component hashes and generation context, then signing and comparing them across releases.

6. Can a code reviewer catch a hallucinated dependency?

Rarely. Plausible package names and clean lockfile changes can evade review. Registry-existence gates, frozen lockfiles, and private proxies should block unsafe dependencies before installation.