The AI supply chain

Catherine Ives-YimPublished 27 September 2026 · 5 min read

Engineering companies understand supply chains. We know that a product is only as reliable as its components, that a supplier's change can ripple through everything built on it, and that knowing exactly what is in a product is the foundation of quality, safety and compliance.

AI brings a new supply chain with it. Some of it is obvious: the model, and the company that provides it. Much of it is not: the libraries, plugins and tools the AI system is built from, the model files downloaded from the internet, and the code that AI writes into your own products. Each is a place where something can go wrong, by accident or by design.

The model

Hosted models. When you use a model through a provider, you depend on that provider's security, its handling of your data, and its decisions about updating and retiring models. That is a supplier relationship like any other and deserves the same scrutiny: contractual terms, data handling, location of processing, and what happens when the model changes.

Downloaded models. Running an open model locally or on UK infrastructure, as discussed in Where should your AI live?, means downloading a large file from somewhere. That file is software you are choosing to trust. Download models only from their original publishers or well-established sources, verify their integrity where checksums or signatures are published, and use file formats that store only the model's numbers rather than formats that can contain executable code.

Model provenance. Some organisations also care about who trained a model. As I discussed in Where should your AI live?, that is a different question from where the model runs or who can access your data, and it is worth being clear which question you are actually asking.

The tools and plugins

AI systems increasingly connect to tools through plugins, connectors and standard interfaces, many of them written by third parties. Each one runs with some level of access, handles data, and can be updated by its author.

A connector that gives an agent access to a document store or a ticketing system is, in effect, a piece of privileged software inside your environment. It deserves the same assessment as any other: who wrote it, what it can access, how it is updated, and whether it does only what it claims.

What to do. Keep an inventory of the tools and connectors your AI systems use. Prefer well-maintained, widely reviewed components. Give each only the access it needs, as described in Agents with keys. Review updates before they reach production.

Packages that do not exist

This is a new and slightly strange risk. AI coding assistants sometimes suggest software libraries that do not exist, or that exist under slightly different names. I mentioned this in Building production software with AI coding agents.

Attackers have noticed. Because AI tools tend to invent the same plausible names repeatedly, it is possible to publish a malicious package under a name an AI is likely to suggest, and wait for someone to install it. The practice is sometimes called slopsquatting.

What to do. Never install a dependency simply because an AI suggested it. Check that it is the genuine, established package. Use an approved list of dependencies, lock versions, and scan everything that enters your build. Treat new dependencies introduced by AI with more suspicion, not less.

The code AI writes

Much of the software written today is written with AI help. That code enters your products, and your products' security depends on it.

AI-written code is not inherently less secure than human-written code, but it has characteristic weaknesses. It can look clean and confident while containing subtle flaws: a missing check, an unsafe default, a security control applied in the wrong place. It may reproduce insecure patterns common in the material the model learned from.

What to do. Review AI-written code as carefully as any other code, and in security-sensitive areas more carefully. Use static analysis and dependency scanning. Have a different model check security-relevant changes, as I do, as an extra layer rather than a substitute for human review. And put the result through independent testing. The connected vehicle platform I led with AI assistance went through the same security testing any other code would have needed: thousands of automated tests with industry-standard security tools, run by different AI models from the ones that wrote the code.

Knowing what is in your product

The single most important defence across all of these is knowing exactly what is in your systems and products. For conventional software, that knowledge is recorded as a software bill of materials, a list of every component and version.

The EU Cyber Resilience Act makes this central for manufacturers of connected products. Manufacturers will need to identify and document the components in their products, handle vulnerabilities in them throughout the product's support period, and report actively exploited vulnerabilities promptly. As I argued in From documents to data, that assumes a level of traceability many organisations do not yet have.

AI adds to the list. If your product or your engineering process includes AI components, they belong in the inventory too: which models, which versions, from where, which tools and connectors, and which parts of your code were produced with AI assistance. Some organisations now call this an AI bill of materials. Whatever it is called, it is the same discipline applied to a new kind of component.

When a vulnerability is announced in a library, a connector or a model, that inventory is what lets you answer, in minutes rather than weeks, whether you are affected. That is also exactly the question the vulnerability triage agent in Agents at work in engineering is designed to answer, and exactly what the next article, Connected products versus AI-assisted attackers, depends on.

Four things worth taking seriously

For engineering leaders: treat AI models, tools and connectors as suppliers and components, with the same scrutiny you apply to any other.

For development teams: never install a dependency because an AI suggested it. Verify every one.

For compliance teams: extend your software bill of materials to cover AI components. The regulatory direction of travel makes it inevitable.

For everyone: the principles of supply chain security have not changed. The components have.

I would be interested to hear whether your organisation's software inventory includes the AI models and tools it uses, and the code AI has written.