Clarion Street

Agents Broke the Software Bill of Materials

·6 min read

An SBOM is a “nested inventory, a list of ingredients” that make up software. That is CISA’s own description, and it has been accurate for years. The instrument was built around a picture of software as something a vendor assembles at build time and ships: a fixed set of components, each with a name, a version, and a producer, that an operator lists once and hands to a customer or an assessor. I have written about the burden-of-proof side of that instrument already, in the post on the open source CMMC compliance paradox. This post is about what happened to the instrument in 2026, which is that it got pointed at a thing that does not fit the picture.

Two documents did the pointing. In July 2026 CISA, the NSA, the FBI, and a long list of international partners published the 2026 Minimum Elements for a Software Bill of Materials, which “updates and replaces” the minimum elements NTIA published in 2021. Its scope section says the minimum elements “apply to all software,” and that AI software systems and software as a service “may require additional elements.” The 2021 version was written for software as it then was. The 2026 version keeps the all-software baseline but names the cases that need more, and it adds fields that only make sense if the SBOM is doing more than listing packages: an author signature, a tool version, a generation context.

Two months earlier, in May 2026, CISA and the G7 partners released the first SBOM for AI, Minimum Elements. It extends the SBOM to AI systems and names the target directly. Its system-level cluster is meant for “systems composed of multiple AI elements, such as classifiers, large language models (LLMs) or AI agents,” and it includes “all software dependencies and frameworks used in the AI system.” The document is careful about its own weight. The elements are “not mandatory” and “do not create requirements, standards, or legislation.” In the EU the Cyber Resilience Act is the one place an SBOM has become a legal obligation, and that obligation lands on manufacturers of products with digital elements, not on agent operators.

The documents themselves are not the problem. An SBOM assumes a static stack. A build happens, dependencies are pinned, and the inventory is generated at that point. An open source agent that writes code and pulls dependencies at runtime does not have a static stack. It has a continuously mutating one, so the inventory becomes something you regenerate rather than something you generate once. The agent is not just the subject of the inventory. It is also the producer of part of what the inventory is supposed to describe.

An SBOM tells you what is present. It does not tell you who, or what, produced it. For human-authored code that gap was manageable, because the producer was usually knowable: a vendor, a maintainer, a team. For agent-written code the producer is the model, and the model is not a field in CycloneDX or SPDX. The standards community has started to say this plainly. OpenSSF’s Security Insights project has an open issue, SIEP-171, on agent-produced code provenance. Its observation is that a consumer “cannot currently learn whether the code was produced wholly or partly by an AI agent.” A note in the thread puts the problem more sharply: this “does not fit SBOM (which is about dependencies, not production method).”

The security cost is not theoretical. A September 2025 study of four models across 439,138 prompts found that LLM-generated code hallucinates packages, domains, and GitHub accounts, and that non-existent components “could be exploited by adversaries to preemptively take ownership and hijack” downstream users. An agent that invents a package name is not a documentation gap. It is a squatting surface, and a format that records only what ended up in the manifest has no field for where the name came from.

The hole is real enough that people are selling against it. ForgeProof, a vendor, frames its product around exactly this: “SBOMs tell you what components are in your software. SLSA/Sigstore prove your build was untampered. But neither answers: which AI model wrote this code?” A March 2026 preprint makes the same point from the research side, calling conventional SBOMs “static dependency inventories [that] cannot capture runtime behaviour, environment drift, or exploitability context” and proposing “agentic AIBOMs” that monitor drift at runtime. Both are signals, not standards. The vendor is selling a product, and the paper is a preprint scoped to regulated analytic environments with human-in-the-loop disclosure control.

None of this is a requirement yet. The SBOM for AI guidance is not mandatory, and no CMMC or DFARS clause requires an AIBOM. The G7 document is international consensus, not U.S. regulation, and it carries no enforcement hook for a defense contractor beyond the baseline SBOM transparency the 2026 minimum elements describe. The G7 group considered adding a “level of decision making or autonomy of an AI system” element, “particularly around agentic AI,” and deferred it. How much autonomy an agent has, the part that determines risk, is not in the format either. The CMMC program is itself in flux, which I have covered in earlier posts and will not re-derive here.

The through-line I keep coming back to on this site is that the tool got cheaper and the proof did not. The agent version is stranger, because now the tool writes the subject of the proof. You are left with two stacked obligations. The first is to prove what your agents pulled in, continuously, and you can start on that today by regenerating an SBOM per build or per run instead of per release. The second is to prove who wrote what is in it, and that one has no standard yet. The honest answer for now is that you cannot satisfy it with a format. You can only capture it as policy and logs: the prompt, the model, the tool, and the human who authorized the run, kept as evidence you will be asked for later. It is not an SBOM, but it is the only provenance you can produce until someone finishes writing the field.

Sources

  1. Software Bill of Materials (SBOM) — CISA
  2. NIST SP 800-218 Secure Software Development Framework (SSDF) 1.1 — NIST CSRC
  3. 2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA
  4. 2026 Minimum Elements for a Software Bill of Materials (SBOM), PDF — CISA
  5. Software Bill of Materials for AI, Minimum Elements — G7 Cybersecurity Working Group (BSI)
  6. arXiv 2603.10057: SBOMs into Agentic AIBOMs
  7. arXiv 2509.20277: Investigating Security Implications of Automatically Generated Code on the Software Supply Chain
  8. OpenSSF Security Insights SIEP-171: Agent-produced code provenance fields
  9. ForgeProof — GitHub