Slopsquatting is turning AI package hallucinations into real supply chain risk

At a glance

What this is: Slopsquatting is a package supply chain attack that exploits AI-generated hallucinated dependency names and can turn them into real malicious installs.

Why it matters: It matters because AI-assisted development, CI pipelines, and agentic coding workflows can convert a model mistake into credential exposure, hidden malware, and unmanaged non-human access paths.

By the numbers:

• Researchers at USENIX Security 2025 tested 16 models across 576,000 code samples and found that hallucinations follow predictable patterns: 38% are conflations like express-mongoose, where the model mashes two real things together, 13% are typo variants, and 51% are pure fabrications.
• In early 2024, huggingface-cli got more than 30,000 authentic downloads in three months after researchers proved the hallucinated package name could spread in the wild.
• As of early February, the malicious unused-imports package was still pulling 233 downloads a week.

👉 Read Aikido's analysis of slopsquatting and AI package hallucinations

Context

Slopsquatting is a software supply chain problem created by AI-generated package hallucinations. When a model invents a dependency name with confidence, developers and AI agents can be steered toward a package that looks plausible enough to install, even though it was never the intended library. That matters because package install is an access event as much as a code event, especially when environment secrets and CI permissions are present.

The identity angle is direct: the attack converts trusted automation into a non-human execution path that can inherit credentials, tokens, and broad install permissions. In practice, this blurs the boundary between application security and NHI governance, because the package manager, pipeline, and agent become part of the identity control surface. That starting position is increasingly typical in AI-assisted development rather than an edge case.

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 AI-generated package choices create more supply chain risk than normal developer workflows?

A: Because the agent can move from intent to execution without the human judgment step that usually filters suspicious packages. That widens exposure to typosquatting, slopsquatting, and malicious install scripts. The risk is highest when the agent also has access to tokens, signing keys, or repository write permissions.

Q: What do security teams get wrong about slopsquatting?

A: They focus on whether the package name looks plausible instead of whether the publisher is trusted. Slopsquatting succeeds when familiarity substitutes for verification. A package can have a clean appearance, a convincing name, and even some downloads while still being malicious or unmaintained. The right control is publisher validation plus install-time policy, not name checking alone.

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 are exploitable

LLMs do not validate package existence or maintainer authenticity by default. They generate likely-looking names from training patterns, which means a fabricated dependency can sound more credible than a real one if it fits the task. Attackers exploit that by registering names the model is likely to invent, then waiting for a developer or agent to follow the recommendation. The risk is highest when the package name is not obviously malicious and when the install path is treated as routine rather than privileged.

Practical implication: Treat model-suggested dependencies as untrusted input until the publisher and namespace are verified.

Why install-time payloads evade simple scanning

Many malicious packages do not need obvious source code to be dangerous. A package can execute a post-install script, fetch remote content through URL-based dependencies, or trigger behaviour only when installed in a real environment. That makes static review weaker than practitioners expect, because the malicious action may sit in metadata, lifecycle hooks, or remote retrieval paths rather than in readable package files. This is especially relevant in JavaScript ecosystems where install-time execution is common.

Practical implication: Inspect package lifecycle hooks and external fetch behaviour, not only source files and direct dependencies.

How agentic coding turns a recommendation into execution

When an AI agent can install packages, edit files, or run build commands without approval, the model's suggestion becomes a direct execution path. That shifts the problem from recommendation quality to delegated authority. In identity terms, the agent is acting with inherited privileges, often in CI or developer environments where secrets, cloud tokens, or npm credentials are already present. The control failure is not hallucination alone. It is granting installation rights without a verification boundary.

Practical implication: Restrict autonomous package installation and require confirmation for any install command that can reach production credentials.

Threat narrative

Attacker objective: The attacker wants to convert AI-generated trust into secret theft and durable supply chain access through a package install path.

1. Entry occurs when a developer or AI agent accepts a hallucinated package name from a model recommendation and installs it as if it were legitimate.
2. Credential access follows when the package's install-time code reads environment variables, API keys, cloud tokens, or npm authentication material.
3. Impact occurs when the stolen secrets are exfiltrated or used to implant further malicious dependencies, extending compromise across repositories and pipelines.

NHI Mgmt Group analysis

Slopsquatting is a governance failure, not just a model error. The technical novelty matters less than the control failure it exposes. If AI can invent dependencies that developers then trust, the organisation has allowed model output to bypass package provenance checks. That makes dependency verification part of identity governance for build systems and agentic workflows. Practitioners should treat AI-suggested installs as an access decision, not a convenience feature.

