Practices
AI supply chain
definition
The AI supply chain is the full set of external artifacts an AI system consumes — models, prompts, skills, rules, hooks, MCP connectors, and retrieved context — each of which can alter its behaviour.
In depth
Software supply-chain security matured around one question: what code are we running, and where did it come from. AI agents introduce a second class of input that changes behaviour just as decisively without being code — a Markdown instruction file, a tool description, a retrieved document, a system prompt fragment. Those inputs are the AI supply chain, and almost none of the existing tooling sees them.
The layers stack roughly like this. Models and weights — provenance, licence, and whether a fine-tune was poisoned during training. Prompts and rules — CLAUDE.md, AGENTS.md, system prompt fragments, anything always-loaded. Skills — folders of instructions, sometimes with executable scripts. Hooks — shell commands the host runs automatically. Connectors — MCP servers, plugins, and the credentials handed to them. Retrieved context — documents, pages, and tool results pulled in at runtime, which is where indirect prompt injection enters.
What makes this a distinct discipline rather than a subset of software composition analysis is that the dangerous artifact often contains no code. An SBOM generated from a lockfile will not list the skill that told the agent to skip the security review, because that skill is not a dependency. A container scanner will not flag a hook that reads `~/.aws/credentials`, because the hook is three lines of shell in a settings file.
The other structural difference is that the trust boundary moves at runtime. A dependency's behaviour is fixed once it is installed. An agent's behaviour changes with every document it reads, so the supply chain includes content that was not present at deploy time and cannot be reviewed in advance.
Why it matters for governance
The controls that transfer from software supply chain are the boring, proven ones, and they transfer well: a single source of record for approved artifacts, pinned versions with content hashes, a scan before distribution rather than after, provenance for every artifact, and fast revocation. The control that does *not* transfer is 'review it once at install' — because retrieved context arrives continuously, runtime observation is not optional here the way it arguably is for a static dependency tree.
Frequently asked
- Is the AI supply chain just the software supply chain with extra steps?
- No — the artifact classes are different in kind. Most AI supply-chain artifacts are natural-language instructions with no executable payload, which means they are invisible to dependency scanners while being fully capable of changing what the agent does.
- Where should a security team start?
- Inventory before policy. Enumerate which skills, rules, hooks, and MCP servers are actually loaded across your AI surfaces. That list is almost always longer and stranger than expected, and it makes the rest of the programme obvious.
- Does an SBOM cover AI artifacts?
- Not as generated today. SBOM tooling reads package manifests, and a skill or a hook is not a package. Covering them needs an explicit AI-BOM that enumerates instruction artifacts and connectors alongside code dependencies.
Sources
Primary sources for the claims on this page. Specifications and vendor documentation change — verify against the source if a detail is load-bearing for a decision you are making.