An AI bill of materials lists the models, data and tools inside your AI

The first question after a model problem

When a model publisher discloses a problem, the first question is simple: are we affected, and where? Endor Labs, a vendor with its own tooling in this area, says that without an inventory the answer takes "days of Slack threads and grep." With one, it says, the answer is a query against data you already have.

That inventory is called an AI bill of materials, or AIBOM. This is the vendor's explainer, so read it as one company's view. But the idea is practical, and it changes who can answer a hard question quickly.

What goes on the list

Endor Labs describes an AIBOM as a structured, machine-readable inventory of the parts of an AI system. It also records evidence of each part's origin, rights, integrity and evaluation. It covers six categories.

These are models and their provenance, datasets, software and machine-learning dependencies, external AI services, agents and tools, and governance details such as owner, approval status and known limits. Endor Labs notes that agents and tools include Model Context Protocol (MCP) servers, the connectors that let an AI assistant act on other systems.

The guide says an AIBOM extends a software bill of materials (SBOM). It does not replace it. Libraries, containers and runtimes still need their own list. The two work better linked.

How it works in a real system

The guide walks through an internal support assistant. It answers staff questions from company documents and opens tickets. It uses an open-weight chat model fine-tuned on support tickets, an open source embedding model, a hosted language model API as a fallback, and one MCP server for tickets.

Each part gets an entry. For the fine-tuned model, a field called pedigree points back to the model it was built from. In the guide's example, that pointer is how a team would trace exposure if the original model were later found to have a flaw. The guide labels its sample CycloneDX entry as illustrative and says to check it against the current schema.

The honest entry is "unknown"

The hosted API shows where an inventory meets its limits. A company never downloads the weights, so it has nothing to hash. The guide adds that the provider can change the model without changing its name. Its advice is to log the exact identifier, when you last verified it and what the contract says. The hash field should read unknown.

Training data is similar. Many publishers describe it only in general terms. The guide suggests copying whatever the model card says and marking what is missing. In its words, an AIBOM that says "unknown" is honest and useful, while blank fields make it look complete when it is not.

This is the idea worth keeping. A list that admits its gaps tells your team where to look. A list with blanks hides the question until an auditor asks it.

The risk is mostly ordinary

Malicious models exist. Endor Labs points to Python's pickle format, which can run code when a model loads. That is a documented mechanism, and it is why safer formats such as safetensors exist.

The guide says it found no credible aggregate data on how often incidents come from malicious parts, so it offers a qualitative picture instead. Much everyday risk comes from components nobody meant to be harmful. Its examples: a model downloaded without a fixed version, so its weights can change unnoticed. An outdated model version that is still serving customers. A model licensed against commercial use that sits inside a commercial product. A fine-tuned model whose original was never written down.

Endor Labs also warns that spreadsheets drift. A developer pulls a model into a notebook, the notebook becomes a service, and nobody updates the list.

Standards exist, but none has won

Several formats and efforts apply. CycloneDX supports machine-learning models and model cards from version 1.5. SPDX added profiles for AI packages and datasets in version 3.0. OWASP runs a community project that defines what an AIBOM should hold.

OWASP also publishes an open-source tool, the AIBOM Generator. Point it at a Hugging Face model and it builds a CycloneDX inventory, then scores how many fields it could fill in. Endor Labs calls it a low-effort way to see a real example.

In May 2026, CISA and its G7 partners released voluntary joint guidance titled "Software Bill of Materials for AI: Minimum Elements." It groups the information into seven clusters, running from metadata to key performance indicators. Endor Labs describes it as a baseline, not a mandate.

On law, the guide notes that neither the EU AI Act nor ISO/IEC 42001 names an AIBOM. Its argument is that an inventory is a practical way to gather much of the component and data information those frameworks ask for. Endor Labs adds that no single schema is universally adopted yet, and advises teams to follow their customers' format.

What an inventory cannot tell you

The guide is plain about limits. An AIBOM cannot prove a model is safe or capture runtime behavior. It also cannot record what AI coding agents do. Those need model evaluation, runtime monitoring and an audit log of agent actions.

Questions for your teams

Endor Labs frames a simple test. Imagine an auditor or a customer asks for your AI inventory tomorrow. Could someone export it within minutes? Or would a person spend a week piecing a spreadsheet back together?

Add a few more. Does the inventory include prototypes that reached production? Are model versions pinned? Is the base model recorded for every fine-tune? Who has checked the license on each model? Are unknown fields marked as unknown?

An inventory does not make AI safe. It makes the next incident a query instead of a hunt.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.