What is an AI bill of materials, and who uses it?
An AI bill of materials lists the models, tools, data sources, and services behind your AI. See what it holds, how CycloneDX fits, and how security, procurement, and audit use it.
By Halo Research Team
A software bill of materials lists the components inside a piece of software, so people can answer questions about it later. An AI bill of materials, or AI BOM, applies the same idea to AI. It lists the models, applications, agents, tools, data sources, and services that make up an AI system, or that make up the AI in use across an organization.
The idea is simple. Its value comes from how many teams can work from one shared record.
What goes into an AI BOM
The exact fields vary, and most AI BOMs cover the following kinds of components.
- Models. The model and version, the provider, where it runs, and the terms that apply to it.
- Applications and agents. The apps and agents that call models, each with an owner and a purpose.
- Tools and connections. MCP servers, plug-ins, extensions, and app connections that give an AI system reach into other systems.
- Data sources. What the system reads and writes, with a sensitivity label.
- Runtimes and artifacts. Local runtimes, model files, and the locations where they live.
- Services and providers. Hosting, APIs, and vendors that the system depends on.
- Status and approvals. Whether the item is sanctioned, monitored, or blocked, and who decided.
How it relates to an SBOM and an inventory
A software bill of materials covers libraries, packages, and other software components. An AI BOM extends that idea to the parts that are specific to AI, such as models and data sources. The two work side by side, and a mature program often keeps both.
An AI BOM can describe one AI system or the AI an organization uses. A system-level BOM lists the components inside one system, such as the model, the retrieval index, and the tools an agent can call. An organization-level BOM lists the systems and tools that exist across teams, and it overlaps heavily with an AI inventory.
Starting at the organization level makes sense when the first problem is finding what exists. You cannot describe the components of a system that you have not found yet.
Where CycloneDX fits
CycloneDX is an open standard format for bills of materials. It began in application security and software supply chain use cases and includes support for describing machine learning components. A common format lets existing tools read the list, compare it over time, and join it with other supply chain records.
Halo exports its AI inventory as an AI BOM in CycloneDX, JSON, and CSV. CycloneDX suits tools that already read BOMs, JSON suits scripts and internal systems, and CSV suits spreadsheets and reviewers who prefer a table. The CycloneDX integration page has the details.
One inventory, exported in the format each team already uses, keeps security, procurement, and audit working from the same facts.
Who uses it
Each group asks a different question of the same list.
| Team | Question the AI BOM answers |
|---|---|
| Security | A new advisory names a plug-in, a runtime, or a server. Where is it in use? |
| Procurement and vendor management | Which AI providers and tools are in use, and do they match what contracts cover? |
| Audit and compliance | What AI existed on a given date, how was it classified, and who owned it? |
| IT and platform engineering | What needs support, updates, or retirement? |
| Finance and AI operations | Which tools and models drive spend, and who owns each one? |
Keep one source so the answers agree. When each team builds its own spreadsheet, the lists drift apart and meetings turn into reconciliation.
For example, a security team might receive an advisory about a local model runtime. They filter the exported inventory for that runtime and see where it was found and how confident the source was. Procurement checks the same export for sanctioned runtimes, and audit keeps the dated snapshot as a record of what was known that week.
Keep the list trustworthy
A BOM that is out of date misleads. Three habits keep it useful.
- Record the source and confidence. Say how each item was found, such as endpoint discovery, browser discovery, or manual registration, and how sure you are.
- Label unknowns. An item with no owner or purpose is a finding. Keep it visible until someone claims it.
- Snapshot on a schedule. Export the list at regular intervals, so audit and security can compare two dates.
Coverage limits belong next to the data. Discovery works on supported surfaces, so say which devices, browsers, and gateways feed the list. The post on inventory coverage and freshness goes deeper.
Use snapshots to see change
AI components change without announcement. A provider updates a model, a plug-in asks for new permissions, or an agent gains a tool that can send data outside the company.
Two exports taken at different dates show what changed in between. Review the differences that matter most, such as new external-sending tools, new data sources, and items that moved from unknown to in use.
Keep the earlier snapshot, so the old approval and the new review outcome both stay on record. The post on when to review an AI system again describes which changes deserve a fresh review.
What an AI BOM does not tell you
A bill of materials lists what is there. It says little about how a system behaves, whether a model is accurate, or whether a use is appropriate. Risk assessments, testing, and policy decisions still need their own records, and the BOM gives them a reliable list of things to assess.
How Halo helps
Halo's AI inventory classifies items as sanctioned, monitored, blocked, shadow, or unknown, and records the source and confidence for each. Browser and endpoint discovery feed it, and it exports as an AI BOM in CycloneDX, JSON, and CSV. Read the glossary entry on AI bill of materials or book a walkthrough to talk through what an export would contain for your environment.