---
title: "Supply Chain Security for AI Agents: What to Pin, What to Verify, What to Record"
description: "An agent runs far more than the code in your repository. This is the practical control set for pinning, verifying and recording everything else it depends on."
author: "Declan Osei"
category: "Attack Surface & Threat Modeling"
date: 2026-10-18T17:40:39.077Z
canonical: "https://agenticcyber.co/blog/supply-chain-security-for-ai-agents-pinning-signing-and-bills-of-materials"
---

# Supply Chain Security for AI Agents: What to Pin, What to Verify, What to Record

![padlock, lock, chain](https://cdn.pixabay.com/photo/2015/01/12/17/40/padlock-597495_1280.jpg?w=1200&q=75)

> An agent runs far more than the code in your repository. This is the practical control set for pinning, verifying and recording everything else it depends on.

Open the repository for a production agent and you are looking at a fraction of what actually executes. Behind the application sit a hosted model, an orchestration framework, that framework's transitive packages, several tool servers, a vector store, a retrieval corpus and a folder of prompt files that three teams have edited this quarter. Each of those can change without a single commit landing in the branch you review.

This guide is the controls checklist for that reality: which dependencies to freeze, which artefacts to verify before execution, and what to write down so an incident does not begin with archaeology. For the map of which trust relationships fail and why, see our earlier piece on [where trust breaks down in agentic pipelines](/supply-chain-risk-in-agentic-pipelines-where-trust-breaks-down). Everything here is defensive and stays at the level of configuration you own.

## What an Agent Actually Depends On

  ![](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/5bc07ae2-9ee0-46b9-9820-b0704936f742/78cc95af-2ddd-4012-8666-7214381d7ff7/8981ae84-b3aa-452a-9b66-f1770f5a9fb4.png)

The OWASP GenAI Security Project places supply chain third on its 2025 list for LLM applications, and [its entry warns that these chains can compromise model integrity, the data used to train a model, and the platform it is deployed onto](https://genai.owasp.org/llmrisk/llm032025-supply-chain/). Agents inherit every one of those exposures and then add their own, because an agent holds memory, reaches tools and acts on what it reads.

Sorting dependencies into five buckets makes the inventory tractable.

- **Application and library code.** Your service, the agent framework, vendor SDKs, and the long tail of packages those pull in without asking.

- **Models.** Hosted endpoints you call, plus open weights pulled down and served from your own hardware.

- **Tool surfaces.** MCP servers, plugins, connectors, browser extensions and anything else that turns a model's output into an action.

- **Data.** Fine-tuning corpora, retrieval indexes, embeddings and whatever your memory store has accumulated since launch.

- **Instructions.** System prompts, skill files, rule files and tool descriptions.

That last bucket is the one teams leave off the diagram, and it is the one with no package manager behind it. Prose that steers an agent is a dependency in precisely the way a library is. Where somebody outside your review process holds the edit rights, you have a supply chain exposure with no advisory number attached.

## Why the Gaps Open So Fast

Agent tooling is designed for a one-command install, and the ecosystem ships weekly. A dependency gets added to unblock a demo and nobody revisits the decision, because nothing visibly breaks. Trust runs in a direction that surprises people, too: an agent reads tool descriptions authored by a third party and then acts on them, so a supplier's mistake, or a supplier's intent, becomes behaviour inside your system.

The wider software ecosystem keeps demonstrating the speed at which one compromised package travels. Our write-up of [the npm worm and what it means for coding agents](/shai-hulud-npm-worm-lessons-for-ai-coding-agents) walks a single case and the controls that shortened it.

## Control 1: Write Down Every Component, Including the AI Ones

Begin with a record rather than a tool. The OWASP entry for this risk asks teams to keep [an up-to-date inventory of components](https://genai.owasp.org/llmrisk/llm032025-supply-chain/) in a software bill of materials, and points separately at an AI bill of materials covering models and data.

There is now a standard to write it in rather than a spreadsheet convention. CycloneDX is published as [ECMA-424, whose second edition of December 2025 standardises CycloneDX v1.7](https://www.ecma-international.org/publications-and-standards/standards/ecma-424/) and carries domain-specific modelling for machine learning models alongside ordinary software components. The project's own ML-BOM capability page describes the goal as [model and dataset transparency, covering dataset provenance, training methodology and AI framework configuration](https://cyclonedx.org/capabilities/mlbom/). If you are choosing a format this quarter, choose one a tool can already emit and a regulator can already read.

In practice that means model names carrying their versions, the origin and hash of each set of downloaded weights, a version for every dataset, a version for every tool server, and a version for every prompt template. Keep the record beside the code in the same repository so it moves when the system moves. A bill of materials living in a wiki page is a bill of materials that was accurate once.

## Control 2: Freeze Anything That Offers a Version

Lockfiles for packages. Exact pins for every tool server. Digests rather than tags for container base images. Pin model versions wherever the provider exposes them, and keep a note of which provider aliases you depend on, because an alias quietly moving to a newer model is a behaviour change you did not request. A floating latest tag is a standing invitation for a stranger to deploy into production.

## Control 3: Verify Integrity Before Execution

The same OWASP entry recommends model integrity checks through signing and file hashes. Extend the habit to packages and to the binaries behind each tool server, and prefer a supplier publishing build provenance or signatures over one publishing neither. The Supply-chain Levels for Software Artifacts framework, SLSA, gives you a ladder for provenance, its Build Track running from Level 1 up to Level 3.

Know what that ladder does not reach. [Its specification is explicit that SLSA does not cover an organisation that deliberately ships malicious software](https://slsa.dev/spec/v1.0/about). Provenance establishes an artefact's origin with high confidence. It says nothing about whether the author deserved your trust, so vetting stays a separate job nobody can automate for you.

## Control 4: Review a Tool Server as Code Plus Text

A tool server is two things at once: a running process, and a description your model will read and believe. Work out who maintains the project, how an update reaches you, which permissions it requests, and which hosts it can open a socket to once it is running.

The Model Context Protocol's security guidance is specific about local servers launched from configuration, requiring that clients display the exact command and obtain consent before executing it. [It also holds that a server must reject a token it was not itself the intended audience for](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices). Our [intake checklist for third-party MCP servers](/mcp-security-a-checklist-before-you-install-a-third-party-server) turns that into a review you can run in twenty minutes.

## Control 5: Give Third-Party Code Less to Work With

Design on the assumption that one dependency eventually behaves badly, then make that event boring. Run tool servers inside a container, with a read-only file system where the workload allows it and an egress allowlist in every case. Issue each one a scoped credential of its own rather than anything belonging to an engineer. Put changes to a tool description through code review, because the model reads those strings and follows them.

## Control 6: Govern Updates Instead of Blocking Them

Freezing versions and never moving is its own vulnerability, because patches stop arriving. Both sides of that trade have a cost, which is why the OWASP entry names vulnerability scanning and a patching policy among its mitigations. Build a deliberate path: a bot opens the change, your test suite and your adversarial checks run against it, a person approves the merge. A short waiting period on non-urgent updates costs almost nothing, and a malicious release is usually identified within days of publication.

## Control 7: Watch for Changes Nobody Requested

Alert on a new outbound destination from a tool server, a new child process under it, or a version that shifted with no merge behind it. Decide in advance how credentials get rotated, how a bad component is pulled, and how you return to a known-good pinned set. Rehearse that once, so the runbook survives its first contact with a real incident. The [monitoring guide](/ai-agent-monitoring-what-to-log-measure-and-alert-on) covers which signals repay the collection cost.

## Build the Egress Allowlist Before the Bill of Materials

Given one week and one engineer, most teams generate an SBOM first. It is the artefact an auditor asks for, a tool produces it in a single command, and it feels like progress you can show. We would spend that week differently, on an egress allowlist for every tool server and a pinned set you can roll back to, and leave the inventory for week two. The reason is in the five buckets above. The formats are good at the components that have a package manager behind them: ECMA-424 reaches models and datasets, which is further than anything did two years ago. The prompt files and the tool descriptions, the fifth bucket, have no agreed component type and no advisory feed, and they are the dependencies most likely to change without a merge. An SBOM that is complete about libraries and silent about instructions tells you the thing you were already least worried about.

Who you sell to decides this. If your agent ships inside a product placed on the EU market, the Cyber Resilience Act takes the choice away: the Commission's own page sets [reporting obligations from 11 September 2026 and the main obligations from 11 December 2027](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). Once documentation has a date attached it stops being a priority judgement and becomes a scheduling one, and you do the inventory early because the alternative is doing it in a hurry. For an internal agent with no such exposure, the allowlist still buys more risk reduction per hour than the document does.

## When to Bring In Help

A suspected compromise in a production agent's dependencies is an incident rather than a maintenance task. Escalate it internally, and bring in outside responders where the scope justifies them. This article is general guidance, not an assessment of your particular dependency graph.

You will not verify everything, and a plan assuming otherwise fails on contact. Freeze, record, isolate and monitor the components holding the most authority first, then work outward as the budget allows.

One ordering note. Of the seven controls, the inventory and the pins are the only ones that cost nothing but attention, and they are the ones that make every later control possible. An alert on a version that moved requires a recorded version to compare against. A rollback to a known-good set requires somebody to have written that set down. Teams that open with the interesting work, usually signature verification in the build pipeline, tend to find that the components doing the most damage were never in the pipeline to begin with.

## Questions about agent supply chain controls

### What belongs in an AI bill of materials?

The AI-specific parts a normal software inventory misses: models with versions and origins, downloaded weights with hashes, datasets, retrieval corpora and prompt template versions. It extends a conventional bill of materials rather than replacing it.

### Does a hosted model API count as a dependency?

Yes. You depend on that provider's model behaviour, its change schedule and its own security posture. Pin the version where the provider offers one, and re-run your evaluation suite after any provider-side change.

### Are prompts and tool descriptions really dependencies?

They steer the agent's decisions, so an unreviewed change to either carries the same risk as an unreviewed code change. Version them, review them and record which version shipped.

### Is provenance enough on its own?

No. Build provenance gives you tamper resistance and a verifiable origin. It makes no judgement about whether the producer is honest or the code is sound, so pair it with vetting.

## FAQ

### What belongs in an AI bill of materials?

The parts a normal software inventory misses: models with versions and origins, downloaded weights with hashes, datasets, retrieval corpora and prompt template versions. It extends a conventional SBOM rather than replacing it.

### Does a hosted model API count as a dependency?

Yes. You depend on that provider's model behaviour, its change schedule and its security posture. Pin the version where one is offered, and re-run your evaluation suite after any provider-side change.

### Are prompts and tool descriptions really dependencies?

They steer the agent's decisions, so an unreviewed change to either carries the same risk as an unreviewed code change. Version them, review them, and record which version shipped.

### Is build provenance enough on its own?

No. Provenance gives tamper resistance and a verifiable origin, but makes no judgement about whether the producer is honest or the code is sound. Pair it with vetting.


---
Source: https://agenticcyber.co/blog/supply-chain-security-for-ai-agents-pinning-signing-and-bills-of-materials