AI BOM (AIBOM) explained, and the tool gap

An AI BOM, or AI bill of materials, is an inventory of everything that goes into an AI system: the models, the training and evaluation datasets, the software serving them, the hardware underneath, and the claims made about how the result should be used. It extends the idea of a software bill of materials to components that are not code, and it exists because “which model version is this, trained on what, running where” is a question nobody could answer from an SBOM alone.

The idea is real and useful. It is also, as shipped, missing a component class that matters to anyone running agents: the tools those agents can call. An MCP server is a dependency of an agent in the way an npm package is a dependency of an application, except that calling it has side effects in the world. No AI BOM format in production today has a field to put one in.

What is an AI BOM?

The AI BOM meant here is the disclosure artefact. Its most-cited framing is the G7 Cybersecurity Working Group’s Software Bill of Materials for AI, Minimum Elements, published on 12 May 2026 by Germany’s BSI, Italy’s ACN, France’s ANSSI, Canada’s CSE, the US CISA, the UK’s NCSC and Japan’s NCO, in collaboration with the EU Commission. It groups the fields into seven clusters:

1. Metadata: SBOM author and signature, version, data format, generation context, timestamp.
2. System Level Properties: system name, components, producer, version, timestamp, data flow, data usage, input/output properties, intended application area.
3. Models: name, identifier, version, producer, hash value and hash algorithm, training properties, licence, external references.
4. Datasets Properties: name, description, content, identifier, hash, provenance, statistical properties, sensitivity, licence.
5. Infrastructure: infrastructure software and infrastructure hardware, plus a link to a hardware BOM where one exists.
6. Security Properties: security controls, security compliance, cybersecurity policy information, vulnerability referencing.
7. Key Performance Indicators: security metrics and operational performance KPIs.

The tool surface appears in that list only as free text inside two System Level Properties elements. System components offers “other software tools and components” as an example, and System data flow offers “Application Programming Interfaces (APIs) of external services the AI system uses” and “multi-agent communication protocols”. No element names a tool, its capability scope or its schema, and nothing gives a tool the identity, version and hash fields the Models cluster gives a model.

How is an AI BOM different from an AI boom or a Maven BOM?

Three unrelated things share this name, and search results mix all of them.

• Bill of materials, electronics sense. The parts list for a physical assembly, the PCB meaning. Older and larger than anything in software.
• Dependency BOM, Maven or Gradle sense. A pom.xml of type bom that pins a consistent set of library versions for downstream projects to import. A version-alignment mechanism, not an inventory for disclosure.
• “AI boom”, market sense. A different word entirely, and a common autocorrect on the way to this page.

How does an AI BOM differ from an SBOM?

By composition, not replacement. An AI BOM wraps an SBOM rather than competing with it. The model is a new kind of component; the Python wheels, the Node packages, the container base image and the inference server around it are ordinary software, and the existing formats already describe those well.

In CycloneDX the two are literally the same document. An ML-BOM is not a separate file type: it is a CycloneDX BOM whose components array happens to contain machine-learning-model and data entries alongside the library entries. In SPDX they compose by profile, so one document can carry both the software packages and the AI-specific ones.

The new part is neither code nor hashable:

Concern	SBOM	AI BOM adds
Identity	package name, version, purl	model name, version, base model
Integrity	file hashes, signatures	weights hash where the weights are distributed at all
Provenance	build attestation, source repo	training data sources and collection method
Fitness	licence	intended use, out-of-scope use, known bias
Behaviour	none	evaluation metrics, benchmark conditions
Cost	none	energy consumption

The right-hand column is why AI BOM adoption trails SBOM adoption. A build system can emit an SBOM with no human in the loop. Nobody can generate “known bias” or “intended use” from a CI job, and a training-data summary for a model you fine-tuned from someone else’s checkpoint depends on disclosure you may never have received.

Which formats can actually express an AI BOM today?

Two formats can, plus a standardisation track that is easy to overstate.

Format	AI support arrived	What it gives you
CycloneDX 1.5 (26 June 2023)	machine-learning-model and data component types, modelCard	The ML-BOM as it is used in practice
CycloneDX 1.6 (9 April 2024)	environmentalConsiderations under modelCard.considerations, carrying energyConsumptions	Training and inference energy disclosure
CycloneDX 1.7 (21 October 2025)	no new AI-specific fields	The newest 1.x minor; 2.0 work is open
ECMA-424	1st Ed (June 2024); 2nd Ed (December 2025) = CycloneDX 1.7	CycloneDX as a published standard
SPDX 3.0 (15 April 2024), 3.0.1 (17 December 2024)	AIPackage and a separate DatasetPackage	AI and Dataset profiles alongside the software one

