AI supply chain security is now an identity and governance problem

At a glance

What this is: Xygeni argues that AI supply chain security now spans package integrity, AI-generated code, MCP exposure, and the governance of models and agents across the SDLC.

Why it matters: IAM, AppSec, and platform teams need to treat AI tools, agents, and registry access as governable assets because hallucinated dependencies and uncontrolled connections create new attack paths.

By the numbers:

• Researchers asked 16 large language models to generate 576,000 code samples.

Context

AI supply chain security is the governance problem created when AI systems influence what enters the software build, what dependencies get trusted, and what can be reached from developer workflows. The core risk is not limited to malicious code in a registry. It also includes AI-generated suggestions, autonomous installers, and model-driven connections that expand the attack surface faster than traditional review can track.

This topic sits at the intersection of AppSec, IAM, and NHI governance because modern development environments now include non-human actors, machine-to-machine access, and third-party package trust decisions. Once those actors can select dependencies or reach registries without clear inventory and policy, the control problem shifts from code review to identity and access governance across the SDLC.

The article is a typical example of an emerging programme gap, not an edge case: the same environment that accelerates delivery also creates repeatable opportunities for dependency abuse and uncontrolled AI access.

Key questions

Q: How should teams respond when AI-suggested dependencies are introduced into builds?

A: Block the assumption that a recommended package is safe because it installs cleanly. Require malware-aware SCA, dependency graph review, and reachability filtering, then limit build promotion until the package has been validated against policy.

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. A developer might notice a strange package name and stop, but an agent can fetch, resolve, and install it immediately. That collapses the time available for review and makes install-time policy enforcement the decisive control.

Q: How should security teams use AI without turning it into a control dependency?

A: Security teams should use AI for summarisation, correlation, and prioritisation, then keep containment in deterministic controls such as access policy, segmentation, and revocation. The key rule is that AI can recommend action, but it should not be the only mechanism that can stop exposure. That separation reduces false confidence and preserves auditability.

Q: What is the difference between AI supply chain security and traditional application security?

A: Traditional AppSec mostly evaluates known vulnerabilities in known components. AI supply chain security also governs how AI affects dependency choice, tool connectivity, and package trust, which means it has to manage non-human actors as part of the software lifecycle. That shifts the control problem from code alone to identity, access, and provenance across the pipeline.

Technical breakdown

How hallucinated dependencies become an attack path

Large language models do not merely suggest code. They also suggest package names, install commands, and dependency patterns that developers may trust because they came from an assistant. When those names are fabricated but repeatable, attackers can pre-register them as malicious packages and wait for installs. This is the supply chain equivalent of exploiting a predictable false positive. The risk grows when autonomous coding agents can install packages without a human review step, because the last chance to notice an invented dependency disappears. In identity terms, the agent is acting as a non-human requester with implicit trust, even though its package choices were never independently governed.

Practical implication: Treat AI-driven dependency selection as a controlled identity and approval step, not a convenience feature.

Why MCP expands the software trust boundary

The Model Context Protocol creates a connective layer between AI agents and tools or data sources. That makes it useful, but also attractive to attackers, because any unauthenticated or weakly governed MCP server can become an invisible route into an agent workflow. The governance issue is not just whether the server exists. It is whether the agent can discover it, trust it, and reach it with privileges that were never designed for runtime tool chaining. This is where NHI governance meets AI security: the agent, its tokens, and its tool connections function like machine identities that need inventory, access boundaries, and revocation paths.

Practical implication: Inventory MCP servers and bound them to explicit access rules, ownership, and revocation controls.

Why behavior-based detection beats signature-only scanning

High-volume malicious package campaigns now exploit the time gap between publication and detection. Signature-based tools wait for a known bad hash, name, or CVE, which is too slow when attackers publish at scale and accept rapid takedowns. Behavior-based analysis instead looks at what a package does at install time, including network calls, obfuscation, and metadata anomalies. That matters because malicious packages and compromised maintainer paths often look legitimate until execution. In practice, the control boundary moves from static reputation to runtime observation, which is a better fit for registries where trust can be manufactured faster than signatures can be written.

