Notifications
Clear all
Topic starter
19/08/2026 3:36 pm
TL;DR: AI supply chain security is shifting from a niche AppSec concern to an operational governance problem as Xygeni cites research showing 205,474 fake package names were generated in a USENIX study, making hallucinated dependencies and malicious registries a predictable attack path. The real issue is that AI now changes both what gets into the build and what defenders can credibly govern.
NHIMG editorial — based on content published by Xygeni: AI supply chain security and the hidden risks of hallucinated dependencies
By the numbers:
- In a controlled USENIX Security 2025 study, researchers found that 205,474 unique fake package names were invented across 576,000 AI-generated code samples.
- Compromised credentials surged roughly 160% in 2025 versus 2024, showing how quickly AI-assisted attack methods are feeding into software environments.
- Only 37% of organisations had a formal policy for safe AI use in security stacks, even as 77% were already running generative AI there.
Questions worth separating out
Q: How should security teams govern AI-generated code in production pipelines?
A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact.
Q: Why do AI coding agents increase supply-chain risk?
A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment.
Q: What do teams get wrong about AI agent access in MCP environments?
A: Teams often focus on the agent interface and ignore the identity objects that actually authorize actions.
Practitioner guidance
- Inventory AI-connected SDLC assets Build an AI-BOM that lists models, coding assistants, agents, MCP servers, and the developer endpoints that can reach them.
- Block hallucinated dependencies before install Add controls that compare AI-suggested package names against approved registries and internal allowlists, then require human review for any dependency that is not resolved or known-good.
- Inspect package behaviour at install time Use behavioural detection to score install scripts, network calls, and obfuscation before execution, because signature-based scanning cannot keep pace with short-lived malicious packages.
What's in the full article
Xygeni's full research covers the operational detail this post intentionally leaves for the source:
- The paper's full breakdown of the USENIX experiment methodology and prompt patterns behind hallucinated package names
- Operational examples of behaviour-based malware detection across registries and install-time execution
- The article's treatment of MCP, AI-BOM inventorying, and developer workflow exposure in more implementation detail
- Xygeni's explanation of how its MEW and Shield components map to supply chain control points
👉 Read Xygeni's analysis of AI supply chain security and hallucinated dependencies →
AI supply chain security: what does it mean for IAM and AppSec?
Explore further
19/08/2026 4:17 pm
AI supply chain security is now an identity governance problem, not only an AppSec problem. The article shows that models, agents, registries, and MCP servers are now acting like governed actors inside the SDLC. That means the relevant control question is who or what is authorised to introduce dependencies, invoke tools, and reach secrets. Teams that do not inventory these actors are already behind the risk.
A question worth separating out:
Q: How do organisations reduce secret leakage from AI-assisted code generation?
A: Keep secrets out of prompts and local model context, then scan generated code and build artifacts for tokens before merge. When a secret does appear, rotate it immediately and investigate which assistant, agent, or workflow exposed it. The key is to treat generated output as a disclosure surface, not a trusted artifact.
👉 Read our full editorial: AI supply chain security is now an identity and governance problem
