How do you model AI supply chain risk?

To model AI supply chain risk, list every outside component your AI system depends on, such as models, datasets, libraries, plugins and hosted services. Then rate each for how much you trust its source, what it can touch, and what failure would cost. Review the list whenever a component changes.

What is in an AI supply chain?

A normal software supply chain has source code, packages, build tools and registries. An AI system adds more layers. There are pretrained model weights, fine tuning data, embedding models, prompt templates, vector stores, agent tools and plugins, and the hosted inference service. Each has an owner who is not you.

OWASP lists supply chain vulnerabilities as one of the risks for LLM applications, covering third party models, datasets and plugins. MITRE ATLAS catalogs adversary techniques against AI systems, including poisoning data and compromising model artifacts, and gives you a shared vocabulary.

What can go wrong at each layer?

Weights downloaded from a public hub may be tampered with, or use a file format that can run code when loaded. Training or retrieval data can be poisoned so the model behaves badly on chosen inputs. A library you import may be compromised like any other package. A plugin may request more permissions than it needs. A hosted model can change behavior when the provider updates it.

A constructed example. A support chatbot uses a fine tuned open model, a vector database filled from a shared documentation site, and a plugin that creates tickets. Anyone who can edit the documentation site can plant text that the chatbot later retrieves and obeys. That path never touched the model, which is why the model alone is the wrong unit of analysis.

How do you build the model?

Use a simple register, one row per component, and keep it in version control.

1. Name the component, version and where it came from.
2. Record who controls it: you, a vendor, or the public.
3. Note what it can access: data, tools, network.
4. Rate trust in the source from low to high, with the reason.
5. Rate impact if the component misbehaves.
6. List the existing control, such as hash pinning, review or sandbox.

Rank by trust low and impact high. Those rows get attention first.

The NIST AI Risk Management Framework gives a structure for this work through its four functions: govern, map, measure and manage. The register is mostly the map step, and ratings and controls feed measure and manage.

Which controls give the most return?

Pin versions and verify hashes for weights, datasets and libraries, so a silent swap fails loudly. Prefer formats that do not execute code on load. Control who can write to retrieval sources, since that is an input channel. Give agents and plugins the narrowest permissions. Log model and prompt versions with each response so an incident can be traced. Keep a way to roll back to a known good model quickly.

A bill of materials helps. A software bill of materials covers libraries and packages today. For models and datasets, track the same facts yourself: source, version, license, checksum.

How to check or apply this

1. Draw one diagram of a single AI feature showing all inputs and tools.
2. Fill the register from that diagram.
3. Mark rows where trust is low and impact is high.
4. For each, add one control and an owner with a date.
5. Add a trigger to update the register when a model, dataset or dependency changes.
6. Scan the code dependencies in the same project with your usual tools, as the AI layer sits on ordinary packages too.

Quick check

Sources

1. NIST AI Risk Management Framework
2. MITRE ATLAS
3. OWASP Top 10 for Large Language Model Applications

Last reviewed: 18 October 2026.