Slopsquatting attacks are turning AI package hallucinations into real risk

At a glance

What this is: This analysis explains how slopsquatting turns AI-generated package hallucinations into a software supply chain attack path.

Why it matters: It matters to AppSec, DevSecOps, IAM, and platform teams because AI-assisted development can introduce untrusted dependencies and automated installs that bypass normal review controls.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

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

Context

Slopsquatting is a software supply chain problem that starts with an AI model inventing a package name and ends with a developer or agent installing malicious code. The security gap is verification, not awareness: teams assume a suggested dependency exists because the model sounded confident, then fail to check registry provenance before installation.

This is relevant to AppSec and DevSecOps because AI-generated code now influences dependency selection as well as code content. When package trust is delegated to a model, the control boundary shifts from human review to dependency validation, which makes package governance, registry hygiene, and build-time policy enforcement more important than ever.

The article's examples show that this is no longer a niche research curiosity. Repeated hallucinations, agentic installs, and poisoned lookalike packages have made the pattern operationally real, not just theoretically possible.

Key questions

Q: What breaks when AI-generated package names are allowed to install without review?

A: The main failure is that model output becomes an execution path. A hallucinated package name can be registered by an attacker, installed automatically, and allowed to run install-time code that steals secrets or plants further payloads. The control gap is unverified dependency execution, not merely poor model accuracy. Protect the install boundary first.

Q: Why do repeated package hallucinations matter to AppSec teams?

A: Repeated hallucinations matter because they are predictable. If the same invented package appears across prompts or agents, an attacker can register it once and wait for multiple victims. That makes slopsquatting scalable, not random. Security teams should monitor for recurring hallucinated names and block them centrally across repositories and build pipelines.

Q: How can security teams reduce the risk from agent-driven package installs?

A: They should require policy gates for any first-time dependency, especially when an AI agent proposes the install. The safest pattern is allowlisting for known-good packages, human approval for new ones, and build-time controls that refuse unverified dependencies. This keeps autonomous workflows from turning suggestion into execution without scrutiny.

Q: Who is accountable when an AI assistant follows malicious repository instructions?

A: Accountability sits with the organisation that allowed mutable instructions to act as standing authority without governance. If a project file can change agent behaviour, then ownership of that file, its review process, and its execution scope must be defined. Without that, the organisation has delegated security decisions to uncontrolled context.

Technical breakdown

How package hallucinations become a supply chain entry point

A slopsquatting attack starts when an LLM recommends a package name that sounds plausible but does not exist. An attacker monitors repeated hallucinations, registers the name in a public registry such as npm or PyPI, and waits for the next developer or coding agent to install it. The dangerous part is that the package is now real, so normal installation workflows will not flag it as suspicious. This differs from classic typosquatting because the mistake originates in model output rather than human typing. The attack works best where AI suggestions are treated as trusted dependency discovery rather than unverified hints.

Practical implication: treat every AI-suggested dependency as untrusted until registry, maintainer, and package-history checks pass.

Why repeatable hallucinations make slopsquatting scalable

The article highlights a crucial property of package hallucinations: they are often repeatable. If the same model keeps producing the same invented name under similar prompts, an attacker does not need to guess what to register. That turns one hallucinated dependency into a scalable threat across many teams, repos, and agent workflows. The risk increases further when coding assistants or autonomous agents reuse prompts, because the same invented package can propagate through multiple projects. Repeatability is what converts model error into an attack surface that behaves like a supply chain vulnerability rather than a one-off coding mistake.

Practical implication: scan for repeated hallucinated dependency names across repositories and block them centrally before they spread.

How agentic coding expands dependency trust beyond the developer

Agentic coding changes the control model because the system, not just the developer, may decide what to install next. If an AI assistant or agent fetches packages autonomously, the organisation loses a direct human checkpoint that used to catch suspicious names, unusual maintainers, or registry anomalies. The article also points to MCP-connected workflows, which widen the path from suggestion to execution by linking models to tools and data sources. That means package governance must extend into automation policy, build integrity, and dependency allowlisting, not just developer education.

Practical implication: enforce policy gates for agent-driven installs and require human approval for first-time dependencies.

Threat narrative

Attacker objective: The attacker wants to convert model-generated trust into package installation and then use that foothold to execute malicious code or steal secrets.

1. Entry occurs when an LLM invents a package name and a developer or agent accepts it as a plausible dependency.
2. Credential or code execution escalation follows when the attacker-registered package is installed into the build or runtime environment.
3. Impact is achieved when the malicious package executes backdoor code, steals secrets, or poisons the software supply chain downstream.

