Notifications
Clear all
Topic starter
19/08/2026 3:43 pm
TL;DR: AI coding models are repeatedly inventing package names that attackers can register before developers verify them, turning hallucinations into a supply chain risk, according to Xygeni's analysis. The governance gap is no longer package discovery alone but controlled verification of AI-suggested dependencies before they reach build and runtime systems.
NHIMG editorial — based on content published by Xygeni: slopsquatting attacks and the evolution of AI package hallucinations
Questions worth separating out
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 repeated package hallucinations matter to AppSec teams?
A: Repeated hallucinations matter because they are predictable.
Q: How can security teams reduce the risk from agent-driven package installs?
A: They should require policy gates for any first-time dependency, especially when an AI agent proposes the install.
Practitioner guidance
- Implement first-time dependency verification Require registry existence checks, maintainer review, publication age review, and package history review before any AI-suggested dependency is approved for use.
- Block hallucinated package names centrally Build a denylist of invented or suspicious package names seen in prompts, pull requests, and build logs, then enforce it in SCA and CI policy so repeated hallucinations cannot slip into multiple repositories.
- Gate autonomous installs with approval policy Prevent coding agents from installing new packages without a human checkpoint or a pre-approved allowlist, especially where the dependency was not already present in the organisation's standard software catalogue.
What's in the full article
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how hallucinated package names propagate from AI prompts into real registries and build pipelines.
- The specific prevention workflow for verifying package provenance, maintainer history, and suspicious install behaviour.
- Practical SCA and CI policy patterns for blocking invented dependencies across human and agent-driven workflows.
- Examples of how repeated hallucinations spread across repositories and why that makes central governance necessary.
👉 Read Xygeni's full analysis of slopsquatting attacks and AI package hallucinations →
Slopsquatting attacks and package hallucinations: what teams need to do?
Explore further
19/08/2026 4:21 pm
Slopsquatting is an identity-adjacent supply chain problem because the trust decision happens before code ever runs. The real failure is not package installation alone. It is the assumption that a model-generated dependency suggestion has the same provenance as a vetted dependency, which it does not. AppSec teams need to treat dependency naming as a trust boundary, not a convenience feature.
A question worth separating out:
Q: Who is accountable when an AI assistant follows malicious repository instructions?
A: Accountability sits with the organisation that allowed mutable instructions to act as standing authority without governance. If a project file can change agent behaviour, then ownership of that file, its review process, and its execution scope must be defined. Without that, the organisation has delegated security decisions to uncontrolled context.
👉 Read our full editorial: Slopsquatting attacks are turning AI package hallucinations into real risk
