What is an AI bill of materials (AI-BOM)?
By Identra · Updated
An AI bill of materials (AI-BOM) is a structured record of the models, data, software and dependencies that make up an AI system. It documents their sources, versions and relationships so teams can find affected systems when a component changes or a vulnerability is disclosed.
What should an AI bill of materials include?
First decide which system and which release it describes. A record for one model file is far smaller than one for an app that does retrieval and calls tools. Say what's covered and what's unknown.
For each component, capture an identifier, the source, the version and how it connects to everything else. Add license and permitted-use terms where you have them. Two files both called model.safetensors can be told apart by their SHA-256 digests. For a hosted model, keep the provider's model ID and any revision they disclose.
Label data by use: training, fine-tuning, evaluation or retrieval. Point to sensitive datasets by ID and keep the records themselves out of the BOM. This is the raw material for AI supply chain security investigations.
- Models: provider, identifier, revision, source, where it's deployed.
- Data: source, version, purpose, provenance, usage restrictions.
- Software: libraries, frameworks, packages, runtime dependencies.
- Agent dependencies: tools, plugins and MCP servers.
- About the record itself: owner, scope, evidence sources, last verified.
How is an AI-BOM different from an SBOM or agent registry?
An SBOM lists software components. An AI-BOM adds models and datasets. An agent registry tracks agents as managed assets, with owners and lifecycle status.
They overlap. CycloneDX supports AI and ML use cases, including model and dataset transparency, and the CycloneDX ML-BOM documentation shows what the format covers. Two files both labeled AI-BOM can still hold very different information. Pick a format your review tools can read.
SBOM
- Question it answers
- Which software is in here?
- Typical contents
- Packages, versions, suppliers, dependency links
AI-BOM
- Question it answers
- What makes up this AI system?
- Typical contents
- Models, datasets, software and how they connect
Agent registry
- Question it answers
- Which agents do we run?
- Typical contents
- Agent IDs, owners, purposes, lifecycle status
How do you build an AI-BOM for an enterprise system?
Pull from build manifests, the model registry, dataset catalogs, deployment config and supplier docs. Join them on stable IDs. A model name in a spreadsheet that can't be traced to the apps using it won't help anyone during an incident.
For agents, include the configured tools. Connect a new MCP server to Claude Code and the system can suddenly do new things with the same model. Link the record to the environment, the owning team and the access it holds.
Discovery has to reach past the systems you build yourself. Browser AI apps, desktop tools and SaaS agents turn up shadow AI that needs an owner. Finding an app won't tell you its model or training data. Write down what the supplier disclosed and what it didn't.
How would a security team use an AI-BOM during an incident?
Say an internal support assistant runs on a hosted model, retrieves product docs and opens Jira tickets through a plugin. Its AI-BOM links the release to the model ID, the retrieval dataset, the plugin package and its libraries. The deployment record links that release to a service account.
The plugin vendor discloses a vulnerability in the version you run. The team traces the package to every deployment, finds the owners and decides what to contain. Engineering patches or disables it, then checks what's actually running.
That narrows the search. It doesn't show whether anyone exploited the flaw. For that you need activity logs and an AI audit trail.
How do you keep an AI-BOM current?
Version it alongside the deployed system and give it an owner. Updates happen as part of each release. Keep the old versions, because an investigation needs what was running at the time.
Know what each kind of evidence proves. A supplier doc, a build manifest and an observed install are three different facts. A file that passes schema validation can still be missing half the dependencies.
- Generate records from build and deployment data where you can.
- Review new models, datasets, plugins and tools before they ship.
- Mark undisclosed revisions and data sources as unknown, with someone assigned to chase them.
- Compare the record with deployed config and investigate any drift.
- Store credential references only. Never secret values.
Does an AI-BOM make an AI system secure?
No. It informs decisions and enforces none of them. A fully documented agent can still follow a malicious instruction or misuse an overprivileged account.
Use it to drive controls. Apply least privilege to connected identities, limit the tools, require approval for sensitive actions, and recheck access whenever a dependency changes.
How Identra thinks about it
Identra gives you an observed inventory to check an AI-BOM against. On macOS and Windows endpoints it finds AI clients, coding agents, MCP servers, skills, plugins, IDE extensions and packages. In the browser it finds AI apps and the accounts people use with them. Across identity, SaaS and cloud it finds AI agents and connected apps, sorted by what they can reach.
Go deeper: AI security, built on identity
Frequently asked questions
Does an AI-BOM contain the actual training data?
No. It references datasets and records where they came from and what they're for. For a hosted model, mark undisclosed training data as unknown.
Can you create an AI-BOM for a hosted AI service?
Yes, as far as the provider lets you see. Record the service, model identifiers and known dependencies, then note what the provider doesn't disclose.
Should system prompts and retrieval configuration be included?
Reference them by version when they affect behavior. Keep the content itself in controlled storage, linked to the release.
How often should an AI-BOM be updated?
Whenever components or dependencies change. Regular reconciliation against deployed config catches changes that skipped the release process.
Who is responsible for an AI-BOM?
The system owner is accountable for accuracy. Engineering maintains it, suppliers provide disclosures and security uses it to assess exposure.