SBOM for AI

Supports: Establishes what this element set is and who agreed it: seven national cyber agencies reaching consensus over a defined work window, not one vendor publishing a format. The executive summary names the publishers as BSI (Germany), ACN (Italy), ANSSI (France), CSE (Canada), CISA (United States), NCSC (United Kingdom) and NCO (Japan), in collaboration with the EU Commission.

Does not prove: Does not make the document a standard or a specification. It is guidance, and the same paragraph describes it as the outcome of a discussion that "led to a co-created list of minimum elements through consensual decision-making" rather than a formal balloting process. It also carries no explicit publication date beyond the year on its cover.

Supports: The relationship between this control and the signed agent SBOM, stated by the source rather than inferred. An SBOM for AI is recorded in addition to the general minimum elements. It does not replace them, and it does not supersede m-sbom. Any framing in which an AI-BOM makes a conventional SBOM unnecessary contradicts the document directly.

Does not prove: Does not say which general SBOM baseline applies, nor how the two records should be linked, packaged, or published together. The document sets out AI-specific elements and leaves the general baseline to the general guidance.

Supports: Fixes the standing of the element set. Producing a conforming record is a transparency practice, not a compliance outcome, and nothing here can be cited as an obligation on a team shipping an agent.

Does not prove: Does not mean the elements are without force. The same paragraph notes that "in some jurisdictions, certain elements proposed in this document may already be, or may be expected to be, addressed through legal requirements and obligations, or through existing or forthcoming standards", so a local obligation may exist independently.

Supports: Confirms the count and the shape: seven clusters, with Metadata describing the document and the remaining six describing the system. The section headings are Metadata (§2.1), System Level Properties (SLP) (§2.2), Models (§2.3), Datasets Properties (DP) (§2.4), Infrastructure (§2.5), Security Properties (SP) (§2.6), and Key Performance Indicators (KPI) (§2.7). The body text adds that "the remaining clusters follow in no particular order".

Does not prove: Does not rank the clusters by security value, and explicitly declines to: all six non-Metadata clusters are called equally important. Nor is the list closed. §2 states that "some clusters have been adjusted, some added and some removed" during drafting, and the introduction says the list "is open for further expansion".

Supports: Sets how the Examples column should be read throughout this page. Several rows below quote examples rather than element descriptions, and this is the source telling the reader those examples do not bound the element.

Does not prove: Cuts the other way too. An example naming a concept does not make that concept a required field, so an implementation that records an element differently from its example is still conforming.

Supports: The one cluster that addresses multi-component systems directly, and it names AI agents in its own scope sentence. Its System data usage element lists, as examples, "Application Programming Interfaces (APIs) of external services the AI system uses", "multi-agent communication protocols", and "bidirectional data flow towards external services (web grounding)" (p. 10) — three facts an agentic architecture is built from.

Does not prove: Records the data flow, not its trust. Nothing in SLP asks whether a given flow carries attacker-influenceable content, which is the judgement a threat model makes and a bill of materials does not.

Supports: The half of the supply chain a conventional SBOM has no field for. The cluster carries thirteen elements per model: model name, identifier, version, timestamp, producer, description, hash value, hash algorithm, properties, input-output properties, training properties, license, and external references.

Does not prove: Identification and description, not assurance. The cluster records what a model is and how its weights were produced; it does not evaluate whether the model is safe to deploy, and the evaluation results it can point at live in external references.

Supports: Model lineage is a named part of the element set, and it is where a fine-tune is traced back to the checkpoint it came from. This is the record that makes an undeclared fine-tune visible as an undeclared fine-tune rather than as a model nobody looked at.

Does not prove: Lineage sits inside the free-text Model description element rather than in a structured field of its own, so it is documentation quality, not something a tool can validate. The same element also holds capabilities and known limitations.

Supports: Extends hash pinning from software artifacts to model weights, with the same stated purpose: validating the integrity of the target component. The paired Model hash value element is described as covering "the hash of the weights or model file or other model related artifacts".

Does not prove: Asks for the hash to be recorded; it does not prescribe verifying it when the agent loads the weight. It also permits an explicit unknown: "If the SBOM author does not have access to the executable component artifact, then the SBOM author should indicate the value is unknown." A conforming record therefore does not guarantee a hash exists for every model.

