AI supply chain security is now an identity and governance problem

At a glance

What this is: This is an analysis of how AI is reshaping software supply chain risk, with fake package names, malicious registries, MCP exposure, and AI-generated secrets becoming operational attack paths.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly need visibility into AI tools, agents, and delegated access inside the SDLC, not just human users and static pipelines.

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.

👉 Read Xygeni's analysis of AI supply chain security and hallucinated dependencies

Context

AI supply chain security is the discipline of controlling the risk created when artificial intelligence writes, selects, or connects code and tools inside the software delivery chain. The governance gap is that most programmes still separate application security, developer tooling, and AI oversight, even though the attack surface now spans all three.

The article’s core finding is that hallucinated dependencies, malicious package registration, MCP exposure, and secret leakage are no longer edge cases. For IAM and NHI practitioners, that means the relevant question is not only who can deploy code, but what machine identities, agents, and delegated connections can introduce or consume it.

This is a genuine cross-domain problem, but the identity angle is real: AI coding tools, agents, package registries, and MCP servers all behave like governed actors that can be overprivileged, untracked, or misused. That makes this topic especially relevant for teams responsible for secrets, workload identity, and privileged access.

Key questions

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. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.

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. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

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. The common mistake is assuming the protocol replaces credential governance, when in fact it depends on it. If ownership, rotation, and revocation are not defined, the organisation inherits hidden access paths that are hard to audit and harder to remove.

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.

Technical breakdown

Slopsquatting turns hallucinated packages into a repeatable attack path

Slopsquatting is the practice of registering package names that AI coding assistants invent but developers assume are real. Because those hallucinations repeat, attackers can wait for a model to suggest the same nonexistent dependency, then publish a malicious package under that name. The control failure is not just typosquatting hygiene. It is a governance gap in how code assistants influence dependency selection, especially when autonomous agents can install packages without human review. In effect, AI creates a new pre-commit trust layer that traditional AppSec did not inventory.

Practical implication: track AI-generated dependency suggestions as a supply chain risk, not a convenience feature.

MCP expands the trusted tool boundary for AI agents

The Model Context Protocol connects agents to tools and data sources, but it also creates a machine-readable trust boundary that many security tools do not inspect. A malicious or unauthenticated MCP server can expose tools and data to any agent that can reach it, especially when local developer environments and shared runtimes are poorly segmented. This is not a simple API security issue. It is an identity and authorisation problem for non-human actors whose access may be delegated indirectly through the agent runtime. The control gap is invisible connectivity without lifecycle governance.

Practical implication: inventory MCP endpoints and bind them to explicit access policy, authentication, and logging.

Behavior-based malware detection is replacing signature dependence

AI-assisted supply chain attacks move too fast for traditional signature-first detection to keep up. Behaviour-based systems inspect what a package does at install time, such as network calls, obfuscation patterns, and unexpected filesystem activity, instead of waiting for a known-bad hash or CVE. That matters because many malicious packages exist only briefly before takedown, yet still reach downstream builds. For defenders, the architectural shift is from static package trust to runtime trust scoring, where execution behaviour is the primary signal.

Practical implication: use runtime behavioural checks to gate package installation before the first script executes.

Threat narrative

Attacker objective: The attacker wants to turn AI-generated dependency suggestions and automated installs into a scalable route for code execution, secret theft, and supply chain compromise.

1. Entry occurs when an attacker registers a package name that AI assistants have repeatedly hallucinated, then waits for developers or agents to install it.
2. Escalation occurs when the malicious package runs install-time code, reaches developer tooling, or captures secrets from the build context and surrounding environment.
3. Impact occurs when compromised dependencies, leaked credentials, or poisoned toolchains propagate into downstream builds and production systems.

NHI Mgmt Group analysis

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.

Slopsquatting creates a new kind of trust debt. AI hallucinations are not random noise when the same fake package names recur across prompts. That repeatability gives attackers a reliable registration strategy and turns model output into an exploitable dependency-control weakness. The named concept here is hallucinated dependency reuse, and it should be treated as a supply chain governance defect.

MCP exposes an under-governed machine identity layer. The protocol is useful because it lets agents reach tools and data sources, but every connection expands the set of identities, permissions, and audit events that security teams must manage. This is where OWASP-NHI and broader access governance meet AI operations: if an agent can call a tool, it needs lifecycle control like any other privileged workload.

Behavior-based package screening is becoming the minimum viable defensive posture. High-volume malicious-package campaigns are designed to outrun signatures, so the governance model must shift from post-publication cleanup to pre-execution decisioning. That is not a tooling preference. It is a recognition that the attack window is now shorter than many review workflows.

AI-BOM is the right inventory construct for this problem. Most organisations can name cloud platforms and endpoint tooling, but not every model, agent, or MCP server reachable from a developer workstation. The field needs a separate bill of materials for AI-connected assets because without that inventory, secrets, package trust, and delegated access cannot be governed coherently.

What this signals

Hallucinated dependency reuse will become a practical governance metric. If the same fake package names keep surfacing across prompts, security teams need to treat model output as an attacker-readable signal and fold it into dependency policy, especially where AI agents can install software without review.

The operational centre of gravity is shifting toward pre-execution control. Teams that rely on after-the-fact scanning will keep losing the race to short-lived malicious packages, while programmes that tie package trust, MCP authorisation, and secret hygiene together will create a smaller attack surface.

For identity teams, the lesson is that machine identities now extend into developer workflows, not just runtime services. Inventory, credential scope, and auditability need to cover the AI tooling layer or the rest of the control stack will be incomplete.

For practitioners

• 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. Treat each as a governed asset with owner, purpose, and access scope.
• 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.
• Govern MCP access like privileged tooling Require authentication, logging, and explicit authorisation for every MCP server and tool connection, and review whether agent access inherits more privilege than the task requires.
• Reduce secret exposure in AI-assisted development Keep secrets out of prompts, local context files, and training inputs, then rotate any token that appears in generated code or shared model context.

Key takeaways

• AI supply chain security is emerging as a governance problem because models can now influence what code, packages, and tools enter the build.
• Predictable hallucinated package names and fast-moving malicious registries make behaviour-based controls more effective than signature-first scanning.
• Teams need an AI-BOM, MCP inventory, and tighter secret handling to govern non-human actors inside the SDLC.

Key terms

• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Behavior-based malware detection: Behavior-based malware detection evaluates what a package or process does when it runs, rather than waiting for a known signature. It is especially useful for short-lived supply chain attacks because malicious code often appears and disappears before static signatures are available.

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

👉 The full Xygeni article covers slopsquatting, MCP exposure, and defensive controls in more depth.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners build the governance discipline needed for machine identities, delegated access, and AI-connected systems.