Supply Chain Risks When AI Agents Modify Dependencies

What the error-rate data shows about AI-driven dependency selection

Sonatype's 2026 State of the Software Supply Chain research looked at 36,780 dependency upgrade suggestions and found that 27.8% pointed to versions that were non-existent, deprecated, or unsafe. Roughly one in three recommendations was wrong, and wrong here doesn't mean a typo the compiler flags. It means a real package with a known CVE, a version the maintainer pulled for a reason, or a name that resolves to something an attacker registered on purpose.

Endor Labs' 2025 research fills in the rest of the picture, and it's worse than the Sonatype number alone suggests. Forty-nine percent of dependency versions that AI coding agents pulled in carried known vulnerabilities. Thirty-four percent were hallucinated outright: they don't exist in any real package registry. Stacking those two figures on top of each other means only about one in five dependency versions an AI coding assistant recommends is actually safe to use.

An academic study covering 117,062 dependency changes put agents side by side with human developers. Agents picked a vulnerable version 2.46% of the time versus 1.64% for humans, and that gap looks small until it gets multiplied across a few thousand pull requests a week, which is exactly the pace some organizations are running agents at now. When agents did pick something vulnerable, fixing it required a major-version upgrade 36.8% of the time, compared to 12.9% for human-introduced issues. Agent mistakes are structurally harder to walk back than human ones. Across the study period, agent-driven development produced a net 98 new vulnerabilities, while human-authored changes over the same window produced a net reduction of 1,316. Humans are cleaning up the codebase. Agents are quietly filling it back in.

None of this makes the problem unfixable, and the fix isn't complicated: Endor Labs found a threefold improvement in dependency safety when agents get the right tooling in place before they act, not after the pull request lands. The failure mode is governable. Almost nobody governs it yet.

Package hallucination as an attack surface: how slopsquatting works

Seth Larson, the Python Software Foundation's Developer-in-Residence, coined the term "slopsquatting" in April 2025. A model generates slop, a package name that sounds plausible but doesn't exist, and an attacker squats on that name before anyone else claims it. Simple mechanism, ugly consequences.

A USENIX Security Symposium study measured this across 576,000 code samples generated by 16 different language models and found an average hallucination rate of 19.7%, close to one in five package suggestions pointing at nothing real. Commercial models, GPT-4 among them, still produced phantom packages around 5% of the time. Open-source models did worse, landing at 21%. Across every model and prompt tested, researchers counted 205,474 unique hallucinated package names. Each one sits open on a registry right now, free for anyone to claim.

The number that should worry a security team most is 43%, not the 19.7%. It's this: 43% of hallucinated names appear consistently across similar prompts. That turns a random weakness into a predictable one. An attacker doesn't need to guess. He can run the same prompts a target's tooling is likely to run, note which fake names come back reliably, register those names once, and wait. Every future suggestion of that name then delivers whatever payload sits behind it.

Researchers sorted the hallucinations into three buckets. Pure fabrications, names invented from nothing, made up about 51% of cases. Conflations, where a model mashes two real package names into one that doesn't exist, accounted for roughly 38%. Typo variants of legitimate packages made up the remaining 13% or so.

A human developer who sees an unfamiliar package name usually pauses, if only for a second. That friction disappears entirely when an agent adds the name to package.json and opens the PR on its own, with nothing between the hallucination and the merge. The incidents below aren't a hypothetical sitting in a research paper. The incidents below aren't a hypothetical sitting in a research paper: they already happened.

Confirmed incidents that show the threat operating in production, 2025–2026

In August 2025, attackers compromised the NX CLI by exploiting a vulnerable GitHub Actions workflow to steal the project's npm publishing token. They used it to push malicious packages whose postinstall scripts turned local AI developer tools, Claude, Gemini, and Amazon Q among them, into scanners that hunted for secrets on the machines where they ran.

The following month brought Shai-Hulud, a self-replicating npm worm. Once it got into a maintainer's account, it republished itself across that maintainer's most-used packages, with roughly 200 packages compromised in its first wave.

By April 2026, public research had confirmed a case where an AI coding agent pulled a malicious, cryptocurrency-themed dependency into an active codebase tied to a legitimate crypto trading project. Around the same period, backdoored builds of LiteLLM sat on PyPI for roughly three hours and still racked up about 47,000 downloads. Three hours is all it took.

On January 27, 2026, CVE-2026-25253, tied to a system called Open-Claw, became the first CVE ever assigned to an agentic AI system. Within days, a campaign known as ClawHavoc exploited that flaw and related weaknesses to push over 1,200 malicious skills into the OpenClaw marketplace, deploying the AMOS credential stealer onto developer machines. Then in June 2026, a security firm built a harmless test skill, got it past both Cisco's and NVIDIA's security scanners, and promoted it through a skill marketplace and an Instagram ad. It reportedly reached around 26,000 agents, some running on corporate accounts. The skill passed static review clean, then loaded its real payload from a mutable external link the scanners never rechecked. Later that same quarter, GTIG watched threat actors compromise a cloud resource and then plan, build, and run a full agent-driven mass credential harvesting campaign in under six hours.

Look at the trend line, not just the individual cases. All of 2025 produced 14 supply chain attack campaigns and 111 indexed malicious packages tied to them. The first half of 2026 alone produced 37 campaigns and 497 indexed packages, several times over the campaign count and package volume of the entire prior year. Malicious npm packages rose 451% in 2025 to more than 171,000 unique entries. This has stopped being a tail risk. An enterprise survey found 88% of organizations had a confirmed or suspected AI agent security incident in the prior year, making it closer to a baseline condition of running agents.