Supports: Scopes the dataset half across the model lifecycle rather than to training alone, which is what brings evaluation and fine-tuning corpora into the record. Ten elements: dataset name, description, content, identifier, hash, provenance, statistical properties, sensitivity, dependency relationship, and license.

Does not prove: Scoped to datasets used in the model lifecycle. It is not a statement about a live retrieval corpus that is written to continuously in production, and a hash taken over such a store at build time does not detect a later write.

Supports: The declared counterpart to the `provenance` field Helmwart already carries on document stores, shared memory and tool buses, where it feeds the untrusted-content leg of the lethal-trifecta detector. Our value is a three-state trust judgement inferred from an imported config; this element is the collection history that judgement should be resting on. The same example adds "the creator" and, "in case of synthetic data, the methods used to create it".

Does not prove: A history, not a verdict. The element records where data came from and what was done to it, and stops there. It does not classify a source as trusted or untrusted, so it is an input to a trust decision rather than the decision.

Supports: The declared counterpart to the `sensitivity` value Helmwart infers per data store and prints in a scan report’s asset inventory. The engine stamps its own reading `basis: ‘inferred’` precisely because it is derived from a configuration rather than declared by an owner. This element is the declaration. The element description reads: "Element used to express the type of data present inside the dataset, where type is related to the sensitivity level of the data."

Does not prove: Names categories, not a scale. There is no ordered sensitivity level in the element and no mapping to any classification scheme, so a declared sensitivity and an inferred one cannot be compared numerically. It is also a statement about a dataset, not about the store serving it in production.

Supports: Two elements only, Infrastructure software and Infrastructure hardware, and the hardware one is a link out to an HBOM rather than an inventory in its own right. The software element covers "dependencies to software components specifically required to deliver and run an AI system", with firmware, package managers, third party libraries, frameworks, runtime environments and tools used by the AI system given as examples.

Does not prove: Most of what this cluster lists is ordinary software already inside the general SBOM baseline. That overlap is the reason this control does not claim the framework-vulnerability or plugin threats: the general SBOM answers those, and claiming them again here would count one control twice. The hardware element is conditional on an HBOM existing.

Supports: Four elements: security controls, security compliance, cybersecurity policy information, and vulnerability referencing. Its AI-specific control examples name "adversarial robustness training", "prompt injection controls and tools for LLMs or LLM-based agents", "input/output filters", and "data-level controls (to curate training data)" — the same control vocabulary an agentic threat model works in.

Does not prove: Records which controls are claimed to be implemented. It does not test them, assess their configuration, or say whether they are sufficient for the deployment. A conforming SP entry is an assertion by the producer.

Supports: The smallest cluster, two elements: security metrics and operational performance KPIs. Security metrics are exemplified as "security related benchmarks and metrics, e.g., robustness (resilience against third-party manipulation)"; operational KPIs as system uptime, incident resolution time, system latency, request throughput, and load balancing.

Does not prove: Names no benchmark, threshold, or measurement method, so two conforming records can carry incomparable numbers. It is a place to publish what you measure, not a definition of what to measure.

Supports: The source setting its own ceiling, and the reason this control is mapped to T17 at one severity step rather than more. The record becomes a control when something reads it: a vulnerability scanner, an advisory feed, or a gate in a pipeline. On its own it is documentation.

Does not prove: Names no tool, integration, or format for that connection, and none of the seven clusters describes one. How an SBOM for AI reaches a scanner is left entirely open.

Supports: The gap that matters most to an agentic reader, recorded by the authors themselves. The same paragraph says the level of autonomy "might become more relevant due to the fast-changing developments in technology, particularly around agentic AI" and that including it "could help to assess the impact of a potentially damaging compromise". It was still left out. An SBOM for AI therefore says what an agent is built from and not how much it is allowed to decide.

Does not prove: Not a statement that autonomy is unimportant, and not a permanent exclusion. The stated reason is that the element "may be addressed differently across different jurisdictions, including through safety requirements", and the introduction leaves the list open to expansion.