Guide · Implement
How to build an AI bill of materials
Your SBOM lists the libraries your code imports. It does not list the model that wrote the code, the skill that told the agent how, or the MCP server that gave it database access. Those are the components that decide what your agents do.
before you start
- Your existing SBOM tooling and format choice, if you have one.
- Access to per-surface configuration on developer machines.
- A decision on granularity — see step one, and make it before you start collecting.
Why the obvious approach does not work
Software bills of materials work because a dependency is a stable, declared, versioned thing: it appears in a manifest, resolves to a lockfile entry, and hashes consistently. Every one of those properties is absent for the artefacts an AI agent loads. A skill is a folder someone copied. A rules file is markdown. An MCP server is a command in a config file, often pointing at a floating tag. There is no manifest, so there is nothing for a conventional scanner to read.
This matters because the artefact layer has more influence over behaviour than most dependencies do. A library changes what a function returns. A skill changes what the agent decides to do, and a connector changes what it can reach. When you need to answer 'what was this agent operating under when it did that', the model version is the least interesting part of the answer and the only part anyone currently records.
The formats are further along than the tooling. CycloneDX has published an ML-BOM capability covering models, datasets and their properties, so the model side has a real standard to target rather than a bespoke spreadsheet. What no standard covers yet is the agent-artefact layer — skills, rules, hooks, prompts, connector definitions — which means you will be extending a format rather than adopting one, and you should be explicit about that in your own documentation.
The failure mode to plan for is staleness, not incompleteness. An AI-BOM that is 70% complete and current is operationally useful; one that was 100% complete last quarter is a document, not an inventory. Artefacts change far faster than dependencies — a rules file can be edited daily — so decide your granularity for the churn you can actually sustain, which is the subject of step one.
The procedure
Decide granularity before you collect anything
Pick the level you can keep current. Per-artefact-version is ideal and expensive; per-artefact with a last-changed date is usually the sustainable choice; per-surface is nearly free and rarely enough. Make this call deliberately and write down the reason, because retrofitting granularity means recollecting everything. Err toward the level you can automate rather than the level you would like to have.
you now haveA written granularity decision with its rationale, and the churn rate you are designing for.
Inventory the model layer using an existing format
Record which models are in use, by which surface, under which terms, with which retention and training settings. CycloneDX's ML-BOM capability already covers models and datasets, so target it rather than inventing fields. Include the model configuration your organisation set — retention and training opt-out are the properties an auditor will ask about, and they are organisational choices rather than model facts.
you now haveA model inventory in a standard format, including per-surface terms and retention settings.
Inventory the artefact layer, which nothing covers yet
For each surface, enumerate the skills, rules files, commands, hooks and system prompts in play. Record name, source, version or content hash, install date and owner. This is the section with no standard, so define your own fields and document that they are an extension. Expect this to be the largest and least tidy part of the inventory, and the part that most repays automation.
you now haveAn artefact inventory with a hash and an owner for every entry.
Inventory connectors with their credentials and scopes
List every MCP server and connector: what it connects to, which credential it holds, what scope that credential has, and which surfaces use it. Then reconcile it against the credentials your identity provider and cloud accounts have actually issued. That reconciliation is where the real findings live — the gap between the connectors you know about and the tokens that exist is usually the most interesting output of the whole exercise.
you now haveA connector inventory reconciled against issued credentials, with the deltas listed.
Attach it to the machines, not just the org
An inventory that says 'the company uses these twelve artefacts' cannot answer an incident question. You need to know which machine held which version when. Even a coarse per-machine snapshot on a schedule beats a perfect org-level list, because incident response is always machine-scoped and always retrospective.
you now havePer-machine artefact snapshots with timestamps, however coarse.
Automate collection or accept a decay date
Decide how each section refreshes and how you would notice a new artefact appearing. If a section is manual, write its expiry date on it — 'accurate as of' is honest and useful; an undated inventory implies a currency it does not have. Sections you cannot automate are the ones to argue for tooling on, with the decay rate as your evidence.
you now haveA refresh mechanism per section, or an explicit expiry date on the manual ones.
AI-BOM field set
Layer 1 maps to CycloneDX ML-BOM. Layers 2 and 3 are extensions — no standard covers them yet, so document them as your own.
AI-BOM field set
LAYER 1 — MODELS (CycloneDX ML-BOM covers this; use it)
model identifier and version
provider and the surface(s) using it
contractual terms in force (enterprise / consumer / API)
data retention setting as configured by us
training opt-out status, confirmed in writing
region / data residency
LAYER 2 — ARTEFACTS (no standard yet; extension fields)
artefact name and type (skill | rules | command | hook | prompt | agent)
source (registry | repository | vendor | internal | unknown)
version or content hash of what is installed
whether it contains executable content [ yes | no ]
review status, reviewer, review date
owner
surfaces it is loaded into
install date and last-changed date
LAYER 3 — CONNECTORS (no standard yet; extension fields)
connector / MCP server name and version pin
transport and endpoint
systems it can reach
credential identifier held
credential scope, and the minimum scope that would work
read / write / execute classification
surfaces using it
review status and date
LAYER 4 — PLACEMENT (what makes it usable in an incident)
machine or environment identifier
artefact + connector versions present, with timestamp
principal the surface ran as
PER SECTION, ALWAYS RECORD:
collection method (automated | manual)
accurate-as-of date
ownerWhere this goes wrong
- Extending the SBOM tool and stopping at models
Model inventory is the easy layer and the least behaviourally significant. A bill of materials that lists models but not skills and connectors has catalogued the component with the least influence over what your agents do.
- Choosing granularity you cannot sustain
Per-artefact-version sounds right and dies on first contact with a rules file that changes daily. Pick the level you can automate, and write down why.
- An org-level inventory with no machine dimension
Every incident question is machine-scoped and retrospective. Without placement data the inventory cannot answer the question it will be asked.
- No expiry date on manual sections
An undated inventory is read as current forever. Dating it is cheap, honest, and turns a stale document into usable evidence.
Doing this without us
Layers 1 and 3 are assembled today with scripts, your identity provider and CycloneDX tooling — worth doing immediately, and the connector-versus-credential reconciliation usually pays for the whole effort on its own. Layers 2 and 4 are where manual collection breaks down: artefacts change faster than a human can record and placement data has to be continuous to be worth anything. That continuous inventory is what Vincosha Registry produces as a by-product of distributing the artefacts in the first place.
Frequently asked
- Is an AI-BOM the same thing as an ML-BOM?
- An ML-BOM covers models and datasets, and CycloneDX has a published capability for exactly that. An AI-BOM as described here is broader: it adds the agent-artefact layer — skills, rules, hooks, connectors — that determines behaviour but has no standard yet. Use ML-BOM for the model layer and treat the rest as a documented extension.
- Can our existing SBOM tooling do this?
- For models, increasingly yes, especially if you are already on CycloneDX. For artefacts, no — the tooling works by reading manifests and lockfiles, and there is no manifest to read. Skills and MCP configurations are not declared dependencies, so a scanner has nothing to parse.
- Do we need this if we only use one AI tool?
- The artefact and connector layers apply in full with one tool, and those are the layers that carry the risk. What one tool saves you is reconciliation across surfaces — real work, but the smaller half.
- Where does the connector reconciliation usually surprise people?
- In the gap between connectors anyone knew about and credentials that were actually issued. Tokens outlive the experiments that created them, so the delta between your connector list and your identity provider's grant list is typically the most actionable finding in a first pass.
Sources
Checked on 2026-07-25. Where a vendor control is changing quickly this guide describes the mechanism rather than asserting a current state — verify against the vendor's own documentation, and tell us if we have drifted.