Topic starter
02/08/2026 11:59 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “What is Slopsquatting? The AI Package Hallucination Attack Already Happening”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Slopsquatting turns package-name hallucinations into a real attack path by turning AI suggestions into installable dependencies.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:06 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Slopsquatting is turning AI package hallucinations into real supply chain risk