Slopsquatting is becoming an autonomous supply chain risk

At a glance

What this is: This analysis tracks how slopsquatting has moved from a model-hallucination curiosity into a supply chain risk that can drive malicious dependency installs in human and autonomous coding workflows.

Why it matters: It matters because IAM, AppSec, and DevSecOps teams now have to govern dependency trust at the point of suggestion and installation, not just after code review.

Context

Slopsquatting is a dependency trust problem, not just a package hygiene problem. AI assistants can invent plausible package names that do not exist, and once those names become repeatable across prompts they create a ready-made attack surface for malicious registration and dependency abuse. For identity and security programmes, the important shift is that the risky decision now happens before a human ever validates the artefact.

The article's focus is the governance gap between suggestion and verification in software supply chains. Traditional AppSec and DevSecOps controls were built around human review of code and known repositories, but autonomous coding agents can act on recommended packages without that checkpoint. That makes this a genuine supply chain and identity-adjacent issue because the agent, its permissions, and its ability to install software all become part of the trust boundary.

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 repeated hallucinated dependency names create more risk than isolated mistakes?

A: Because repetition turns a model error into a predictable target. If the same fabricated name appears across prompts or agent runs, an attacker can pre-register it and wait for adoption. That converts randomness into scale. Security teams should treat recurring hallucinations as a signal for pre-emptive registry watchlisting and install-time policy enforcement.

Q: How can security teams tell whether AI-generated package suggestions are being trusted too much?

A: Look for invented dependency names in code, tickets, build scripts, and chat threads, then trace whether they were ever validated against a registry or approved source. If teams cannot show a verification step before installation, the organisation is treating generated text as a trusted software supply signal.

Q: How should teams govern AI agents that can install dependencies?

A: Treat dependency installation as a privileged action that requires scoped authority, logging, and explicit approval for new packages. The agent should not inherit broad secrets or unrestricted registry access just because it can generate code. If the workflow must install, do it in a constrained environment with secret minimisation and dependency review before merge.

Technical breakdown

Why hallucinated package names become a reliable attack surface

A slopsquatting attack works because modern code models do not merely make random errors. They often emit the same fabricated package names across repeated prompts, which turns hallucination into a predictable string that an attacker can register first. The attacker is not exploiting a typo by a human, but the model's own invented dependency suggestion. Once the fake package exists in a registry, ordinary install tooling sees a valid package and has no reason to object. The real security problem is therefore provenance, not syntax.

Practical implication: Treat AI-generated dependency names as untrusted inputs and verify package existence, ownership, and publishing history before any install.

How autonomous agents turn suggestion into execution

Autonomous coding agents change the risk because they can translate a model suggestion directly into an install action. That removes the human pause that previously existed between recommendation and execution. When an agent can fetch packages, update project files, or chain tools without review, a hallucinated dependency becomes a live supply chain control issue rather than just a bad recommendation. The same pattern is even more dangerous when the agent is allowed to follow secondary prompts, because the install step can be coupled with other instructions that expand the attack path.

Practical implication: Constrain agent permissions so they cannot install or execute unverified dependencies without explicit policy checks.

Why repeatable hallucinations are more dangerous than one-off errors

The most important measurement is not whether a model ever hallucinates, but whether it repeats the same hallucination across prompts and models. Repeated outputs let attackers pre-register names at scale and wait for downstream adoption. That makes slopsquatting a supply chain planning problem, not a random quality issue. Defenders should think in terms of predictable artefact emergence, because a stable hallucinated package is effectively an early indicator that an attacker can weaponize the name before the ecosystem catches up.

Practical implication: Add monitoring for recurring hallucinated dependency names and prioritise any string that appears across multiple prompts or agent runs.

Threat narrative

Attacker objective: The attacker wants to get malicious code executed through a trusted dependency path before the organisation verifies the package's legitimacy.

