The AI Supply Chain: Models, Datasets, Adapters and Plugins

Shadow AI DiscoveryAug 15, 20269 min read

When you deploy an AI feature, it feels like one artefact: a model that answers questions. It is not. It is a supply chain — a stack of components sourced from different places, most of which your team never inspected. Training data scraped from the open web. Base weights downloaded from a public hub. A fine-tune or LoRA adapter someone published last month. A handful of plugins and tools bolted on at the edge. You trust the answer, which means you have implicitly trusted every link. Attackers know this, and they aim for the links, not the answer.

Why the chain exists at all

Nobody trains a frontier model from scratch to answer support tickets — it costs millions and takes months. So the industry composes. A team starts with a base model pretrained by someone else on a corpus they did not curate. They adapt it cheaply with a fine-tune or a LoRA adapter — a small set of extra weights that steers behaviour without retraining the whole network. Then they extend it with plugins and tools so it can search, run code, or hit internal APIs. Each step trades control for speed and capability, and each step imports somebody else's trust decisions into your product.

This is the same economics that produced the software supply chain — npm, PyPI, container base images — and it inherits the same failure mode. You are not running code you wrote; you are running the transitive closure of everything your dependencies pulled in. The difference is that with a model, the malicious payload can hide in weights or data, where no linter or SBOM tool has ever looked.

The AI supply chain, from raw data to a running app — with the points an attacker poisons.

Where each link breaks

Data. Researchers have shown that poisoning even a tiny fraction of a web-scale corpus is practical: buy an expired domain that a dataset still points to, and you control what gets ingested next time. A model trained on poisoned text can carry a backdoor — normal behaviour until it sees a trigger phrase, then it flips. You cannot diff a dataset the way you diff source, so this is largely invisible after the fact.

Weights. Model files are not inert data. The classic PyTorch .bin/.pt format is Python pickle, which executes arbitrary code on load — downloading a model can be enough to get popped. Public hubs have hosted malicious models exploiting exactly this, which is why the ecosystem moved toward the safetensors format that carries data only. A backdoor can also live in the numbers themselves, invisible to any file scan.

Adapters. A LoRA is attractive precisely because it is small and shareable — and that makes it a tidy delivery vehicle. A malicious adapter can implant a trigger, weaken a base model's safety tuning, or ship as a pickled file with the same code-execution problem. Teams review the base model carefully and then load a community adapter on top with a shrug.

Plugins and tools. The moment a model can call out, its supply chain includes every tool it can reach. A plugin is code running with your service's credentials, often reached over the network, frequently maintained by a stranger. It is the link most likely to be added late, under deadline, with the least review.

Why it matters: A poisoned link doesn't announce itself in the output. The model behaves perfectly in your demo and every test you wrote — the backdoor only fires on the trigger the attacker chose, which by definition isn't in your test set.

Test for it — in practice

Pick one model or adapter in production and try to answer three questions: where did the weights come from, in what file format, and who published them? If any answer is “not sure,” you have an unmanaged link.
Grep your model-loading code for formats that execute on load (pickle-based .bin/.pt, torch.load without weights_only). Prefer safetensors for anything you did not produce yourself.

Those are spot checks. Building a full provenance inventory — every model, dataset, adapter and plugin, with integrity verification and poisoning tests — across the estate is what a Shadow AI Discovery assessment runs for you.

Managing the chain like a supply chain

Inventory every link. You cannot govern what you have not listed. Track base models, adapters, datasets and plugins as first-class dependencies, with source and version.
Pin and verify. Pin to specific revisions, verify hashes or signatures on download, and prefer non-executable formats like safetensors for third-party weights.
Treat adapters like the base model. A LoRA changes behaviour and can execute code; it deserves the same review and the same provenance bar, not a free pass.
Scope the plugin layer. Give each tool the least access it needs and review it as running code, because that is exactly what it is.

The software world took a decade of painful breaches to accept that dependencies are attack surface. AI is speed-running the same lesson with higher stakes, because the payload can hide in data and weights that no existing tool inspects. The defence starts where it always does: you cannot secure a supply chain you have never mapped — and most teams have never mapped theirs.

Keep reading

Agent Identity and Delegated Authorization

→

← Back to all articles Request an assessment