Summary: A five-layer taxonomy from silicon to user interface, with “grey zones” where accountability fragments. 78% of surveyed organisations report limited or partial visibility of their own AI supply chain.
Sources: raw/Supply-chain-attacks/sc-report-final.md (Plexal & Oxford GCSCC, March 2026); AI Supply Chain Security_ Why It's Becoming Harder to Ignore.md (Wiz); Same same but also different...md (Google Cloud)
Last updated: 2026-07-29
The primary source
Securing the AI Supply Chain: Risks, Realities and Resilience (March 2026), by Plexal and Oxford University’s Global Cyber Security Capacity Centre (GCSCC), supported by the Laboratory for AI Security Research (LASR).
This is the first non-vendor institutional source on supply chain in the vault, and it is workshop-derived research rather than marketing. Two figures anchor everything else:
- 78% of workshop participants indicated their organisation had “limited or partial visibility of their AI supply chain.”
- 28% had changed vendors due to trust or compliance challenges.
Why a taxonomy is the deliverable
“While often reduced to models and training datasets, the AI supply chain extends far beyond these elements, encompassing the software, hardware, infrastructure, and human inputs that make modern AI possible.”
The report’s argument is that you cannot assess what you cannot name — a taxonomy “provides clarity on the components involved and the common language used to describe them, enabling more precise discussion of risks, dependencies and security challenges.”
The five layers
| Layer | Contents |
|---|---|
| Hardware | GPUs, TPUs, ASICs, FPGAs; packaging, power and cooling; servers and interconnects; compute boards and edge devices; embedded firmware; IC design and fabrication |
| Compute infrastructure | Virtual machines, CI/CD pipelines, orchestration tooling, APIs; cloud (rented, SLA-governed) vs on-prem (private GPU clusters) |
| AI core | Data (sources, labelling, cleaning, versioning) · Algorithm (training strategy, loss functions, hyperparameters) · Model (architectures, pre-trained weights, fine-tuning) |
| Deployment | Model serving frameworks, containers, model registries, access controls, inference APIs, monitoring |
| Integration & user interfaces | Plugins and API connectors, orchestrations and wrappers, GUIs, business platform integration, guardrails, human-in-the-loop workflows |
Note where guardrails sit — in the integration layer, not the model. They are a supply-chain component with their own provenance question.
There is no one-size-fits-all chain
“Organisations adopt AI through a wide range of models, including in-house development, use of open-source components, deployment of pre-trained models or reliance on APIs and hybrid approaches… Each of these deployments introduces distinct trade-offs in terms of visibility, control and vulnerability.”
The consequential case is API consumption: third-party services “abstract away multiple underlying layers… which remain invisible to the end user organisation. While this simplifies adoption it also creates blind spots.”
This maps directly onto deployer split — the report cites Engler and Renda on reconciling the AI value chain with the Act, and Cobbe, Veale and Singh on accountability in algorithmic supply chains.
Grey zones
“Several ‘grey zones’ emerged where accountability and control are either fragmented or unclear… they represent convergence points for risk propagation or failure that are challenging to trace.”
Grey zones are both technical and organisational — they arise “at the intersection of technical systems and deployment environments.” This is the supply-chain analogue of the confused-deputy problem in agentic attacks: nobody is doing anything wrong, and the boundary is where the failure lives.
The CIA triad is insufficient
The report’s sharpest analytical move:
“Traditionally, the CIA triad (Confidentiality, Integrity, Availability) defines the pillars of information security. However, in the context of AI, additional properties — including explainability, fairness, robustness, reproducibility, and accountability — are equally important… these properties offer a practical lens for assessing AI supply chain risks than component-level analysis alone.”
That list overlaps substantially with NIST’s seven trustworthiness characteristics, reached independently and from a supply-chain rather than a risk-management direction. Both conclude that AI security cannot be expressed in CIA terms alone.
Compare the CISA definition of “AI cybersecurity incident” in the OWASP glossary, which is framed purely in CIA terms — the corpus does not agree on this.
Wiz’s layer model, for comparison
Wiz cuts the same territory differently — data layer, development layer, model artifact layer, deployment and inference layer, third-party components — and adds the cascade argument:
“A poisoned dataset can corrupt a model, a tampered model can leak data during inference, and an over-permissive deployment can expose everything downstream. Securing the AI supply chain means understanding these dependencies – not just protecting each component in isolation.”
What is genuinely different from traditional software
Google’s three differences (source: Google Cloud):
- Data versus code — “AI relies heavily on data, creating unique security challenges around data provenance, poisoning, and versioning… Version control for AI datasets is not as mature as that for traditional software code.”
- Opacity versus inspectability — “AI models are opaque, making manual review impossible, unlike software code that can be readily inspected… AI training often comprises a series of ad hoc incremental steps that are not recorded in any central configuration.”
- Emphasis on provenance — “Software provenance is crucial for AI due to the risks of data poisoning and model tampering.”
Google’s overall position is nonetheless continuity: “AI development is similar to the traditional software development lifecycle, so existing security measures should readily adapt to AI.” The LinkedIn piece in this folder puts it more bluntly with a section headed “Remember, AI is just software.”
The Plexal/Oxford report agrees on approach — “builds on existing cyber security best practices while adapting them” — and points to NCSC supply chain guidance as still applicable.