Autonomous installation creates a non-human identity problem inside the software supply chain. A package manager invoked by an AI agent can carry broad privileges without the review discipline applied to human action. That creates a standing-authority problem similar to over-permissioned service accounts, except it is hidden inside development tooling rather than IAM consoles. The implication is straightforward: if the workflow can install, it can also exfiltrate, so privilege boundaries must be explicit.

Package provenance is becoming more important than package popularity. Download counts and familiar names are weak signals when hallucinations and copy-pasted instructions can manufacture legitimacy. The named concept here is hallucinated dependency provenance gap: the mismatch between a package's apparent usefulness and its verified origin. Once that gap exists, registries and scanners need publisher trust, namespace validation, and install-time policy to close it. Practitioners should re-rank provenance above familiarity.

AI-assisted development is expanding the attack surface faster than traditional AppSec controls are adapting. Static analysis, SCA, and human code review all help, but none of them alone stop a model from recommending a real malicious package or an agent from installing it with credentials attached. The operational conclusion is that secure coding controls must now cover model prompts, dependency resolution, and pipeline permissions together, not as separate concerns.

NHI governance now extends into build and CI identity. API keys, cloud tokens, and npm auth tokens sitting in environment variables are effectively standing non-human privileges that a malicious install can consume immediately. That bridges secrets management and software supply chain security in a way many teams still treat as separate workstreams. Practitioners should align secrets scope, install approval, and runtime containment under one control model.

What this signals

Hallucinated dependency provenance gap: AI-assisted development is creating a new trust problem where the apparent plausibility of a package name matters less than the verified origin of the package itself. That should push teams to treat dependency resolution like an identity decision, with publisher trust, namespace control, and install-time policy enforced before code ever runs.

The practical signal for programmes is that secrets exposure now starts earlier in the toolchain than many controls assume. If build systems and agentic workflows have access to environment secrets, then a single unsafe install can turn model error into credential compromise. Teams should align dependency controls with secrets minimisation and privileged access governance, not leave them in separate workstreams. See the patterns in the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs , Why NHI Security Matters Now.

For practitioners

• Verify package publisher and namespace before installation Require maintainers, registration age, and namespace ownership checks for any package suggested by an LLM or coding agent. Block installs when the package is new, unclaimed, or inconsistent with the expected ecosystem lineage.
• Restrict autonomous install privileges in agentic workflows Separate package installation rights from code generation rights, especially in CI and agent-assisted development. If an agent can run npm install, it should do so only under scoped credentials and with an approval boundary for new dependencies.
• Scan nested dependencies and install-time hooks Use SCA tooling that inspects the full dependency tree, lifecycle scripts, and remote retrieval paths. Hidden malicious packages often appear below the top-level manifest, where a quick review will miss them.
• Reduce the secret blast radius in build environments Assume any install-time execution can read exposed environment variables. Minimise API keys, cloud tokens, and npm credentials available during dependency resolution, and isolate build contexts from production-level secrets.

Key takeaways

• Slopsquatting turns AI package hallucinations into a real supply chain entry point when teams trust model-generated names without verifying the publisher.
• The attack becomes materially worse when install-time execution can reach environment secrets, cloud tokens, and other non-human credentials.
• Controls should focus on provenance, scoped install privilege, and secret minimisation in build environments, not just on code review or package popularity.

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 Dependency Provenance Gap: The hallucinated dependency provenance gap is the difference between a package name that appears credible and a package origin that has never been verified. It becomes dangerous when model suggestions, automation, and install-time execution let plausibility outrun source validation.
• Install-Time Payload: An install-time payload is malicious behaviour that runs when software is installed rather than when it is later executed. This matters because package lifecycle hooks can read environment secrets, fetch remote content, or implant code before standard review tools have a chance to inspect the final state.
• Agentic Coding Workflow: An agentic coding workflow is a development process where an AI system can generate code, choose tools, and trigger actions such as package installation. The security issue is delegated authority, because the agent may inherit permissions and secrets that a human would normally review.

What's in the full article

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

• The specific npm examples and hallucinated package patterns that researchers observed in the wild
• The package-level detection and SafeChain workflow Aikido describes for intercepting installs before they run
• The developer-facing examples showing how AI suggestions turn into accidental dependency installs
• The practical context behind the real malicious packages and the downloads they continued to receive

👉 The full Aikido post covers package examples, attacker patterns, and practical safeguards for dependency installs.

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 the build and automation systems that now shape software risk.