Slopsquatting is becoming an autonomous supply chain risk

At a glance

What this is: This article traces slopsquatting from early hallucinated package names to agent-driven install risk, showing how predictable model output can be turned into scalable supply chain abuse.

Why it matters: It matters because AppSec and DevSecOps teams now have to govern not just human package selection, but AI-suggested dependencies and autonomous installs that bypass normal review.

By the numbers:

• The USENIX Security 2025 study tested 16 code-generation models across 576,000 Python and JavaScript samples.
• The study found that 19.7% of recommended packages did not exist.
• Open-source models hallucinated packages far more often, averaging 21.7% versus 5.2% for commercial models.
• When identical prompts were repeated ten times, 43% of hallucinated names appeared on every run.

👉 Read Xygeni's analysis of slopsquatting evolution and AI package hallucinations

Context

Slopsquatting is a supply chain attack that exploits AI package hallucinations, not human typos. The control gap is simple: traditional AppSec assumes developers can verify what they install, while AI-assisted workflows can propagate a fabricated package name at machine speed across many repositories.

For AppSec and DevSecOps teams, the concern is no longer just whether a package exists in a registry. It is whether dependency recommendation, package resolution, and install-time execution are being governed well enough to stop an invented name from becoming a real compromise path.

That shift is especially important where coding assistants and autonomous agents can act without a human checking the command line. The article shows a pattern that began as curiosity and now looks typical of the way AI-accelerated software supply chain abuse will develop.

Key questions

Q: What breaks when AI assistants recommend packages that do not exist?

A: The trust model breaks because existence in a registry is no longer a reliable proxy for legitimacy. If teams let AI-suggested names flow straight into install commands, attackers can register the hallucinated package first and turn a recommendation into code execution. The control failure is at the verification step, not the model output itself.

Q: Why do hallucinated package names create a bigger risk for autonomous agents than for developers?

A: Autonomous agents remove the human checkpoint between suggestion and execution. A developer might notice a strange package name and stop, but an agent can fetch, resolve, and install it immediately. That collapses the time available for review and makes install-time policy enforcement the decisive control.

Q: How should AppSec teams measure whether slopsquatting controls are working?

A: Measure how many AI-generated dependency suggestions are blocked before install, how many recurring hallucinated names are detected across repositories, and how quickly new fake package names are added to guardrails. If the same hallucinations keep appearing in pipelines, the control is not operating early enough.

Q: Who is accountable when an AI agent or automation system installs a malicious dependency?

A: The accountable team is the one that granted autonomous execution without a policy boundary. If a bot or AI agent can install third-party code, the organisation has created a delegated trust chain and should govern it like any other privileged non-human identity. Accountability sits with platform owners, security governance, and the workflow owner together.

Technical breakdown

How hallucinated package names become a real supply chain path

Slopsquatting works because AI models often generate plausible package names that are not present in any registry. An attacker watches those recurring hallucinations, registers the name first, and waits for developers or agents to trust the suggestion. The technical risk is not the model alone, but the combination of deterministic-looking output, registry availability, and automatic install flows that treat existence as proof of legitimacy. That makes dependency resolution a trust problem, not just a syntax problem. Practical implication: treat AI-generated dependency names as untrusted inputs until package origin and reputation are verified.

Practical implication: validate every AI-suggested dependency against origin, reputation, and maintainership before install time.

Why repeatable hallucinations matter more than random errors

The study cited in the article shows that hallucinations are not purely random. When the same prompt is run repeatedly, the same fake package names often reappear, which means attackers can predict which names are worth claiming. That repeatability turns a generative error into a pre-positioning opportunity across ecosystems such as npm and PyPI. It also explains why the threat scales beyond one developer, because the same hallucinated dependency can spread through copy-pasted prompts, generated agent skills, and shared project templates. Practical implication: monitor for recurring AI-generated package names and block them centrally before they become socialised across teams.

Practical implication: centralise detection of recurring hallucinated names instead of relying on individual developer judgement.

How autonomous agents change the package install threat model

Autonomous coding agents remove the human checkpoint that used to sit between recommendation and execution. If an agent can fetch, install, and follow up on package guidance without review, then a hallucinated dependency can move straight from suggestion to code execution. The article’s 2026 examples show that slopsquatting now intersects with agentic AI security, because package identity, tool invocation, and install-time behaviour are all part of the same trust chain. That means governance has to cover the AI system’s actions, not only the repository contents. Practical implication: gate agentic install behaviour with policy controls that can stop execution before the dependency reaches runtime.

Practical implication: constrain autonomous installs with policy and runtime controls, not only repository scanning.

Threat narrative

Attacker objective: The attacker wants to turn a fabricated package suggestion into trusted code execution inside developer or agent workflows.