The practical reading: if you want an AI BOM you can generate and consume with existing tooling today, CycloneDX is the one with the longer production history for this, and SPDX 3.x is the one with the richer AI-specific data model.

Does any regulation actually require an AI BOM?

No regulation requires one under that name.

The EU AI Act comes closest. Article 53(1)(d) requires providers of general-purpose AI models to publish a “sufficiently detailed summary about the content used for training”, following the Commission’s “Explanatory Notice and Template for the Public Summary of Training Content for general-purpose AI models”, published on 24 July 2025 and adopted as Commission Communication C(2025) 8311 final on 5 December 2025. That is a training-data summary aimed at the public and at rightsholders. It is not a machine-readable component inventory, and nothing in the Act names a BOM format.

The G7 minimum elements are explicitly voluntary: they “are not mandatory; do not create requirements, standards, or legislation”. In the United States, Executive Order 14148 of 20 January 2025 revoked “Executive Order 14110 of October 30, 2023 (Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence)” outright, so the federal AI-inventory push that some 2024 guidance was written against no longer exists.

Build an AI BOM because it answers questions you will be asked in procurement and incident response, not because a regulator currently demands the artefact.

Why does the tool surface belong in an AI BOM at all?

A tool is a dependency with side effects.

When your agent connects to an MCP server, three things enter the system that the model card never described. First, executable reach: the ability to read a file, call an API, spend money, or write to a database. Second, text the model reads and acts on, since tool names, descriptions and schemas are supplied by the server and consumed as instructions. Third, a data path out, because anything the tool can receive as an argument can leave.

That second point is the mechanism behind MCP prompt injection and tool poisoning. That post covers how hostile tool text works and what constrains it. The BOM question is narrower and prior: can you enumerate, at a point in time, which tool definitions your agent was exposed to, and prove they have not changed since? An incident response that cannot answer that has no inventory to work from.

Can any AI BOM format express an MCP server today?

No, and both standards bodies tried.

CycloneDX has no component type for it. In the 1.7 JSON schema the full component.type enumeration is application, framework, library, container, platform, operating-system, device, device-driver, firmware, file, machine-learning-model, data and cryptographic-asset. There is no tool, no agent, no capability. Issue #895, “Proposal: Agent Bill of Materials (Agent BOM) for AI agent components”, proposed exactly this, listing “MCP servers the agent connects to (name, version, hash)” and “Tools the agent has access to (tool definitions, capability scopes)” among its components. It was opened on 26 March 2026 and closed on 29 April 2026, with the reply that “Agentic AI is being addressed in the ongoing work of the Blueprints and Threat Modeling working groups.” The separate issue #702, open against the 2.0 milestone, files “agent cards” under “Additional considerations” as something to extend modelCards towards, which is a note rather than a design.

SPDX had a design and withdrew it. PR #1113, “Add AIAgent as subclass of SoftwareAgent”, drafted an AIAgent class and modelled tool access through the usesTool relationship that the Core vocabulary already carried, rather than inventing a field. Reusing an existing relationship is structurally the right shape: a link between the agent and the things it can invoke. The pull request was closed unmerged on 15 November 2025 with the comment “With the current state of direction within the AI WG, the fundamental design has changed.”

The higher-level guidance considered it and declined. The G7 minimum elements document weighs a standalone autonomy element, “particularly around agentic AI”, and then records that “while the group recognized the importance and relevance of decision making or autonomy of an AI system to cybersecurity, it was decided to not explicitly call it out as a separate element.”

To check whether this was a gap in what vendors write about rather than in the formats themselves, we read six current AI BOM explainers on 17 August 2026 and looked only at each one’s list of what the BOM contains: Palo Alto Networks, Checkmarx, Cycode, Manifest Cyber, Sysdig and Snyk. None of the six component lists carries tools, plugins, function calling or MCP servers as a component class. The nearest miss is Sysdig’s “Interfaces and protocols”, which is about model-serving APIs and names none of those. Two of the six use the word loosely elsewhere: Snyk’s opening sentence calls an AIBOM “a comprehensive list that shows all the AI models, tools, and data used in a software application”, and Sysdig’s introduction mentions “AI models and tools with AI capabilities”. Neither develops it into a field.