Practical implication: Use behavioral checks and install-time policy enforcement for packages that AI or humans introduce into build pipelines.

Threat narrative

Attacker objective: The attacker aims to turn AI-driven trust into a repeatable path for code execution, dependency compromise, or credential theft inside the software supply chain.

1. Entry begins when an AI coding assistant recommends a package name that does not exist, or when a developer pulls a malicious package from a public registry.
2. Credential or trust abuse follows when an autonomous agent or developer installs that package, granting it execution in the build or workstation context.
3. Escalation occurs when the package runs install scripts, reaches adjacent tools, or leverages implicit trust in the pipeline to spread further.
4. Impact is achieved when malicious code, stolen credentials, or poisoned dependencies reach downstream builds and software releases.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI supply chain security is now an identity governance problem, not only an AppSec problem. The article shows that the trust decisions behind package selection, model access, and tool connections are now being influenced by non-human actors. Once AI systems can propose or install dependencies, the question becomes who or what is allowed to act on behalf of the build pipeline. Practitioners should treat AI agents, registries, and tool connectors as governed identities with explicit scope.

Hallucinated dependencies create a new named failure mode: invented-name capture. That is the point at which a repeated fake package name becomes an attacker-controlled real package. The governance gap is not a lack of scanning alone. It is the absence of a control that prevents AI-generated artefacts from being trusted as if they had passed human validation. Teams need to understand that predictable hallucinations are exploitable signals, not harmless noise.

MCP widens the non-human identity surface inside development environments. The article makes clear that AI agents are no longer isolated models but connected systems that can reach tools, data, and registries. That means inventory, authentication, and authorization have to extend to AI tooling itself, not just to the code it touches. For practitioners, the lesson is that every agent-to-tool pathway is now part of identity governance.

Signature-era supply chain controls are no longer sufficient on their own. High-volume malicious package publishing and rapid takedowns make static reputation too slow for the current threat model. AI-assisted defence has value here only when it closes the decision loop from detection to prioritised remediation. The practical conclusion is that teams need policy, telemetry, and response built for pre-signature exposure, not just retrospective clean-up.

From our research library:

• 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.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Invented-name capture: repeated hallucinated package names are becoming a practical attack primitive, so teams need controls that stop AI outputs from being treated as trusted dependency candidates. That changes the problem from simple malware scanning to governed dependency acceptance across development workflows.

AI-driven supply chain risk now depends on whether the organisation can map every model, agent, and tool that can influence installation or build decisions. The governance question is no longer abstract, because unmanaged AI inputs behave like unowned identities with reach into the software factory.

For practitioners

• Inventory AI assets across the SDLC Build an AI-BOM that records models, coding assistants, agents, MCP servers, and registry connections that can influence builds or installs.
• Block unsanctioned package installation paths Require approval or policy checks before AI agents or developers can install new dependencies from public registries.
• Enforce install-time behavioural inspection Scan package actions, scripts, and network behaviour before execution so malicious packages are caught before their payload runs.
• Limit non-human access to registries and tools Map every AI tool and agent to an owner, purpose, and least-privilege access scope so supply chain reach is explicit.
• Prioritise exploitability over raw alert volume Use reachability and behavioural context to rank dependency findings so teams spend time on packages that can actually be abused.

Key takeaways

• AI supply chain security is now as much about identity and governance as it is about package scanning, because AI tools can influence what gets trusted and installed.
• Repeatable hallucinated package names create a predictable attack path that attackers can weaponise by registering invented dependencies before developers do.
• Behavioural inspection, AI-BOM inventory, and install-time policy enforcement are the controls that matter when AI starts shaping the software build.

Key terms

• 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.
• 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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Behavior-Based Package Detection: Behavior-based package detection evaluates what a package does when it is installed or executed, rather than waiting for a known signature. It is used to spot malicious install scripts, suspicious network activity, and other traits that appear before conventional indicators exist.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security programmes that govern modern software delivery.