1. Entry occurs when an AI model recommends a hallucinated package name that a developer or autonomous agent treats as valid.
2. Escalation happens when the attacker registers the invented package and the install step proceeds without human verification.
3. Impact follows when the package executes in a build or agent workflow, enabling malware delivery or remote code execution inside the software supply chain.

NHI Mgmt Group analysis

Slopsquatting is now a software supply chain governance problem, not a prompt-quality issue. The article shows that hallucinated package names can be repeated, observed, and registered at scale. That means the control gap sits between AI recommendation and dependency trust, where conventional AppSec still assumes a human will notice the mismatch. Practitioners should treat AI-generated dependency suggestions as an external supply chain input that requires policy, validation, and telemetry.

Predictable hallucinations create a named concept we should track: hallucination reuse risk. When the same fake dependency is produced across repeated prompts, the attacker does not need creativity, only timing. That changes the economics of abuse because one invented name can be monetised across many teams and projects. The lesson for AppSec is to watch for repeated AI-generated artifacts as a category of pre-compromise signal, not as isolated model noise.

Agentic AI turns package trust into an execution governance issue. The article’s strongest warning is that autonomous agents can install dependencies without a human in the loop. Once that happens, the old assumption that a developer can catch a bad package before execution no longer holds. Security programmes need to align dependency policy with runtime enforcement, because install-time trust now determines execution safety.

Traditional registry checks are necessary but insufficient for this class of abuse. A package can be real in the registry and still be unsafe because it was registered in response to model hallucination. That means allowlists, provenance checks, and behavioural controls have to operate together. Teams should expect package identity abuse to converge with broader software supply chain attacks, especially where AI-generated code is accepted with minimal review.

OWASP-NHI becomes relevant where AI agents can perform installs and invoke tools. The identity problem is not just the developer account, but the machine-driven actor that carries out the dependency action. When an agent can request, fetch, and execute software, its credentials and permissions become part of the supply chain attack surface. Practitioners should govern agent identity and tool access with the same seriousness they apply to privileged human workflows.

What this signals

Slopsquatting is a clear sign that software supply chain governance must now account for AI-generated inputs, not just developer intent. The operational question is whether your controls can stop a package name that is plausible, repeated, and machine-propagated before it becomes executable code.

Hallucination reuse risk: recurring fake package names are becoming a measurable pre-compromise signal. Teams should instrument assistant output, dependency admission, and install-time enforcement together so the same hallucination cannot travel from chat to repository to runtime.

Identity controls matter because agents and build systems increasingly act as non-human identities with tool access. When those identities can request or install software, their permissions become part of the supply chain trust chain, which is why governance should align with NIST SP 800-53 Rev 5 Security and Privacy Controls and internal package approval workflows.

For practitioners

• Block AI-suggested dependencies by policy Require package origin verification and central approval for any dependency first seen in an AI-generated suggestion, especially where the name does not exist in approved registries or maintainers lists.
• Detect recurring hallucinated package names Log dependency names proposed by assistants and agents, then compare them across repositories so repeated hallucinations can be denied before they spread through templates and shared prompts.
• Constrain autonomous install permissions Separate package recommendation from package execution so agents can propose dependencies but cannot install them without policy checks, provenance validation, or human approval.
• Extend supply chain monitoring into agent workflows Include AI assistants, coding agents, and MCP-connected tooling in dependency monitoring, because the install event may now originate outside the developer’s direct action.

Key takeaways

• Slopsquatting has moved from a model hallucination problem to a supply chain execution problem.
• The evidence shows repeated fake package names can be predicted, reused, and weaponised at scale.
• Teams need install-time policy, provenance checks, and agent governance before AI-suggested dependencies reach runtime.

Key terms

• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Hallucinated Package Name: A hallucinated package name is a dependency string produced by an AI model that looks valid but does not exist in the intended registry. In security terms, it becomes dangerous when a real attacker claims the name and uses it as a delivery path.
• Agentic Install Flow: An agentic install flow is a software workflow where an AI agent can resolve, fetch, and install dependencies with limited or no human review. It matters because it removes the checkpoint that normally catches suspicious packages before execution.
• Supply chain provenance: The ability to trace where code, packages, and build artefacts came from and how they were produced. It is essential for software trust because it turns opaque assembly into an auditable chain of custody that security, compliance, and operations teams can verify.

What's in the full article

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step slopsquatting timeline from 2023 to 2026, including the named cases that show how the pattern changed.
• The research details behind the USENIX study, including model-by-model hallucination behaviour and recurrence patterns.
• The defensive logic behind Xygeni Shield's install-time blocking approach and how it fits into a developer workflow.
• The article's examples of agent-driven installs and prompt-injection chaining that move the threat from suggestion to execution.

👉 Xygeni's full article covers the timeline, research evidence, and agent-driven abuse patterns in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It is suitable for practitioners building controls around automated workflows, tool access, and identity-driven security risk.