In a controlled study presented at USENIX Security 2025, researchers asked 16 large language models to generate 576,000 code samples. Nearly one in five of the open-source packages those models recommended did not exist: 205,474 unique fake package names, invented out of nothing. That would be a curiosity if it were random. It isn’t. Forty-three percent of the hallucinated names showed up again and again across repeated prompts. Attackers don’t have to guess what a coding assistant will invent. They can watch, wait, and register the name first.
That is the core problem of AI supply chain security in one experiment: the same AI that accelerates software development has become a predictable, exploitable entry point into it. The question for security teams is no longer whether AI touches the software supply chain. It’s whether you can see what it’s doing on both sides of the fight: the AI writing your code, the AI defending your pipeline, and the AI an attacker is pointing at both.
What is AI supply chain security?
AI supply chain security is the practice of protecting the software supply chain against risks introduced or amplified by artificial intelligence, and of using AI to defend that same supply chain. It sits at the intersection of two trends most security programs still treat separately: AI-generated code entering the codebase, and AI-powered attacks targeting the dependencies, build pipelines, and developer tooling that surround it.
Traditional application security asks whether a known vulnerability exists in a known component. AI supply chain security asks harder, faster questions: Does this dependency an AI agent just installed actually exist, or was it hallucinated? Does this newly published package behave maliciously, even though no signature exists for it yet? Which AI models, agents, and connections are running across the software development lifecycle, and what can they reach?
Answering those questions at the speed code actually ships is the whole discipline.
How AI became a supply chain attack surface
Attackers stopped experimenting with AI some time ago. They now build it into operations that target code and its dependencies directly, not just inboxes and login pages.
Slopsquatting: weaponizing what AI invents
The technique has a name now: slopsquatting, coined in April 2025 by Seth Larson, security developer-in-residence at the Python Software Foundation. The mechanics are simple and brutal. AI coding assistants routinely suggest package names that don’t exist. Because those hallucinations repeat, an attacker can register the invented name as a real, malicious package and wait for the next developer (or the next autonomous agent) to install it.
The precedent is already documented. In 2023, security researcher Bar Lanyado published an empty placeholder package under a name that models frequently hallucinated, huggingface-cli. Within three months it had been downloaded more than 30,000 times, and the hallucinated install command even appeared in a public repository README from a major technology company. That was a benign test. The same playbook with a real payload is now a repeatable business model for attackers.
Autonomous coding agents make this worse by removing the last human checkpoint. An agent that installs dependencies without review eliminates the one moment where a developer might have noticed the package looked wrong.
Malicious packages at industrial scale
Slopsquatting is one tactic inside a much larger shift. In 2025, high-volume malicious-package campaigns became the baseline operating model for supply chain attacks, as Xygeni’s New AppSec Attack Trends for 2026 documents. Attackers have adopted spam economics: publish malicious packages by the thousand, accept rapid takedowns, and rely on probability rather than persistence. Public registries now field hundreds of thousands of new malicious packages a year, and even a short exposure window contaminates downstream builds.
MCP: a new, largely unsecured connection layer
The Model Context Protocol (MCP) lets AI agents connect to tools and data sources. It also creates a fresh attack surface most scanners never inspect. A malicious MCP server can sit invisibly alongside legitimate ones, reachable by any agent with access. OWASP published an MCP Top 10 in 2025 to catalog these risks, from prompt injection and tool poisoning through to unauthenticated servers that any agent on the network can reach.
Secrets leaking through AI-generated code
Compromised credentials surged roughly 160% in 2025 versus 2024, according to Check Point External Risk Management (formerly Cyberint), driven partly by AI-enhanced phishing and infostealer malware. In software environments, that maps directly to hardcoded keys and tokens in AI-generated code. A coding assistant that has ingested a .env file into its context can reproduce a secret in a suggestion, and attackers scan for exactly that pattern.
The human dimension hasn’t gone away either. IBM’s Cost of a Data Breach Report 2025 found that among breaches involving AI, 37% used AI-generated phishing and 35% used deepfake impersonation, techniques increasingly aimed at developers through fake recruiter outreach and impersonated maintainer accounts.
How AI defends the supply chain
The capabilities that make AI dangerous are exactly what make it useful for defenders. In the supply chain, that trade-off is most concrete in four places.
Malware detection ahead of the signature
This is the defining capability. Traditional scanning waits for a known-bad signature before it can flag a package, which is structurally too slow for attacks that rack up thousands of downloads within hours of publication. Behavior-based detection instead scores a newly published package the moment it appears: its install-time actions, network calls, obfuscation patterns, and metadata anomalies. That closes the window slopsquatting and typosquatting campaigns depend on. The late-2025 Shai-Hulud and GlassWorm npm campaigns, which signature-based detectors missed entirely, are precisely the case behavioral analysis is built to catch.
Prioritization by exploitability, not volume
AI’s most practical contribution to modern AppSec isn’t finding more issues; it’s cutting the noise of what’s already found. Reachability analysis determines whether a vulnerable code path is actually executed. Exploitability scoring weighs real-world attack data against a raw CVSS number. Together they let teams focus on the fraction of findings that represent genuine, exploitable risk instead of triaging thousands of low-signal alerts by hand.
Anomaly detection at the pipeline level
In Darktrace’s State of AI Cybersecurity 2026 survey, security leaders named threat detection and anomaly spotting (72%) as the area where AI delivers the most impact, ahead of automated response (48%) and vulnerability management (47%). Applied to CI/CD, this means flagging an install script that behaves unlike anything seen before in that pipeline, or a dependency update that introduces an unexpected network call.
Automated, reviewable remediation
Beyond finding and ranking risk, AI now generates the fix: a safe, framework-specific code change submitted as a pull request rather than a ticket that rots in a backlog. IBM found that organizations using AI and automation extensively across security operations cut their total breach lifecycle to 204 days, versus 284 for those that didn’t (about 80 days faster), while saving an average of $1.9 million per breach. Detecting a risk without closing it just relocates the backlog; pairing AI triage with AI-generated fixes closes the loop.
The governance gap most teams haven’t closed
Here’s the uncomfortable part. Darktrace’s 2026 survey found that 77% of organizations now run generative AI in their security stack, but only 37% have a formal policy for using AI safely. That figure actually fell from 45% the year before. Adoption is outrunning governance, and attackers are exploiting the gap.
For software teams, it shows up concretely: AI coding assistants, agents, and MCP connections are already running across the SDLC, often with no centralized visibility into what they access or what they’ve introduced. Most organizations can name their cloud providers. Very few can name every AI model, agent, and MCP server reachable from a developer’s machine. That inventory, an AI Bill of Materials (AI-BOM), is the foundation the rest of AI supply chain security is built on. You cannot secure what you haven’t inventoried.
What AppSec teams should do now
The average data breach cost $4.44 million in 2025 (IBM), and the supply chain is increasingly one of the entry points. The practical response isn’t “adopt AI” in the abstract. It’s a short, concrete list:
- Inventory what AI is running in your SDLC. Models, agents, MCP servers, and AI coding tools are assets. Build the AI-BOM first.
- Treat AI-generated code like human-written code. Code that compiles isn’t automatically safe, and its dependencies deserve the same review as anything else.
- Detect malware by behavior, not signatures. Signature-based scanning is structurally too slow for high-volume, short-lived package campaigns.
- Prioritize by exploitability, not alert volume. The defensive value of AI is separating real risk from noise, not generating more of it.
- Automate remediation, not just detection. Detection without a fix just moves the backlog somewhere else.
Where AI supply chain security is heading
Two patterns will define the next few years. First, attacks are becoming predictable at scale rather than random: slopsquatting works precisely because AI hallucinations are consistent, which means defense has to shift from one-off signatures to pattern recognition that scales to match. Second, defense is moving from “alert a human” to “identify, score, and respond before a ticket exists.” The organizations gaining ground are the ones catching a malicious package’s behavior at publish time, not waiting for a CVE to be written.
AI is your newest risk and your best defense, often in the same system
AI pulls in two directions at once. It hands attackers scalable, automated tooling, and it hands defenders the ability to detect and respond at a scale manual review never could. That duality is exactly why AI supply chain security can’t be bolted on as an afterthought or banned outright.
This is the gap Xygeni was built to close. Malware Early Warning (MEW) continuously monitors public and private registries and detects malicious packages the moment they’re published, before any signature exists, using AI verdicts validated by a human research team. Xygeni Shield puts that intelligence to work at the developer’s endpoint: it blocks malicious packages at install time before their scripts run, and inventories the AI tools, agents, and MCP servers on every machine. Together they’re purpose-built for the threats this article describes: slopsquatting, typosquatting, dependency confusion, and maintainer compromise, including the Shai-Hulud and GlassWorm attack classes signature-based tools missed. Combined with reachability-based prioritization, an AI-BOM across your SDLC, and automated pull-request remediation, AI-generated code and AI-powered attacks get the same scrutiny, without slowing developers down.
Start free. Xygeni’s Developer plan is €0: 10 repositories, 200 scans a month, up to 5 contributors, no credit card. Sign up with GitHub, GitLab, or Google and run your first scan in under 10 minutes; Shield endpoint protection is coming to the Developer plan soon.
FAQ
What is AI supply chain security?
AI supply chain security protects the software supply chain against risks that AI introduces or amplifies, such as hallucinated dependencies, AI-generated code containing vulnerabilities, and malicious MCP connections, while also using AI to defend it through behavior-based malware detection, exploitability prioritization, and automated remediation.
How is AI used to defend the software supply chain?
AI enables defenses that signature-based tools can’t match: scoring a newly published package’s behavior at the moment it appears, determining whether a vulnerable code path is actually reachable, flagging anomalous pipeline activity, and generating framework-specific fixes as pull requests rather than backlog tickets.
Why can’t traditional scanners catch AI-driven supply chain attacks?
Traditional tools rely on known signatures and published CVEs, so they only flag a package after it has already been identified as malicious. High-volume, short-lived package campaigns rack up downloads within hours of publication (long before a signature exists), which is why behavior-based, pre-signature detection is required.
What is an AI-BOM and why does it matter?
An AI Bill of Materials (AI-BOM) is an inventory of every AI model, agent, and MCP connection running across the software development lifecycle. It matters because you cannot secure what you haven’t inventoried, and most organizations have no centralized visibility into what AI is reachable from a developer’s machine.
