AI BOMs need behavioral inventory
The AI bill-of-materials push borrows the SBOM playbook: inventory your models and datasets. Necessary, insufficient. An agent's risk lives in what it may do — the BOM must record tools, scopes, and policies too.
ReversingLabs has been making the case that AI supply-chain transparency should borrow the SBOM playbook, framed inside an "xBOM" catalog of a dozen bill-of-materials types — one of which, the ML-BOM, tracks models, datasets, parameters, training processes, and dependencies. The instinct is exactly right, and overdue: the software industry learned the hard way that you cannot secure what you have not inventoried, and AI systems have shipped for years with no equivalent of the ingredient list. (I'll flag that the specific field sets aren't a ratified standard yet, and some download-count figures in the surrounding coverage I couldn't independently confirm.)
But the ML-BOM as described inventories the wrong noun for the risk that actually keeps me up. It catalogs components — the model, the data, the libraries. That is necessary. For a traditional ML model it might even be sufficient, because a classifier's blast radius is its output. For an agent, it is a fraction of the picture, because an agent's risk is not in what it is made of. It is in what it is allowed to do.
Components don't cause the incident; behavior does
Run the incident-response test, which is the only honest way to evaluate a BOM. Something bad happened — an agent leaked data, took a destructive action, followed a poisoned instruction. Your response team pulls the ML-BOM and learns: the model, its version, its training lineage. Useful, and completely insufficient to reconstruct what happened. Because the harmful action was produced by a combination the component inventory never recorded: which prompt framed the task, which tools the agent could call, what permission scope those tools carried, which retrieval source fed it context, which policy version was live, and which deployment of all of the above was running at 03:14 when it went wrong.
The model artifact is identifiable. The behavior that caused the incident is not reconstructable. That gap is the entire problem, and a components-only BOM leaves it wide open. It is the security equivalent of a car recall that can name the engine model but not which brake firmware was flashed to which vehicles — accurate about the parts, useless about the fault.
rendering diagram…
From compliance inventory to incident-response graph
The upgrade is to make the AI-BOM a runtime manifest, not a static parts list — one that links each component's identity to the behavioral envelope it ran inside. Concretely, alongside model and dataset, the record carries: tool grants and their scopes (this agent could call these APIs, with these permissions), prompt and policy versions (the exact instruction and guardrail configuration in force), retrieval sources (what it was allowed to read), eval results at deploy (what was tested and passed before this version went live — the same eval-record discipline that should travel with any AI artifact), deployment version (so a specific incident maps to a specific configuration), and revocation paths (how to kill this agent's authority, and who can).
Do that and the BOM stops being a compliance checkbox and becomes an incident-response graph. When something goes wrong, the response team traverses it: this deployment ran that prompt with these tool scopes reading that source under this policy — here is the exact blast radius, and here is the revocation lever. That is the difference between "we know which model it was" and "we know what it could touch and how to stop it," and only the second one ends an incident.
At work, the version I keep meeting: an organization proud of its model registry — every checkpoint versioned, lineage tracked, the component BOM immaculate — and, in the same breath, unable to answer which tool permissions their production agent holds or which prompt version is live, because those live in a deployment config nobody treats as inventory. They built a beautiful parts list for a machine whose danger is entirely in its wiring. The first real incident is where they discover the registry was answering a question they didn't have.
Steal this
Extend your AI-BOM schema with five behavioral fields per deployed agent, today, even by hand: tool grants and scopes, prompt/policy version, retrieval sources, eval-result reference, and revocation path. Then run the tabletop: pick a hypothetical harmful action and time how long it takes your team to reconstruct the full behavioral context and revoke the authority using only the BOM. If the answer involves "we'd have to ask the team that deployed it," your inventory is a museum label, not an incident tool. The component list tells you what you built; the behavioral manifest tells you what it can do to you, and only the second one is worth anything at 3am.
A model registry names the ingredient — an agent BOM has to record the recipe, the permissions, and the recall number, because the incident lives in what the system was allowed to do, not what it was made of.
