Slopsquatting exposes a new software supply chain risk for AI coding

At a glance

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

Why it matters: It matters because AI-assisted development and autonomous agents can convert a simple dependency suggestion into code execution, secret theft, and build compromise if install-time controls are weak.

By the numbers:

• A peer-reviewed USENIX Security 2025 study found that 19.7% of recommended packages did not exist across 576,000 generated code samples.
• The same study found that 43% of fake package names reappeared across repeated prompts, making hallucinated dependencies predictable enough to weaponise.
• A 2023 experiment saw a placeholder package under a hallucinated name downloaded more than 30,000 times in three months.

👉 Read Xygeni's analysis of slopsquatting and AI-suggested package risk

Context

Slopsquatting is a software supply chain attack in which an attacker registers a package name that an AI coding assistant invents but a registry does not yet contain. The primary governance failure is trust in generated dependency suggestions without independent validation, especially where developers or agents can install packages automatically.

For IAM and NHI practitioners, the intersection is real: autonomous coding agents, build bots, and developer tooling often authenticate to registries using service accounts, tokens, and secrets. Once a hallucinated dependency is installed, the attacker can reach the same credential estate that protects source code, CI pipelines, and deployment workflows.

The pattern is not limited to one ecosystem or one model. The article’s starting position, where a harmless placeholder package gained thousands of downloads, is atypical as a proof of concept but typical as a warning about how quickly AI-driven dependency trust can be abused.

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 shared credentials create compliance risk for NHI and IAM teams?

A: Shared credentials destroy identity attribution, which means the environment can no longer prove which person or system performed a given action. That weakens access review, offboarding, and incident response at the same time. For NHI and IAM teams, the risk is not only compromise but also the inability to produce defensible evidence.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

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 AI package hallucinations become a supply chain entry point

Large language models do not validate package existence in real time unless the surrounding toolchain gives them that capability. They generate plausible names based on language patterns, training data, and prompt context, which means the output can look authoritative even when the package is fake. Attackers exploit that predictability by observing repeated hallucinations, registering the names, and waiting for a developer or agent to install them. The technical risk is not the suggestion itself, but the trust chain that converts a suggestion into execution.

Practical implication: block dependency installation unless the package is verified against an approved registry, maintainer, and provenance source.

Why install hooks matter more than package names

Modern package ecosystems allow code to run during install, build, or post-install phases. That makes the package name only the first control point. A slopsquatted package can look harmless in metadata and still execute a payload as soon as it is fetched, letting the attacker exfiltrate secrets, open a shell, or tamper with the developer workstation or build agent. Behavioural analysis is therefore more useful than signatures alone, because brand-new malicious packages often appear before any reputation data exists.

Practical implication: inspect install-time behaviour and network activity, not just package reputation or CVE presence.

AI-BOMs and dependency firewalls in AI-assisted development

An AI-BOM inventories the AI tools, agents, and automated workflows that can introduce software into a pipeline. That matters because the risk is no longer limited to human developers typing install commands. Autonomous agents can chain prompts, resolve dependencies, and publish artefacts with far less friction than a person, expanding the number of points where an unverified package can enter. A dependency firewall adds a policy layer that quarantines new or suspicious packages before they reach builds or endpoints.

Practical implication: treat AI-assisted development as part of the software supply chain and enforce policy at the registry boundary.

Threat narrative

Attacker objective: The attacker wants to turn an AI-generated dependency suggestion into authenticated code execution inside the developer or build environment.

1. Entry occurs when an attacker identifies hallucinated dependency names that AI coding assistants repeatedly suggest for common tasks.
2. Escalation occurs when the attacker registers a malicious package under that name and prepares install-time code to run on fetch.
3. Impact occurs when a developer or autonomous agent installs the package, allowing secret theft, backdoor placement, or downstream build compromise.

NHI Mgmt Group analysis

Slopsquatting is a governance failure, not just a malware problem. The core issue is that AI-generated dependency advice is being treated as though it were a validated software control. That assumption breaks the normal supply chain model because the package name is created outside the registry and only becomes dangerous once human or agentic trust converts it into execution. Practitioners should read this as a dependency-governance problem that spans AI tooling, developer endpoints, CI/CD, and registry policy.

Predictable hallucinations create a named concept we should now call dependency suggestion trust gap. When the same fake package names recur across prompts, the attacker does not need to guess what to weaponise. That predictability turns model output into a stable attack surface and makes provenance checks and approval workflows mandatory rather than optional. The practical conclusion is that organisations must stop assuming AI-generated software names have any baseline legitimacy.

Autonomous coding agents amplify the blast radius because they collapse the human review step. A person may pause before installing an unfamiliar package, but an agent can resolve, fetch, and execute dependencies in one run. That means the trust boundary moves from developer judgement to machine policy enforcement. For identity teams, the intersection is the service account, token, or workload credential that authorises the agent to reach registries and build systems.

Install-time control is the decisive point of failure containment. Signature-based detection alone cannot protect a brand-new malicious package with no history. The article illustrates why behavioural scoring, pre-install quarantine, and provenance enforcement are now core supply chain controls. Practitioners should treat the registry boundary as a policy enforcement point, not a convenience layer.

What this signals

Dependency suggestion trust gap: AI-assisted development now creates a new control plane for software intake, and that control plane needs policy, provenance, and registry enforcement rather than informal developer judgement. For identity teams, the key question is whether machine credentials can introduce code without the same approval rigor required for human users. See also the Top 10 NHI Issues and the MITRE ATT&CK Enterprise Matrix.

The practical programme signal is that software supply chain security and NHI governance are converging around the same enforcement point: who or what is allowed to install, publish, or promote code. When agents can act on behalf of developers, credential scope and short-lived authorization become as important as malware detection.

AI-BOMs will become more useful as a governance inventory than as a documentation exercise. Teams that can identify every agent, token, and endpoint allowed to fetch dependencies will be better placed to stop hallucinated packages before they become an incident.

For practitioners

• Verify every AI-suggested dependency before installation Require a human or automated policy check that confirms the package exists, is maintained, and matches an approved source before any install command runs. This is especially important for packages suggested inside IDE assistants or agentic coding workflows.
• Enforce install-time behavioural screening Score new packages on install hooks, network calls, obfuscation patterns, and other suspicious runtime traits at publish time, then quarantine unknown packages before they reach developer endpoints or CI jobs.
• Inventory AI tools with an AI-BOM Track which coding assistants, agents, and automation chains can introduce dependencies, and bind their registry access to short-lived credentials with explicit policy approval for new package sources.
• Place a dependency firewall in front of public registries Block or delay first-time packages, newly seen names, and packages outside approved registries until they pass policy checks. This gives security teams a chance to stop hallucinated dependencies before execution.

Key takeaways

• Slopsquatting works because AI hallucinations are predictable enough to be registered and weaponised before developers notice.
• The scale is already material, with one study finding nearly one in five recommended packages did not exist and many fake names recurring across prompts.
• The control that matters most is policy enforcement at install time, backed by provenance checks, behavioural screening, and AI-BOM visibility.

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.
• 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.
• 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.

What's in the full article

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

• The exact slopsquatting attack chain and how hallucinated package names are harvested in practice
• The endpoint and install-time blocking approach used to stop malicious packages before post-install scripts run
• The role of Malware Early Warning verdicts in classifying brand-new packages before signatures exist
• The practical deployment context for developer workstations and build environments

👉 The full Xygeni article covers the attack flow, defensive controls, and package abuse patterns in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the software supply chain and automated development workflows.