NHI Mgmt Group analysis

Slopsquatting is an identity-adjacent supply chain problem because the trust decision happens before code ever runs. The real failure is not package installation alone. It is the assumption that a model-generated dependency suggestion has the same provenance as a vetted dependency, which it does not. AppSec teams need to treat dependency naming as a trust boundary, not a convenience feature.

Repeatable hallucinations create a new kind of dependency persistence risk. When the same invented package appears across prompts, repositories, and agents, the attacker can register once and collect many victims. That pattern resembles credential reuse in NHI governance: a single uncontrolled artifact can persist across multiple workflows until a central control blocks it.

AI-assisted development expands the attack surface faster than traditional SCA was designed to observe. Most tooling still focuses on known bad packages, but slopsquatting begins with unknown names that become dangerous only after registration. The named concept here is hallucination-to-installation gap: the window between model output and package verification where trust is misapplied. Practitioners should close that gap with policy, not hope.

Package verification is now part of secure software identity governance. The article shows that the registry, maintainer history, and package lineage are as important as the code itself. That makes dependency governance a first-class control in modern AppSec, and teams that do not formalise it will keep relying on developer memory instead of enforceable process.

Autonomous install workflows amplify slopsquatting more than individual developer mistakes do. The shift from manual copy-paste to agent-driven execution means the same hallucinated dependency can be installed repeatedly without fresh scrutiny. Practitioners should assume the attack surface now includes the model, the agent, and the registry path between them.

What this signals

Hallucination-to-installation gap: this is the control window AppSec teams now need to own. AI-assisted dependency selection is no longer just a developer productivity issue, because a model can create the exact prerequisite for an attacker to weaponise a package name before any human validation occurs. The right response is to move verification into CI, SCA, and agent policy, not leave it to end-user caution.

The programme signal is clear for teams already managing secrets and workload identity: unverified package installs can become the starting point for downstream secret exposure. That makes dependency governance relevant to IAM and NHI teams as well as AppSec, because compromised build paths often lead to credentials, tokens, and certificates being harvested later in the chain.

For practitioners, the practical shift is to treat AI suggestions as untrusted external input. Pair dependency allowlisting with build provenance controls and review the AI toolchain itself, using the MITRE ATT&CK Enterprise Matrix and MITRE ATT&CK technique mapping where package compromise leads to credential access or exfiltration.

For practitioners

• Implement first-time dependency verification Require registry existence checks, maintainer review, publication age review, and package history review before any AI-suggested dependency is approved for use. This should apply to human requests and agent-generated installs alike.
• Block hallucinated package names centrally Build a denylist of invented or suspicious package names seen in prompts, pull requests, and build logs, then enforce it in SCA and CI policy so repeated hallucinations cannot slip into multiple repositories.
• Gate autonomous installs with approval policy Prevent coding agents from installing new packages without a human checkpoint or a pre-approved allowlist, especially where the dependency was not already present in the organisation's standard software catalogue.
• Extend dependency review into AI workflows Add dependency validation to developer training, secure coding standards, and pipeline policy so AI-generated suggestions are treated as untrusted input, not as authoritative guidance.

Key takeaways

• Slopsquatting works because AI-generated dependency suggestions are often trusted before they are verified.
• Repeatable hallucinations make the attack scalable across repositories, agents, and teams.
• The control that matters most is enforced dependency provenance, not developer vigilance alone.

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.
• Package Hallucination: Package hallucination occurs when an LLM suggests a package name that does not exist, creating a gap attackers can exploit. If the suggested name is later registered by an attacker, developers may unknowingly install malicious code from a seemingly plausible source.
• Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.
• Hallucination-to-Installation Gap: The hallucination-to-installation gap is the time and trust window between AI output and dependency validation. That gap is where slopsquatting succeeds, because the package name is treated as acceptable before registry checks, policy gates, or human review can intervene.

What's in the full article

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

• Step-by-step examples of how hallucinated package names propagate from AI prompts into real registries and build pipelines.
• The specific prevention workflow for verifying package provenance, maintainer history, and suspicious install behaviour.
• Practical SCA and CI policy patterns for blocking invented dependencies across human and agent-driven workflows.
• Examples of how repeated hallucinations spread across repositories and why that makes central governance necessary.

👉 The full Xygeni article covers attack evolution, repeatability evidence, and practical prevention steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to software supply chain risk and operational policy.