An AI bill of materials is an inventory of what an AI system is made of — models and their versions, training and fine-tuning data sources, frameworks and libraries, prompts and system instructions, and the tools and external services the system can reach. It is the AI analogue of a software bill of materials, and it exists to answer one question quickly: when something is found to be compromised, what of ours is affected.
Why an SBOM is not enough
A software bill of materials covers code dependencies. An AI system's risk surface includes several things that are not code.
Model weights are artifacts with provenance, licenses and a serialization format that can carry executable content. Training and fine-tuning data determines behavior and is where data poisoning enters. Prompts and system instructions are configuration that changes behavior as decisively as a code change, and are usually versioned nowhere. Tool and MCP dependencies define what the system can reach — see MCP security.
The last two are the ones most inventories miss, and they are the two that change most often.
The inventory goes stale faster than it is maintained
A conventional SBOM is generated at build time from a dependency file, so it is accurate by construction. An AI bill of materials has no equivalent build step. A team swaps a model, adds an MCP server, edits a system prompt — none of it touches a manifest, and the document drifts from reality within weeks.
The structural answer is to derive the inventory from the traffic rather than from a document. A control plane on the request path already observes which models are called, by whom, through which tools, which makes the inventory a query rather than a maintenance task. A declared list says what teams intended to use; an observed list says what they used, and the gap between the two is usually the finding — see shadow AI and runtime governance.
What it is for
Three jobs, in order of how often they come up.
Incident scoping. A model, package or MCP server is reported compromised. Without an inventory, establishing exposure takes days of asking teams — see AI incident response.
Regulatory response. Model inventory is a standing request in supervisory examinations, and it is the first thing asked for rather than the last. NYDFS Part 500 requires a documented asset inventory tracking owner, location, classification and support expiry — a requirement whose transitional deadline passed on 1 November 2025 and which includes AI systems.
Supply chain assurance. Knowing the provenance of a model before it reaches a regulated workload, which is where it meets model allowlists.
ISO/IEC 42001 expects an AI system inventory as part of the management system, and examination readiness generates it from runtime records rather than from a spreadsheet.
Related terms
Data poisoning · AI incident response · Model allowlist and deny-list · NYDFS Part 500 · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs