The AI Supply Chain, Explained From Zero

This topic is the oldest risk in software wearing a new coat. A modern AI application is assembled from parts other people made, and every borrowed part is something you did not build and cannot fully see inside. That is not a criticism — it is how we build fast — but it means your security is not only your own. We build up why, one part at a time.

1 · You didn’t build it all

Almost nobody builds an AI system from scratch. It is assembled, like a car on a line, from parts made by other people — a base model trained by a big lab, datasets from public repositories, open-source libraries that do the heavy lifting, plugins and tools that connect to outside services, pre-computed components pulled from model hubs. Your “original” product is mostly a careful arrangement of borrowed pieces. And every borrowed piece is something you did not make and cannot fully inspect. That is the whole subject of this topic: the AI supply chain.

2 · The parts on the shelf

You cannot secure what you cannot name, so lay the parts out. First, base models — downloaded from a hub and trusted to behave. Second, datasets — used for training or, in modern apps, as a knowledge source the model reads at run time. Third, libraries — the open-source software packages that wire everything together, often dozens deep, each pulling in more of its own. Fourth, plugins and tools — the connectors that let your agent reach email, search, payments, or any outside service. And fifth, pre-built components — things like embedding models and helpers pulled ready-made from public repositories. Every one is made by someone you have never met, and by default you trust all of it.

3 · A poisoned model from the hub

Take the model — and connect it to the poisoning topic. You browse a public model hub, find a model that scores beautifully on the benchmarks, and download it into your product. But you have no real way to know what went into its training or whether someone planted a hidden backdoor before uploading it. The poisoning attack does not have to reach you through your own training pipeline; it can arrive fully pre-packaged, as a popular, high-rated download that happens to carry a sleeper trigger. This has happened: attackers upload malicious models to hubs with attractive names, sometimes even hijacking the file-loading process to run their own code the instant you load the model. The convenient download is also the delivery truck.

4 · A malicious library

The libraries are the oldest supply-chain risk of all, now attached to AI. You install one convenient package to save time, and that package quietly pulls in dozens of others it depends on, which pull in dozens more — a hidden tree of code you never personally chose or read. If any single package in that tree is malicious, or gets taken over by an attacker, its code now runs inside your application with your application’s full power — reading files, making network calls, stealing credentials. Note how this dwarfs a model attack: a poisoned model can only produce bad outputs, but a poisoned library runs arbitrary code on your servers. Attackers actively publish look-alike packages with names one typo away from popular ones, waiting for a busy developer to install the wrong one.

5 · A rogue plugin or tool

To make an agent useful, you wire it into external services — a search tool, a calendar, a payment connector, a third-party plugin from some marketplace. Each connection hands that outside tool real access, exercised on your agent’s behalf. If the plugin is poorly built, it becomes a weak link an attacker can pry open. If it is outright malicious, you have invited a hostile actor straight into your agent’s trusted circle — and worse, a compromised tool can feed poisoned data back into the agent, turning into an indirect-injection channel. This is excessive agency meeting the supply chain: every tool you connect is both a capability you gain and a party you must now trust, and the more third-party tools you bolt on, the more strangers hold a key to your agent.

6 · You inherit everyone’s risk

Step back and the pattern is clear: when you build on other people’s parts, you inherit every one of their weaknesses along with their work. Your system’s security is not just your own diligence — it is your diligence plus the diligence of the base-model provider, plus every dataset publisher, plus every library author in that deep dependency tree, plus every plugin vendor. You are only as safe as the single least careful supplier anywhere in the chain, and most of those you will never meet or audit. That is sobering, but it is not a reason to build everything from scratch — that is neither possible nor safer. It is a reason to be deliberate: choose suppliers with care, know exactly what is in your system, and limit how much any single borrowed part can hurt you.

7 · Defense: know and limit your parts

You cannot audit the whole world, so the defense is to choose well, know exactly what you have, and box each part in. Prefer trusted sources: pull models and packages from reputable, well-maintained origins rather than the first attractive download. Pin and verify versions: lock each dependency to a specific known-good version and check its signature or checksum, so an attacker cannot silently swap in a tampered one. Keep an inventory — a bill of materials listing every model, dataset, library, and plugin — so that when a supplier is found compromised, you can instantly tell whether you are affected. And apply least privilege to every tool and plugin, granting each the narrowest access it needs, so a rogue one can only reach a little.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

AI supply chain

All the external parts an AI system is assembled from — models, datasets, libraries, plugins, and components.

Model hub

A public repository of downloadable models — convenient, and a delivery route for poisoned models.

Dependency tree

The hidden web of packages each library pulls in — any of which, if malicious, can run code in your app.

Version pinning

Locking a dependency to a specific known-good version so it cannot be silently swapped for a tampered one.

Bill of materials (SBOM)

An inventory of every part in your system, so a compromised supplier can be traced to your exposure.

Typosquatting

Publishing a malicious package with a name one typo from a popular one, hoping a developer installs the wrong one.