Slopsquatting attacks are turning AI package hallucinations into real risk

At a glance

What this is: This analysis explains how slopsquatting weaponises AI-generated package hallucinations by turning invented dependency names into real registry abuse and supply chain exposure.

Why it matters: It matters because AppSec, DevSecOps, and identity-adjacent supply chain controls now have to govern what AI agents and developers are allowed to install, not just what they write.

By the numbers:

• 19.7% of the packages recommended by the models didn’t exist.
• Open-source models hallucinated far more often, 21.7% on average.
• When researchers re-ran identical prompts ten times each, 43% of hallucinated package names showed up on every single run.

Context

Slopsquatting is a supply chain problem created when an AI model invents a package name that looks plausible enough for a developer to trust. The security failure is not the hallucination alone, but the gap between suggestion and verification, because registry trust is assumed before dependency legitimacy is checked.

For identity and access teams, the important shift is that the install decision is now influenced by a non-human actor that can scale the same mistake across many workflows. That means governance must cover dependency intake, package provenance, and the privileges granted to automated tools that can fetch and install code.

The article's examples show that this is not a one-off coding error. It is an operating model issue that becomes more dangerous as AI assistants and coding agents make more of the dependency selection process feel routine.

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 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: What are the signs that package hallucination controls are failing?

A: Recurring first-seen dependencies, repeated installs of unfamiliar packages with no maintainer history, and AI-generated code that references libraries your registry checks cannot validate are all warning signs. If those packages are being accepted without provenance review, the control is not working.

Q: How should teams separate package suggestion from package installation in AI workflows?

A: Use AI to propose dependencies, but keep installation behind an approval gate that checks registry existence, ownership, version history, and policy. That separation reduces the chance that an autonomous tool can turn a hallucinated name into an executed trust decision.

Technical breakdown

How package hallucinations become a registry attack

A slopsquatting attack starts when an LLM recommends a package that does not exist, but sounds legitimate enough to pass casual scrutiny. The attacker monitors repeated hallucinations, registers the invented name in a public registry, and then waits for the next developer or agent to install it. At that point, the fake package becomes a real supply chain entry point. The core mechanism is not code execution by itself, but trust transfer from model output to registry legitimacy, which is why the attack scales when the same hallucination repeats across prompts.

Practical implication: treat AI-suggested dependencies as untrusted until existence, ownership, and provenance are independently verified.

Why repeatable hallucinations make slopsquatting scalable

The article's central technical point is repeatability. If a hallucinated name appears across many prompts, an attacker does not need to guess a unique target for each developer. They can register one package and harvest installs from many workflows. That changes slopsquatting from a novelty into a pre-positioned supply chain trap. In governance terms, the risk becomes measurable because recurring hallucinations can be catalogued, monitored, and blocked at intake time before they are ever used in build or runtime pipelines.

Practical implication: build controls that block recurring hallucinated names before they reach dependency resolution or automated installation.

Why AI coding agents raise the exposure level

AI coding agents extend the problem because they can act on package suggestions without the same human review that a copy-paste workflow might still receive. Once an agent has permission to install dependencies, the attack is no longer limited to human error at the keyboard. The article also notes that hallucinations now spread into repositories and agentic workflows, which means the trust boundary has moved from the developer workstation to the autonomous tool chain. That is a classic governance expansion: more speed, less review, and more inherited trust.

Practical implication: scope least privilege so agents can suggest code without automatically gaining install authority.

Threat narrative

Attacker objective: The attacker wants developers or AI agents to install a malicious package under a plausible hallucinated name so the code enters the build environment.

1. Entry occurs when a developer or AI agent asks for help solving a coding problem and receives a hallucinated dependency name.
2. Credential access is not the primary stage here, but the attacker gains a trust foothold by registering the invented package in a public registry before anyone verifies it.
3. Impact follows when the developer or agent installs the malicious package and introduces attacker-controlled code into the software supply chain.

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 supply chain governance failure, not just an LLM quality issue. The attack works because teams treat model output as a suggestion instead of an untrusted dependency claim. Once that suggestion enters package selection, the security boundary has already shifted from code generation to software intake control. Practitioners need to govern package provenance as part of build security, not as an afterthought.

Package hallucination repeatability creates a new control surface. The article makes clear that many hallucinations recur, which means defenders can move from anecdotal caution to pattern-based blocking. This is where the field needs to mature: the right control is not simply awareness, but repeatable verification gates for any AI-suggested dependency. Practitioners should treat recurring hallucinations as a known dependency class, not isolated mistakes.

AI coding agents introduce delegated install authority into the trust chain. When an agent can fetch and install a package, it inherits a privilege that many software teams never explicitly modelled. That makes this a non-human identity problem as much as a development problem, because the tool is effectively acting on behalf of the developer. Practitioners should separate code assistance from install privilege and review where delegated execution begins.

Slopsquatting widens the definition of software supply chain exposure. The risk is no longer limited to compromised maintainer accounts or poisoned upstream projects. It now includes invented packages that appear legitimate because a model said they existed. That is a new form of dependency confusion for AI-era workflows, and it demands provenance checks that are enforced before install, not after incident response. Practitioners should redesign dependency intake around verification by default.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Package hallucination control is becoming a supply chain governance discipline. Teams that still treat AI-suggested dependencies as harmless hints are underestimating how quickly a plausible name can become an installable threat. The practical shift is to verify every new dependency before it reaches the build system, especially when an AI assistant or agent suggested it.

AI-generated dependencies create a non-human trust problem as much as a software risk. When an agent can recommend and install packages, the governance question becomes who or what is allowed to consume external code on the organisation's behalf. That intersection between software supply chain security and delegated machine action is where new controls now need to land.

Dependency provenance should be enforced at the point of selection, not after deployment. If the package is not validated when it is suggested, the later controls are already too late to stop a malicious registry entry from entering the pipeline.

For practitioners

• Verify every AI-suggested package before install Check that the dependency exists in the official registry, has a real maintainer history, and matches the package name exactly before it is added to code or CI.
• Block unapproved dependency installation by agents Limit autonomous or semi-autonomous tools so they can recommend code but cannot install packages unless the dependency has passed a human review step.
• Add hallucinated-package detection to SCA Flag suspiciously novel package names, near-matches to existing libraries, and first-seen dependencies with no credible provenance in your software composition analysis workflow.
• Use lockfiles and hash verification Pin approved versions and verify hashes so a later registry change or package substitution cannot silently replace the dependency you reviewed.
• Train developers on AI dependency verification Make package verification a required step in AI-assisted coding workflows, with clear guidance that a working snippet is not proof of a legitimate dependency.

Key takeaways

• Slopsquatting turns model-generated package names into an attacker-controlled supply chain entry point when teams fail to verify the dependency before install.
• The article's evidence shows the risk is measurable and repeatable, which makes hallucination-driven package abuse suitable for policy-based blocking rather than ad hoc judgement.
• The most effective control is to separate AI suggestion from installation authority and force provenance checks before a dependency reaches build or runtime systems.

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.
• Autonomous Install Authority: Autonomous install authority is the ability of an AI agent or automated tool to fetch and install software without a human approving each dependency. It creates a governance boundary because the tool is no longer just assisting code generation. It is making trust decisions on the organisation's behalf.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners design the controls that matter when non-human systems influence access, trust, and execution.