The Hidden AI Supply Chain

Many organisations believe they have bought one AI-enabled product. In reality, they may be depending on an entire supply chain they cannot see.

When an enterprise signs a contract with a CRM provider, customer-support platform or document-management vendor, it rarely assumes that it is also becoming dependent on one or more foundation model providers, orchestration frameworks, public package registries and additional subprocessors.

Yet a growing share of the AI features embedded inside mainstream enterprise software are built exactly this way. The application purchased by the organisation may sit on top of a model supplied by another company, connected through middleware maintained elsewhere and supported by components downloaded from repositories the buyer has never reviewed.

This creates a hidden dependency graph underneath software that appears, contractually, to involve only one vendor.

The risk is not theoretical. Recent incidents have shown malicious models and agent skills entering public repositories, compromised open-source packages exposing live AI credentials, and apparently legitimate AI assets attracting hundreds of thousands of downloads before their true nature became clear.

This report examines what the hidden AI supply chain looks like, why apparent vendor diversification can conceal concentration on the same underlying providers, how upstream compromises can affect many organisations simultaneously, and what enterprises should now be asking about provenance, fourth-party risk and dependency visibility before they can claim to understand their real AI exposure.

Apparent diversification at the application layer can conceal concentration on the same small number of underlying providers.

An organisation may believe it has diversified its AI exposure because different departments use different software vendors.

That assumption can disappear once each application is traced back to the model and infrastructure providers underneath it.

Several apparently unrelated products may rely on the same foundation model provider, the same cloud platform or the same orchestration framework. A disruption affecting one root provider can therefore affect multiple business systems at the same time.

This creates a concentration risk that ordinary vendor registers may not reveal.

Procurement teams routinely ask vendors about their own security controls, their own data handling and increasingly their own AI governance practices. They are much less likely to ask which foundation models sit beneath the service, which third-party orchestration components are relied on or what happens if one of those underlying providers changes its pricing, terms, capacity or security posture.

Meaningful diversification therefore requires organisations to map vendors by shared underlying dependencies rather than simply count the number of different brands appearing in the application portfolio.

Attackers do not need to compromise every downstream enterprise when they can compromise one shared component upstream.

The software industry has long understood that a trusted upstream dependency can become a highly efficient attack route. AI introduces new versions of the same problem through models, registries, agent skills and orchestration frameworks.

One long-standing weakness involves Python's pickle format, historically used to serialise and distribute machine-learning models. Because loading a pickle file can execute arbitrary code, a malicious model file can behave as executable software rather than as passive model data.

Public repositories have therefore become part of the security perimeter for any organisation whose developers download models or components directly from them.

The same pattern now extends into agent ecosystems. Reusable agent skills and plugins can provide valuable functionality, but they also create new routes through which malicious code or credential-stealing behaviour can enter an environment under the appearance of legitimate capability.

Middleware creates another concentration point. A single package may route requests to several major model providers and hold live credentials for every one of them. Compromise that package and the blast radius can extend well beyond the software itself.

Supply-chain attacks are powerful because they change the economics of compromise. One successful upstream attack can create exposure across every downstream organisation relying on that component, including organisations that never knew the dependency existed.

An organisation cannot manage an AI dependency it cannot identify, trace or document.

The conventional software industry addressed a similar visibility problem through the software bill of materials: a structured inventory of the components and libraries a piece of software depends on.

Comparable approaches are now emerging for AI.

CycloneDX's machine-learning bill of materials extends existing component inventory concepts to models, datasets, configurations and other AI-specific artefacts, making it particularly suitable for automated generation inside build and deployment pipelines.

SPDX 3.0 also includes dedicated AI and dataset profiles, providing another structured way to document provenance, components and dependencies.

The value of these artefacts is practical rather than cosmetic.

When a model, dataset, library or orchestration component is compromised, a complete dependency inventory allows an organisation to determine quickly which systems are affected rather than beginning an emergency investigation from first principles.

The challenge is that many AI assets still lack enough reliable documentation about their lineage, training data and dependencies to populate a complete inventory. The absence of provenance information is therefore itself becoming an important risk signal.

AI vendor governance needs to follow the dependency chain further than conventional procurement usually goes.

Map vendors to their actual root providers. Record which foundation models, cloud platforms and critical middleware sit beneath each AI-enabled supplier. Multiple applications dependent on the same root provider should be treated as concentrated exposure rather than diversification.

Require disclosure of the underlying stack. Ask vendors directly which foundation models, orchestration frameworks and key subprocessors support the capability being purchased and make material changes to those dependencies a contractual notification requirement.

Request structured provenance evidence. Where appropriate, require recognised bill-of-materials artefacts rather than relying solely on narrative assurances about AI governance, security and model provenance.

Treat model-provider concentration as a continuity risk. Identify which workflows would be affected if a shared foundation model provider suffered an outage, materially changed its pricing or terms, or became unavailable for regulatory or geopolitical reasons.

Monitor actual outbound data flows. Independent technical visibility can identify where sensitive information is being sent even when the vendor's own disclosures are incomplete or have become outdated.

Continue monitoring after the contract is signed. Model registries, package ecosystems, subprocessors and vendor architectures change continuously. AI supply-chain diligence should therefore be an ongoing control rather than a one-time procurement exercise.

The hidden AI supply chain is hidden by default because every layer of the stack can outsource the layer beneath it.

The organisations most exposed to AI supply-chain risk are not necessarily those buying unfamiliar or obviously risky technology.

They may be using entirely mainstream enterprise software built on foundation models, orchestration frameworks and shared repositories the buyer never selected, reviewed or even knew were involved.

That creates a structural mismatch between contractual visibility and operational dependency.

A vendor register may show ten different suppliers while the underlying architecture reveals that eight ultimately depend on the same model provider. A procurement review may approve one software vendor while the production service relies on several fourth parties that were never assessed directly.

The answer is not to eliminate third-party AI dependency. Modern enterprise technology cannot operate without complex supply chains.

The objective is to make those dependencies visible enough to manage. Vendor mapping, structured provenance, fourth-party oversight and continuous monitoring are increasingly becoming prerequisites for understanding what an organisation's AI risk actually looks like rather than what the single contract on file suggests it looks like.