1. Entry begins when an AI model recommends a plausible package name that does not exist in the registry, creating a false dependency candidate.
2. Credential or execution risk appears when a developer or autonomous agent installs the newly registered package without validating origin or publisher.
3. Escalation occurs when the package is used inside an agentic workflow or build path, allowing attacker-controlled code to run in a trusted development context.
4. Impact is remote code execution or broader supply chain compromise through poisoned dependencies and agent-driven installs.

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 now a software supply chain governance issue, not a developer typo problem. The article shows that the attack surface starts with model output but becomes operational when install tooling trusts that output. That changes the control point from code review to dependency verification, which is a materially different governance problem. Practitioners should treat AI-suggested package names as a new trust boundary.

Predictable hallucinations create a named risk we can call dependency hallucination persistence. When the same invented package reappears across prompts, the attacker no longer needs creativity, only timing. That makes recurrence a useful risk signal for security teams and shifts defence toward catalogue validation, provenance checks, and policy enforcement at install time. Practitioners should measure repeatability, not just accuracy.

Autonomous coding agents collapse the gap between recommendation and execution. In human workflows, there is usually a pause where someone can question an odd dependency name. In agentic workflows, that pause disappears unless the environment adds it back through policy. This is where identity matters: the agent's authority to install software must be explicitly bounded, or slopsquatting becomes an execution path rather than a review problem.

Traditional AppSec controls do not fully see the interaction between model, agent, and registry. Repository scanning alone cannot stop a package that is created after the code review stage and then installed automatically by an assistant. The field needs controls that observe dependency suggestion, approval, and retrieval as one chain. Practitioners should reframe the issue as supply chain access governance for AI-driven development.

The policy lesson is to verify artefacts before they are trusted, not after they are already in the build. Once a hallucinated package is installed, downstream detection becomes containment work. Security teams should move verification left into the install decision and right into runtime monitoring, because the risk spans both pre-commit and post-install phases. Practitioners should treat AI-generated dependency names as governed artefacts.

What this signals

Dependency hallucination persistence: the real governance problem is not whether a model occasionally invents a package, but whether it invents the same one often enough for an attacker to weaponize it. That pushes security teams toward install-time controls, source validation, and agent permission boundaries rather than after-the-fact code review.

Autonomous coding agents collapse the review window that traditional AppSec depended on. Once a trusted assistant can install packages directly, the organisation needs policy checks at the boundary where suggestion becomes execution, because that is where the attack now lands.

For practitioners

• Block unverified dependency installs by policy Require package existence, publisher identity, and provenance checks before any AI-suggested dependency can be installed in developer or agent workflows.
• Constrain autonomous install privileges Limit coding agents and build assistants so they cannot add or fetch new packages without explicit approval gates tied to the repository or environment.
• Track recurring hallucinated package names Log suggested dependency names from assistants and agents, then flag names that recur across prompts, repositories, or runs as likely attack candidates.
• Verify dependency origin at the registry boundary Validate maintainer history, package age, and publication context before trust is granted, especially when a name looks like a merged or fabricated variant.
• Add runtime containment for suspicious installs Use endpoint and build-time controls that can stop a malicious package from executing even if it reached the install step.

Key takeaways

• Slopsquatting is a supply chain trust problem created by repeatable AI package hallucinations, not a simple developer typo issue.
• Autonomous coding agents make the risk more severe because they can turn a hallucinated dependency into an actual install with no human pause.
• Defence has to move to install-time provenance checks, bounded agent permissions, and monitoring for repeated hallucinated package names.

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.
• Dependency Hallucination: Dependency hallucination happens when a generative model invents a package, library, or module name that sounds real but does not exist. Attackers can register those names on public registries and turn the mistake into a supply chain attack, making verification of generated dependencies a critical control.
• Agentic Supply Chain Risk: The risk that an AI agent's behaviour is compromised through malicious or vulnerable third-party components, including tools, plugins, MCP servers, prompt templates, and RAG data sources. Mapped as ASI04 in the OWASP Top 10 for Agentic Applications 2026.
• Install-time provenance: Install-time provenance is the verification of where a package came from, who published it, and whether it is the expected artefact before it is allowed onto a system. It matters most when AI-generated suggestions can bypass human judgment and reach execution quickly.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and agentic AI identity alongside machine identity security and secrets management. It helps security leaders connect identity controls to the broader programme decisions that shape risk.