Slopsquatting exposes a new software supply chain risk for AI coding

At a glance

What this is: Slopsquatting is a software supply chain attack that exploits repeated AI package hallucinations to get developers or agents to install malicious dependencies.

Why it matters: It matters because AI-assisted development expands the trusted path into public package registries, so dependency approval, install-time controls, and AI-BOM inventory all become identity and supply chain governance issues.

Context

Slopsquatting is a supply chain risk created when AI coding tools invent package names that look plausible but do not exist. The security gap is that developers often treat assistant output as a recommendation, while autonomous coding agents may install dependencies without a human checkpoint.

The article’s core governance issue is not simply bad code suggestions. It is whether organisations can control what software identities, packages, and agents are allowed to introduce into the build path, especially when the name itself can be predicted and registered first.

Key questions

Q: What is the first control teams should add to stop slopsquatted packages?

A: Start by requiring validation before any AI-suggested dependency can be installed. The package must exist, come from the expected registry or repository, and have enough maintainer and download evidence to pass policy. If an assistant or agent cannot prove that a package is legitimate, the install should be blocked rather than reviewed later.

Q: Why do AI hallucinations create supply chain risk for developers?

A: Because a hallucinated package name can be predictable enough for an attacker to register first. Once that happens, the AI’s error becomes a delivery mechanism for malicious code. The risk is not the hallucination itself, but the trust placed in a suggestion that may already be weaponised in the registry.

Q: What are the signs that AI-suggested dependency controls are failing?

A: Warning signs include repeated installs of unfamiliar packages, agent-driven dependency changes without human review, and new packages appearing in builds before any internal validation step. If your teams cannot explain who approved the dependency, the control boundary has already failed and the registry has become the decision point.

Q: How should organisations govern autonomous agents that install packages?

A: Treat package installation as a privileged action that must be explicitly authorised for each agent. Separate suggestion from installation, require approval for new dependencies, and log which non-human identity performed the action. If an agent can both choose and fetch packages, it should be governed like any other high-risk installer.

Technical breakdown

How repeated hallucinated package names become an attack surface

AI coding assistants can generate non-existent dependency names that recur across the same prompts and across different runs. That repeatability matters because an attacker does not need a random fake package, only a name that models are likely to suggest again. Once the attacker registers that name in a public registry, the assistant’s mistake becomes a delivery mechanism. This is why slopsquatting is more than simple hallucination: it converts model error into a stable supply chain entry point. The defensive problem sits at the boundary between model output and package trust, not inside the package manager alone.

Practical implication: Treat AI-suggested dependency names as untrusted until validated against registry, maintainer, and repository evidence.

Why autonomous agents increase slopsquatting risk

An autonomous coding agent changes the control model because it can act on a suggested package without the human pause that usually interrupts a suspicious install. In that pattern, the agent becomes the installer, the validator, and the executor of the dependency choice. If the package is malicious, the install hook can run immediately and the compromise can spread into build systems, secrets, and downstream artifacts. The practical risk is not only that the assistant is wrong, but that the agentic workflow collapses the review step that would otherwise catch a fake dependency name before execution.

Practical implication: Add explicit human approval or policy enforcement before any agent can install new dependencies from public registries.

Why signature-only detection fails against brand-new packages

Slopsquatted packages often exist only briefly, which means reputation and signature-based controls arrive too late. The attack succeeds in the gap between publication and detection, when the package is new enough to look legitimate but old enough to be installed. Behavioural inspection at publish or install time is more relevant than waiting for a known-bad signature because the malicious action may be the first thing the package ever does. This is a classic supply chain timing problem: the exploit window is created by the delay between registration, user trust, and security telemetry.

Practical implication: Shift from signature dependence to install-time behavioural screening for new or low-reputation packages.

Threat narrative

Attacker objective: The attacker wants to turn AI-generated package suggestions into a reliable malware delivery path inside software builds and developer environments.

1. Entry begins when an attacker observes recurring hallucinated package names from common AI coding prompts and claims one of those names in a public registry.
2. Credential or code execution risk appears when a developer or autonomous agent installs the hallucinated package and its install hook or payload runs.
3. Impact occurs when the malicious package exfiltrates secrets, opens a shell, or plants a backdoor that can propagate into builds and production.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Slopsquatting is a governance problem, not just a model-quality problem. The central failure is that organisations allow AI output to influence package selection without a corresponding trust decision. That creates a new control gap between code generation and dependency admission. The practitioner conclusion is that dependency governance now has to extend to AI suggestions, not just published packages.

The named concept here is hallucinated dependency reuse. When the same fake package names recur across prompts, attackers can pre-register them and rely on repetition rather than guesswork. This turns model variance into a predictable supply chain pattern. The practitioner conclusion is to monitor recurring AI-suggested package names as a distinct threat signal.

Agentic coding workflows compress the review window to zero. A human developer may question a strange package name, but an autonomous agent often will not. That means the control has to move from post-suggestion review to pre-install policy. The practitioner conclusion is to treat agent install authority as a privileged capability, not a convenience feature.

Supply chain security now includes identity of the installer. The same package can be harmless in one context and dangerous in another depending on whether a human, a script, or an agent is allowed to fetch it. That matters because package trust is no longer only about the artifact, but also about who or what is authorised to introduce it. The practitioner conclusion is to govern package intake as an access problem.

AI-BOM thinking is becoming operational, not optional. If teams cannot inventory which assistants and agents can install software, they cannot govern the resulting dependency risk. Slopsquatting shows that software supply chain controls and identity controls now overlap at the point of install. The practitioner conclusion is to map AI tools into the same governance model used for other non-human actors.

What this signals

Hallucinated dependency reuse: repeated fake package names create a predictable attack pattern that defenders can monitor as an indicator of registry abuse. The practical shift is from trusting the assistant’s fluency to governing the install boundary, because the attacker only needs one repeated name to land a malicious package in the workflow.

AI-assisted development changes the unit of control from code completion to dependency admission. Organisations that already manage non-human identities should apply the same governance discipline to coding agents, because install authority is now a non-human capability with supply chain consequences.

For practitioners

• Validate AI-suggested packages before install Require developers and agents to confirm that a suggested dependency exists, is maintained, and matches the intended repository before any install command runs.
• Block unauthorised dependency installs by policy Use a dependency firewall or equivalent admission control so brand-new, low-reputation, or unapproved packages are quarantined before they reach build steps.
• Inventory AI tools and agents in the build path Record which coding assistants, copilots, and autonomous agents can recommend or install packages, then define which of them are allowed to act without review.
• Shift detection to package behaviour Score newly published packages on install-time actions, network calls, and obfuscation patterns so suspicious dependencies are flagged before signatures exist.
• Restrict agent install authority Separate code generation from dependency installation so an AI agent cannot both suggest and approve packages in the same workflow.

Key takeaways

• AI package hallucinations become exploitable when attackers register the same names first and wait for developers or agents to install them.
• Repeatability is the key risk signal, because recurring hallucinated dependency names make the attack predictable rather than random.
• The strongest controls move left of signature detection and focus on validation, install-time behaviour, and agent install authority.

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 Dependencies: Hallucinated dependencies are fake packages, libraries, or registries that an AI model invents while trying to solve a coding task. They create real security risk because attackers can register those names on public package managers and place malicious code there, turning a model error into a software supply chain compromise.
• Credential firewall: A credential firewall is a runtime policy control that screens passwords before they are accepted into an identity store. It rejects weak, breached, or predictable credentials at the point of creation, which makes the control effective only when every provisioning and reset path is covered.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity control to the wider security programme that now includes AI assistants and autonomous agents.