m-sbom-for-ai · MITIGATION
SBOM for AI: the model, dataset and infrastructure record a general SBOM has no fields for
A conventional SBOM inventories libraries, images and packages. It has no field for the weight an agent loads, the corpus it retrieves from, or where that corpus was collected. An SBOM for AI adds those: seven clusters covering the system, its models, its datasets, its infrastructure, the security controls already in place, and the indicators used to watch it. It is recorded in addition to the general SBOM, never instead of it.
At a glance
What it is
An SBOM for AI is an inventory of the parts of an AI system that a conventional SBOM has no fields for: the models, the datasets those models were built and evaluated on, the infrastructure the system runs on, the security controls already in place, and the indicators used to watch it in production.
The reference element set is Software Bill of Materials for AI: Minimum Elements, published in 2026 by the G7 Cybersecurity Working Group and jointly issued by BSI, ACN, ANSSI, CSE, CISA, NCSC and NCO with the EU Commission. It is the first G7 guidance document on the subject, and it groups the elements into seven clusters: Metadata, System Level Properties (SLP), Models, Datasets Properties (DP), Infrastructure, Security Properties (SP), and Key Performance Indicators (KPI).
Detection signals
- A model or dataset in production with no entry in the SBOM for AI. The Models and Datasets Properties clusters are per-artifact, so a weight the agent loads or a corpus it retrieves from that no entry names is an undeclared component.
- A model hash value that no longer matches the loaded weight. The Models cluster records both the hash and the algorithm that produced it, so a checkpoint replaced after the record was generated fails the comparison.
- A declared dataset sensitivity that is lower than the sensitivity a scan infers for the store backing it. Either the running configuration does not reflect what the store holds, or the declaration is stale. Both are worth an answer.
Threats this addresses
Auto-generated from the coverage map in this mitigation's frontmatter. Each entry links to its threat detail page; the severity-reduction step and notes reflect what this control contributes to containing the threat.
WHY IT HELPS Supply Chain Compromise covers a compromised model, library, plugin, or prompt template reaching the agent. A general SBOM inventories the libraries and the image; it has no field for the weight the agent loads or the corpus it retrieves from. The Models cluster records each model's identifier, version, producer, hash value, hash algorithm and lineage, and the Datasets Properties cluster records each dataset's identifier, hash and provenance. That covers the half of T17 a conventional SBOM cannot express: a swapped checkpoint, an undeclared fine-tune, or a corpus assembled by a crawl nobody wrote down. One step rather than two, because the document is explicit that the record alone is not protection. It has to be connected to vulnerability scanning and security advisories before it changes an outcome.
It supplements the general SBOM. It does not replace it
The document settles this in its own words:
AI systems are also software systems. Therefore, SBOMs still remain valid for AI systems. The minimum elements in an SBOM for AI are in addition to the general SBOM minimum elements.
So this control sits on top of the signed agent SBOM, not instead of it. That control covers the general baseline and the mechanism: pin a hash for every component, sign the manifest, verify it before the agent accepts traffic. An SBOM for AI adds the AI-specific fields to the same record.
The split is easy to apply. An agent framework, its libraries, its container image and its plugins are ordinary software, and the general minimum elements already cover them. The model weight the agent loads, the corpus it retrieves from, and the accelerator it runs on do not appear there at all. Neither record is complete alone, and nothing in this one supersedes the other.
What the seven clusters ask for
Metadata describes the SBOM for AI document itself rather than the system: author, version, data format name and version, author signature, tool name and version, generation context, timestamp, and dependency relationship.
System Level Properties (SLP) describes the system as a whole. Its examples are the ones an agentic system will recognise: the APIs of external services the system uses, multi-agent communication protocols, and bidirectional data flow towards external services for web grounding.
Models carries thirteen elements per model: name, identifier, version, timestamp, producer, description, hash value, hash algorithm, properties, input-output properties, training properties, license, and external references. Lineage lives inside the description element, which is where the predecessor model a fine-tune came from, and any known derivatives, get written down.
Datasets Properties (DP) carries ten elements per dataset: name, description, content, identifier, hash, provenance, statistical properties, sensitivity, dependency relationship, and license.
Infrastructure lists the software required to deliver and run the system, and links to a Hardware Bill of Materials where one exists, so specialised AI hardware is covered too.
Security Properties (SP) records the controls implemented, the compliance held, the producer's published security.txt, and where to look up known vulnerabilities in the model or system. Its AI-specific examples include adversarial robustness training and prompt-injection controls for LLM-based agents.
Key Performance Indicators (KPI) records security metrics and operational performance indicators across the system's lifecycle phases.
Where this meets what Helmwart already computes
Two Datasets Properties elements name properties the engine already carries on every data node, which makes the relationship between a scan and an SBOM for AI concrete rather than thematic.
Dataset sensitivity. Every data store in a scanned graph carries a sensitivity value, and the report's asset inventory prints it. The engine derives that value from the configuration it was handed and stamps the result basis: 'inferred', so nobody reads a guess as a business determination. The AI-BOM element is the declared counterpart: the dataset's owner states whether it holds PII, freely accessible data, copyright-protected material, sensitive records such as financial or medical data, or national-security data. The scan infers, the SBOM for AI declares. Where the two disagree, that gap is the finding: either the running configuration does not reflect what the store actually holds, or the declaration has gone stale.
Dataset provenance. The engine reads provenance on document stores, shared memory and tool buses, and treats untrusted or partial as the untrusted-content leg of the lethal trifecta. That is a three-value trust judgement about a live source. The AI-BOM element is a history: where the data came from, how it was collected, what preprocessing, curation and labelling steps were applied, who created it, and for synthetic data, the method used to generate it. A trust judgement should rest on exactly that history. Today ours rests on whatever the imported configuration happened to reveal.
The two elements flow in opposite directions, and it is worth being precise about which is which. Sensitivity flows from the declaration into the scan: an SBOM for AI states what a store holds, which is a fact a config file usually does not encode, so the declaration is the better input. Provenance flows the other way: a scan that puts an untrusted corpus on a trifecta path has identified, by graph position, which dataset's provenance entry most needs to exist and be accurate.
Threat coverage, and what is deliberately not claimed
This control is mapped to T17 Supply Chain Compromise only, at one severity step.
T17 covers a compromised upstream component reaching the agent: a model, library, plugin, or prompt template. The model and dataset halves of that list are what an SBOM for AI adds, through the Models cluster's hash value, hash algorithm, producer and lineage elements and the Datasets Properties cluster's hash and provenance elements. T17's own page already directs a reader to check for AI-specific bills of materials covering the agent's runtime components, so this is the control that page asks for.
Three neighbouring threats are not claimed, and the reason is the same in each case: the general SBOM already covers them, and claiming them again here would count one control twice.
- T29 Plugin Vulnerability Leading to Agent Compromise. A plugin is ordinary software with a version and a hash. The general minimum elements inventory it, and the signed agent SBOM already claims T29 on that basis. The Infrastructure cluster mentions tools used by the AI system, but adds nothing a plugin entry in a conventional SBOM does not already carry.
- T20 Framework Vulnerability Leading to Code Injection. Knowing which framework version is loaded is the control for T20, and a framework is a software dependency. Nothing in the seven clusters improves on the general SBOM's answer.
- T25 Workflow Disruption via Dependency Exploitation. The SLP cluster does record the APIs of external services the system uses, which makes the dependency set explicit. But an inventory is a precondition for a fallback, not a fallback. Availability is addressed by the controls that degrade gracefully, not by the record.
What it does not do
The document is unusually direct about its own limits, and repeating them is part of using it honestly.
The elements create no obligation. The executive summary states they "are not mandatory; do not create requirements, standards, or legislation; and are open to further refinements". Producing a conforming record is not a compliance outcome.
The record is not itself a defence:
Besides addressing single elements, the authors highlight that an SBOM for AI by itself is not sufficient for increasing cybersecurity along the supply chain. To ensure substantial protection of the AI supply chain, it is necessary to connect the SBOM for AI to cybersecurity tools, such as vulnerability scanning and management tools, security advisories and bulletins, and promoting development of adaptable and evolutionary tooling mechanisms.
That is why the coverage above is one step and not more. An inventory nothing reads changes nothing.
Finally, one omission matters directly to agentic systems. The working group considered recording an AI system's level of decision-making or autonomy, noted that it "might become more relevant due to the fast-changing developments in technology, particularly around agentic AI", and decided not to call it out as a separate element. So an SBOM for AI tells you which model and which data an agent was built from. It does not tell you how much the agent is allowed to decide on its own. That question stays with the threat model.