How do you list an MCP server in a CycloneDX BOM right now?

You use a workaround that covers most of the surface and visibly fails on the rest. The split is structural rather than a matter of taste.

Packaged servers go in components, because they have package identity. Four of the five package ecosystems we score map cleanly onto an existing purl type: pkg:npm/, pkg:pypi/, pkg:nuget/ and pkg:oci/. A server distributed that way is a dependency like any other, and every SBOM tool you already run will pick it up without knowing it is an MCP server at all. On 18 August 2026, our scan of the official registry found 7,469 npm, 3,298 PyPI, 726 OCI and 102 NuGet components.

MCPB bundles have no purl type at all. There is no pkg:mcpb among the 42 types in the registered purl type index. The 847 MCPB components our scan found on that date have no canonical package identity a BOM can reference, so the best available entry is a file component with a hash and a download URL, which loses the ecosystem, the resolvable name and any chance of correlating it with an advisory.

Remote servers have no package identity whatsoever. They are an HTTPS endpoint, which in CycloneDX means the services array rather than components. A service object carries endpoints, authenticated, x-trust-boundary and data, which is genuinely useful: those four fields say who you talk to, whether you authenticate, whether the call crosses a trust boundary, and which way data moves. They are also generic reuse of a service model designed for microservices, not a defined representation of an MCP server. Remote components are the largest single group we see: 12,682 of the 25,124 components in our scan on 18 August 2026, just under half.

In every case, externalReferences is where the evidence link goes: the repository, the registry entry, and the URL of whatever trust assessment you relied on.

What should a tool-surface BOM entry contain?

Every field below is something a verifier can establish from outside the server, which is the same discipline the rest of a BOM follows.

• Server identity and version. A purl where one exists, an endpoint URL where it does not, plus the registry entry it was resolved from.
• Protocol revision. Which dated MCP specification the component declares. That determines which security requirements apply to it.
• Transport. stdio, Streamable HTTP or SSE. stdio means a local process with local reach, so transport is a trust boundary.
• Authentication requirement. Whether the endpoint demands credentials, and of what kind. The authenticated flag CycloneDX services already carry is the right idea, one level too coarse.
• Capability counts. How many tools, resources and prompts the component exposes. A count that changes is a surface that changed.
• A schema hash over the tool definitions. The names, descriptions and JSON Schemas, canonicalised and hashed.
• Output-schema coverage. What proportion of tools declare an outputSchema, which is a decent proxy for whether the results can be validated before the model reads them.
• A dated trust verdict. Not a score alone: a score, the criteria version behind it, and the date it was established.

None of this requires a new format to invent AI-specific vocabulary.

How do you keep an AI BOM current when the tools change under you?

A model version is pinned. A package version is pinned, and a lockfile pins it harder. A remote MCP server is neither. Its tool list is fetched at connection time, and the publisher can add a tool, reword a description or widen a schema without any version number moving, because there is often no version number to move. Your BOM says the same thing it said last month, and the component it describes is not the same component.

That has two consequences for how a tool entry should be written:

A version string is not an integrity claim for a remote server. The content hash is. Hash the canonicalised tool definitions, store it in the BOM entry, and re-fetch on a schedule. A changed hash is not evidence of an attack, and most changes will be ordinary feature work, but nothing else tells you a review is due. The same defence that catches a rug pull, described in the prompt injection post, moves up into the inventory layer here, where it can be audited.

Every tool entry needs a re-verification date, not just a creation date. “This is what the server exposed on 18 August 2026” is a true and useful statement. “This is what the server exposes” is neither, once the server is one you do not control.

Where to go next

• The controls that make a server worth listing at all: MCP security best practices.
• Why tool text is part of the attack surface: MCP prompt injection and tool poisoning.
• What to check before you install one: MCP server security.
• How we establish the fields above: the scoring methodology and the build provenance guide.
• The wider supply-chain picture, SBOMs included: software supply chain security.
• What a proxy in front of several servers does to all of this: MCP gateways.

An AI BOM is worth producing. It answers real questions about models and data that nothing else answers. It just is not yet an inventory of an agentic system, because the formats it is written in have no word for the thing an agent uses to act, and the two attempts to give them one both stalled. Until a format ships that field, record the servers yourself, hash their tool definitions, and date the record.