TL;DR: 19.7% of AI-recommended packages did not exist, and 43% repeated across prompts, in Xygeni's read of USENIX Security 2025 data. Package controls need to stop installs before a suggestion can reach the registry.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “What Is Slopsquatting? How Attackers Weaponize AI Hallucinations”.
Key questions
Q: Why do AI hallucinations create supply chain risk for developers?
A: Because a hallucinated package name can be predictable enough for an attacker to register first.
Q: What are the signs that AI-suggested dependency controls are failing?
A: Warning signs include repeated installs of unfamiliar packages, agent-driven dependency changes without human review, and new packages appearing in builds before any internal validation step.
Q: What is the first control teams should add to stop slopsquatted packages?
A: Start by requiring validation before any AI-suggested dependency can be installed.
Practitioner guidance
- Validate AI-suggested packages before install Require developers and agents to confirm that a suggested dependency exists, is maintained, and matches the intended repository before any install command runs.
- Block unauthorised dependency installs by policy Use a dependency firewall or equivalent admission control so brand-new, low-reputation, or unapproved packages are quarantined before they reach build steps.
- Inventory AI tools and agents in the build path Record which coding assistants, copilots, and autonomous agents can recommend or install packages, then define which of them are allowed to act without review.
Bottom line: AI package hallucinations become exploitable when attackers register the same names first and wait for developers or agents to install them.
Glossary terms: Slopsquatting, Hallucinated Dependencies, Credential firewall, AI-BOM
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Slopsquatting is a governance problem, not just a model-quality problem. The central failure is that organisations allow AI output to influence package selection without a corresponding trust decision. That creates a new control gap between code generation and dependency admission. The practitioner conclusion is that dependency governance now has to extend to AI suggestions, not just published packages.
A question worth separating out:
Q: How should organisations govern autonomous agents that install packages?
A: Treat package installation as a privileged action that must be explicitly authorised for each agent. Separate suggestion from installation, require approval for new dependencies, and log which non-human identity performed the action. If an agent can both choose and fetch packages, it should be governed like any other high-risk installer.
👉 Read our full editorial: Slopsquatting exposes a new software supply chain risk for AI coding