What almost every one of these incidents shares is that the dependency change itself looked ordinary at the time it landed. A feature branch, a bug fix, a package name close enough to something familiar that nobody blinked. The attack hid inside trust, not inside anything conspicuous.

Why agentic dependency changes differ structurally from traditional supply chain risk

The OWASP Top 10 for Agentic Applications, published in December 2025 with input from more than 100 experts and review from NIST and Microsoft's AI Red Team, draws a sharp line here. Its ASI04 category, Agentic Supply Chain Vulnerabilities, describes something that happens at runtime: agents discovering and loading components while they execute, not before a human ever looks at them.

That's an architectural shift, and it changes where the risk actually lives. Traditional software composition analysis scans a manifest a human put together ahead of time. With agents, the manifest gets assembled by the agent itself, sometimes at runtime, sometimes from sources that were never on anyone's approved list to begin with. MCP servers stack a second layer on top of that problem. The agent's own tooling is a supply chain in its own right, and Endor Labs found that 75% of MCP servers are built by individuals, often with no enterprise-grade security practice behind them. Eighty-two percent of MCP servers use sensitive APIs that call for careful access control, and 41% ship with no license information whatsoever. Corporate adoption of these servers is running well ahead of anyone actually vetting them.

JFrog's report found that 53% of organizations pull AI models straight from public registries like Hugging Face, and JFrog's own researchers found 495 malicious AI models on those registries carrying payloads capable of stealing credentials, running malicious code, or handing over remote control of a system. IBM's 2026 X-Force report recorded a nearly fourfold rise in significant supply chain and third-party compromises since 2020, driven largely by attackers exploiting the trust between CI/CD automation and SaaS integrations. That pattern now maps directly onto MCP servers, model registries, and agent plugins.

A compromised agent plugin looks, from the outside, like a routine feature update. Static scanning alone can't catch that. The June 2026 skill marketplace incident showed the pattern in full: pass the static review clean, then quietly load the real payload from a link that changes after the review is finished. It's the same bait-and-switch that plagued browser extensions for years, now running through agent skills instead of browser code. GTIG has also tracked a threat actor it calls UNC6780 (TeamPCP) using tactics built specifically to trick AI coding assistants and LLM-based security scanners during open source supply chain compromises. Adversaries are targeting the AI layer of the review process now, not just the package layer sitting underneath it. A large empirical analysis of 42,447 agent skills found that 26.1% carried at least one security vulnerability, which suggests the skill ecosystem is where the next wave of these attacks is already forming.

What the regulatory and standards environment now requires of teams running agents

The EU AI Act was originally set to apply its high-risk system obligations in 2026, but the Digital Omnibus on AI, which entered into force on July 27, 2026, pushed that timeline back, to December 2027 for Annex III systems and August 2028 for Annex I systems. Any system classified as high-risk still has to meet strict data governance and quality standards, with documentation built to survive an audit.

The obligation that matters most for engineering teams sits downstream of the model itself. When an AI coding tool generates code that ends up inside a high-risk system, biometric identification, credit scoring, critical infrastructure control, the documentation, human oversight, and audit trail requirements fall on the organization deploying that system, not the company that built the AI tool. NIST's AI Risk Management Framework addresses deployed system risk, and NIST's preliminary Cyber AI Profile, published as IR 8596 in 2025, maps CSF 2.0 cybersecurity functions onto AI-specific risks, agentic threat surfaces included. OWASP's Top 10 for Agentic Applications, published in 2025, names agentic supply chain vulnerabilities as a top concern for any system that uses tools on its own.

SOC 2 audit scopes in 2026 have started asking how AI-generated code gets reviewed and how agent-introduced dependency changes get logged. SLSA and Sigstore already define supply-chain integrity standards for conventional software artifacts. The open question most teams are working through now is how to extend that same provenance guarantee to a change an agent made without anyone in the loop. The frameworks exist and they're not the weak link here. The tooling built to satisfy them for agentic workflows is newer than the frameworks themselves, and it shows in every audit that tries to trace an agent's decision back to a reviewable record.

Why prompt-based governance fails

Telling an agent, in its system prompt, to "only use well-known, trusted packages" is a suggestion, not a control. It's a suggestion made to a system that has already shown a 27.8% error rate on exactly this kind of judgment call, with no enforcement behind it, no audit trail, and no way to prove after the fact that the instruction did anything. Prompt-based governance fails for the same reason asking a toddler to "be careful" fails: the instruction and the capability to comply with it are two different things, and nothing in the architecture connects them.

What actually works looks like Endor Labs' finding: tooling in the loop before the agent acts. That means dependency changes routed through the same SAST and SCA scanning a human's pull request would face, no exceptions carved out for the author being an agent. It means treating every AI-generated package addition as untrusted third-party input by default, the same posture a security team would take toward a contractor's unreviewed code drop. It means logging the provenance of every dependency an agent introduces, so that when a regulator, an auditor, or an incident responder asks how a package got into the manifest, someone can actually answer.

None of this is exotic. SCA scanning, SAST, dependency provenance logging: these are controls that already exist and that most mature engineering orgs already run against human-written code. The failure is the assumption, still common in 2026, that automation which moves faster than review somehow needs less of it. It's the assumption, still common in 2026, that automation which moves faster than review somehow needs less of it. That assumption is backwards, and the incident list above is the bill for believing it.