TL;DR: AI hallucinations are now producing package names that attackers can register and weaponise, turning developer trust in model-generated suggestions into a supply chain risk, according to Aikido. The governance gap is that autonomous or semi-autonomous installation workflows can turn a single hallucinated dependency into credential theft, hidden payload delivery, or broader NHI abuse.
At a glance
What this is: Slopsquatting exploits AI-generated package hallucinations by registering invented dependency names and turning mistaken installs into credential theft or payload delivery.
Why it matters: It matters because AI-assisted coding and agentic install flows can turn a single hallucinated dependency into a software supply chain compromise that also exposes NHI secrets and cloud tokens.
Context
Slopsquatting is a supply chain abuse pattern where an attacker monetises model error rather than human typo. The issue is not only that an AI can suggest a fake package name, but that modern developer workflows increasingly treat model output as an installation hint, which collapses the normal verification step between suggestion and execution.
For IAM and NHI teams, the security boundary matters at the point of install authority. If an agent, CI job, or developer tool can install packages with access to API keys, cloud tokens, or npm credentials, a hallucinated dependency can become a credential exposure event before any human review occurs.
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 mobile apps increase exposure to supply-chain and identity risk?
A: Mobile apps reuse SDKs and libraries across many deployments, so one compromised dependency can affect many apps and backend services at once. That matters for identity because a dependency may inherit tokens, sessions or API access paths. Teams should map every dependency to the identities and services it can reach, then monitor that chain continuously.
Q: What are the signs that slopsquatting is entering a codebase?
A: Watch for package names that do not have a credible maintainer, appear suddenly in generated instructions, or are copied across repositories without a clear source. A second signal is unexpected installs in agentic or automated workflows, especially when the dependency is plausible in name but absent from normal ecosystem patterns.
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
How hallucinated package names become executable supply chain risk
Slopsquatting works when an attacker registers a package name that large language models tend to invent, then waits for that name to be used in a real install path. The technical trap is that the package name itself may look plausible even though no legitimate maintainer exists. Once installed, a malicious package can run post-install code, fetch payloads from a remote location, or remain deceptively clean while relying on dependency resolution to pull harmful code later. That makes the attack effective against both humans and automated agentic workflows that trust generated dependency suggestions.
Practical implication: Treat any AI-suggested dependency as untrusted until the publisher, provenance, and install path have been independently verified.
Why autonomous installation authority changes the threat model
The risk becomes materially worse when AI agents, coding assistants, or CI pipelines can install packages without an approval step. In that model, the attacker is no longer relying on a human typo or curiosity, but on the system's own authority to continue execution. That removes the natural pause where a developer might notice an odd package name. It also means the attacker does not need to win every time. A small number of successful hallucinated installs can expose secrets, seed a backdoored dependency tree, or propagate across repositories through copied instructions and generated code.
Practical implication: Reduce package-install permissions for agents and pipelines to the minimum scope needed for their task.
Why dependency-tree visibility matters more than package.json review
Many malicious or hallucinated dependencies will not appear as top-level entries in a project manifest. They can arrive as transitive packages, generated install commands, or nested dependencies buried inside automated workflows. That means a surface-level review of package.json is insufficient. Teams need visibility into the full dependency tree and into the conditions under which a package was introduced, including whether a human or an AI system triggered the install. In slopsquatting incidents, the control point is not just identification of a bad name, but detection of how that name entered the build or runtime path.
Practical implication: Scan the full dependency tree and tie install events back to the identity that approved or executed them.
Threat narrative
Attacker objective: The attacker wants to turn model-generated dependency trust into code execution and secret theft inside software delivery workflows.
- Entry occurs when an AI model hallucinates a package name and a developer or agent uses that name in an install command.
- Credential access follows when the installed package harvests API keys, cloud tokens, or npm auth tokens from the environment.
- Impact occurs when stolen secrets or a hidden payload are used to extend access, compromise builds, or persist in downstream repositories.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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 best understood as trust abuse at the dependency boundary. The attack does not need a novel exploit in the registry or the runtime. It only needs a believable package name and a workflow that treats generated output as installable. That is why the problem sits squarely at the intersection of AI governance, software supply chain security, and NHI secret exposure.
Autonomous installation authority is the real control gap. The same hallucinated name is far less dangerous when a human must confirm provenance before execution. Once an AI agent or CI job can proceed without that check, the organisation has effectively delegated package selection to a non-human actor that cannot distinguish confidence from correctness. Practitioner conclusion: remove installation authority from paths that cannot justify it.
Dependency hygiene is no longer just a software engineering concern, it is an identity and privilege problem. A package install can expose cloud tokens, npm auth tokens, and other secrets that were never meant to leave the build context. The governance question is therefore who or what is allowed to trigger installs, with what permissions, and under which verification rules. Practitioner conclusion: govern package installs as privileged actions.
Slopsquatting shows that model hallucination has become an externally exploitable security input. The named concept here is hallucinated dependency trust gap: the distance between an AI system's confident recommendation and the real-world legitimacy of the package it names. That gap is now large enough for attackers to operationalise. Practitioner conclusion: make provenance, not plausibility, the acceptance criterion.
What this signals
Hallucinated dependency trust gap: security teams now have to govern the distance between model confidence and package legitimacy. The practical response is to move trust decisions from model output to publisher verification, provenance checks, and install-time controls, because plausibility is not evidence.
AI-assisted development changes the timing of control failure. In classic typosquatting, the mistake is human and visible; in slopsquatting, the error can be generated, repeated, and propagated by non-human workflows before anyone notices. That makes install authority, not package naming alone, the control surface that matters most.
For practitioners
- Verify package publisher and provenance Check who registered the package, when it was first published, and whether that publisher matches the expected maintainer before any install is allowed.
- Restrict autonomous install authority Remove blanket npm, npx, yarn, and pnpm install permissions from agents and CI jobs that do not need them, and require explicit approval for new dependencies.
- Scan the full dependency tree Use software composition analysis to inspect transitive dependencies and nested packages, not just top-level manifest entries.
- Gate secret exposure in build contexts Keep API keys, cloud tokens, and npm auth tokens out of environments where package installation can run, especially in agentic or unattended workflows.
Key takeaways
- Slopsquatting turns package-name hallucinations into a real attack path by turning AI suggestions into installable dependencies.
- The risk is amplified when agents or CI systems can install software with access to cloud tokens, API keys, or npm credentials.
- Governance has to shift from checking names after the fact to controlling who can install, what they can install, and how provenance is verified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack steals secrets from environments where hallucinated packages are installed. |
| NHI-10 — Human Use of NHI | Human and agent-driven install flows can expose machine secrets through routine development work. | |
| NHI-07 — Long-Lived Secrets | Stolen cloud tokens and auth tokens remain useful when they are long-lived in build environments. | |
| Recommendation — Scan package-install environments for exposed secrets and revoke any credentials reachable during install. Limit human and agent access to NHI secrets during package installation paths. Shorten secret lifetimes so stolen build credentials expire before they can be reused. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern depends on harvesting secrets and sending them out of the environment. |
| Recommendation — Map hallucinated-package incidents to credential-access and exfiltration detections in your build telemetry. | ||
| CIS Controls v8 | CIS-5 — Account Management | Install authority and secret-bearing accounts need tight lifecycle governance in automated workflows. |
| Recommendation — Use account-management controls to restrict which identities can approve or execute software installs. | ||
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.
- Transitive dependency exposure: Security exposure that arrives through an indirect software dependency rather than a package a team selected directly. It matters because the vulnerable code can exist in runtime paths that are easy to miss if governance only tracks top-level frameworks.
- 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. It is suitable for practitioners who need to connect identity controls to software delivery and AI-driven workflow risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org