What Is an AI Bill of Materials?

An AI bill of materials (AI-BOM) is a record of the components and dependencies that shape an AI system: models, datasets, prompts, software packages, tools, services, and deployment configuration. Its job is traceability. It does not assess every component for safety or prevent an agent from taking an action.

Why an SBOM is not enough for AI

A conventional software bill of materials can identify libraries and versions in an application. An AI workflow also depends on items that are not ordinary packages. A hosted model can change behavior without a repository change; a prompt can modify an agent's choices; a retrieval corpus can introduce new instructions; an MCP server can add both capabilities and credentials.

That is why the CISA AI SBOM minimum-elements work treats AI supply-chain transparency as a broader problem than package enumeration. An AI-BOM gives the review team a way to ask which of those inputs is present in a specific deployment and who accepted it.

What belongs in an AI-BOM

The useful fields depend on the workflow, but an entry should let someone reconstruct the running system without relying on memory. Record the model provider and version or endpoint, prompt and policy revisions, retrieval sources, embedding model, tool definitions, package dependencies, service accounts, data classifications, environment, and accountable owner. Link each record to the deployment or repository revision that consumes it.

For an agent with external tools, the tool description is not just metadata. It can influence model decisions and expose an execution path. The MCP security tools review is useful when that inventory includes MCP servers; it is a separate evaluation of the server's security properties, not evidence that an entry in the AI-BOM is safe.

A change-review example

Consider a support agent that swaps its general-purpose model endpoint, adds a customer-search connector, and updates a system prompt in the same release. Without an AI-BOM, these changes can appear in different systems: a vendor console, an infrastructure file, a prompt repository, and a tool registry. The release reviewer cannot easily see the combined change in capability and data access.

With an AI-BOM, the release identifies the new endpoint, the connector's identity and permitted scopes, the prompt revision, and the target environment. The reviewer can then decide whether the agent needs a new evaluation, a narrower service account, or additional approval before the connector is used.

AI-BOM, inventory, and runtime control

An AI-BOM is an inventory and provenance artifact. Asset inventory answers what exists and where. A risk assessment asks what could go wrong and how material it is. Runtime control decides whether a particular request should proceed. Confusing those roles leads to weak assurance: a complete inventory does not stop a malicious tool call, and an action control does not explain which obsolete model or dataset remains deployed.

The AI agent security controls guide addresses the latter question: where to inspect components and actions. Use the two records together during a release, but do not represent an inventory as enforcement.

When the record becomes security evidence

The record is most valuable when it shortens a real investigation. If a model provider announces a change, an unsafe prompt is found, or a connector is suspected of overreaching, the team should be able to locate affected workflows, owners, and permissions. A static spreadsheet that never follows releases will not answer those questions.

Prompt text and retrieved documents also deserve controlled provenance. The prompt injection definition explains why untrusted instructions require a distinct trust boundary. An AI-BOM can show where those sources enter the system; a test and a runtime control are still required to show whether the system handles them safely.

Practical use

Start with production agents that can access sensitive data or invoke external tools. Make the inventory update part of deployment rather than a quarterly reconstruction exercise. Preserve the owner, version, relationship, and review decision for every new dependency. That creates a useful baseline for supply-chain review and incident response without claiming that the AI-BOM alone secures the agent.

For a second primary perspective on AI-BOM scope, see the NIST AIBOM presentation.