Security and compliance teams have been asking for a software bill of materials, an SBOM, for years, mostly to answer one question after the next open-source vulnerability makes headlines: are we exposed. That question predates coding agents by a long way. It hasn't gone away now that a growing share of a repository's commits come from a session an agent ran, not a person typing.
The overlap between the two worlds is not accidental. An SBOM is an inventory. Once part of what goes into that inventory was chosen by an agent rather than a developer, the inventory alone stops being enough.
What an SBOM is
An SBOM is a structured, machine-readable list of every component and dependency inside a piece of software: libraries, their versions, their licenses, and increasingly their cryptographic hashes, so anyone downstream can check that what they received matches what was declared. The two dominant formats, CycloneDX and SPDX, both aim at the same goal from slightly different angles, and most build tooling today can emit one or the other automatically as part of a pipeline.
CISA's 2026 minimum elements guidance, which replaces the original 2021 NTIA baseline, is the closest thing to a shared definition of what a usable SBOM has to contain. It's also, notably, the first version of that guidance to name AI systems as a distinct product category rather than folding them into "software" by default.
What it already guarantees
A good SBOM answers a narrow set of questions well: what's in this build, which version, under which license, and does any of it match a known CVE. That's genuinely useful. It's why procurement teams ask for one before a vendor contract closes, and why the 2026 CISA revision adds fields like component hash algorithm and SBOM generation context, on top of the original component-and-version baseline: the goal is to make the document verifiable, not just present.
Software composition analysis tools build on exactly this inventory to flag known-vulnerable dependencies automatically, which is why "SCA" and "SBOM" show up together in most procurement conversations. Neither one, on its own, says anything about how the code around those dependencies came to be written.
What it does not cover when an agent writes the code
An SBOM describes what shipped in a build, at the moment the build ran. It doesn't describe the decision path that got there: which prompt or task produced a given file, what constraints or context the agent was given, whether a human reviewed the diff before it merged, or why one library was picked over an equivalent one. None of that is a gap in any specific SBOM tool. It's outside the scope the format was designed to cover in the first place, whether the code was written by a person or a session.
That distinction used to matter less, because the answer to "why is this here" was almost always a person you could ask. When an agent runs a loop, plans a change, edits files, and commits, the session that made those calls closes the moment the task finishes. The SBOM lists what the session produced. It says nothing about the session itself.
Why AI-generated code needs provenance too
This is exactly the direction regulators moved in 2026. Beyond adding hash and tooling fields, CISA published a companion resource specifically for AI systems, built with G7 partners, calling for documentation of the models, datasets, providers, and dependencies behind an AI system, not just its code-level components. The logic is the same one that drove the original SBOM push: you can't manage supply-chain risk in something you can't inventory, and "the code" is no longer the only thing in the supply chain worth inventorying once an agent, not just a library, sits upstream of what shipped.
An AI-generated function pulled in through an agent session sits in exactly the same gap. The dependency it introduces will show up correctly in the next SBOM. The reason it exists, and whether anyone signed off on it before release, won't.
SBOM, SLSA, and delivery attestation
This is where SBOMs meet a second, complementary standard: SLSA (Supply-chain Levels for Software Artifacts), which grades how trustworthy the build process itself is, not what's inside the artifact. At SLSA's higher levels, provenance is signed by a hardened build platform and expressed as an in-toto attestation: a verifiable statement that a specific builder produced a specific artifact, from specific inputs, through a specific recipe. Where an SBOM answers "what's in here," SLSA provenance answers "how was this actually built, and can I trust the pipeline that built it."
Both are real progress. Neither one answers the question a software house actually gets asked when a client pushes back on a delivery: not just what's in the build and how it was assembled, but who authorized the work, what the agent was told to do, and who reviewed the result before it went out. That's the layer above SBOM and SLSA that current tooling still leaves open: the one that ties intent, execution, and human sign-off together as one verifiable chain, the same line from request to production-ready covered elsewhere on this blog when the question is what an agent leaves behind once the session ends.
An SBOM is necessary. It was never meant to answer that question, and it still doesn't.