Topic starter
19/08/2026 3:43 pm
TL;DR: Package hallucinations give attackers a repeatable way to register names developers may trust, according to Xygeni. The install boundary now needs provenance checks before AI-suggested dependencies reach build or runtime systems.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Slopsquatting Attacks: How an AI Mistake Became a New Way Into Your Software Supply Chain”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Slopsquatting turns model-generated package names into an attacker-controlled supply chain entry point when teams fail to verify the dependency before install.
Glossary terms: Slopsquatting, Package Hallucination, Dependency Provenance, Autonomous Install Authority
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
19/08/2026 4:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Slopsquatting turns package verification into a supply chain gate
This post was modified 1 day ago by NHI Mgmt Group