Last post made the case that your SBOM has an AI-shaped hole in it. This one opens up aibom.json and walks the five things it records. Four of them are inventory. The fifth is the one that keeps security people up at night.
If you ran npx sbomix owner/repo on a repo with any AI in it, you already have this file in front of you. Read along.
The five dimensions
An AI-BOM is not a longer software BOM. It records a different kind of thing. Here is the shape.
- Provenance. Model weight files found on disk, SHA-256 hashed, recorded with the framework and version that loaded them. This is the "which model, exactly" answer your package list cannot give you.
- Data lineage. Training datasets tied back to the model component, with Hugging Face identifiers and governance metadata where it exists. Licenses on training data are their own minefield. Now they are written down.
- Infrastructure. MCP servers and API clients, catalogued with their authority scope. Local only, broad filesystem, remote network. This is where inventory turns into risk.
- Agentic scope. Capability flags pulled from your MCP config. Shell access. Filesystem breadth. Network reach. Unpinned tool versions.
- Governance. Your inventory mapped against ISO/IEC 42001 and EU AI Act technical documentation controls, with a coverage percentage per scan.
Provenance and data lineage answer "what is in here." Infrastructure and agentic scope answer "what can it do." That second question is the one almost nobody has an automated answer for.
Why agentic scope is different from every other line in your BOM
Every other dependency in your stack is passive. A library sits there until you call it. The worst a vulnerable npm package does on its own is nothing, until your code reaches it.
An MCP server is not passive. It is a standing capability with a scope you granted, often without thinking hard about it. You wired up a filesystem MCP server during development because it was convenient. It has read access to the whole working tree. That access did not expire when you shipped.
Here is the failure mode that makes this concrete. An agent in your pipeline has shell access through one MCP server and network egress through another. Neither is a CVE. Neither shows up in a vulnerability scan. Together they are a path: read a secret off disk, send it out over the network, no exploit required, because you authorized both halves yourself. The agent is doing exactly what it was permitted to do.
A package scanner will never flag that, because nothing is technically vulnerable. The risk lives in the combination of scopes, not in any single component. The AI-BOM is the only artifact in your build that writes those scopes down where you can review them.
What this means for you
Pull up the infrastructure and agentic scope sections of your aibom.json and ask three questions.
- Does anything have shell access that doesn't need it?
- Is any filesystem scope broader than the directory the tool actually works in?
- Are tool versions pinned, or floating?
If you can answer those in thirty seconds from a file your CI generated, you are ahead of most teams shipping agents right now. Most teams are answering from memory, which means they are guessing.
Try it on something agentic
The provenance and lineage fields show up on any repo with a model in it. The interesting fields need an MCP config. Run the scan on a repo that actually wires up agents:
npx sbomix owner/repoOpen aibom.json, find the agentic scope flags, and see whether the capabilities you granted match the ones you remember granting. The gap between those two is the whole reason this file exists.
Next post: this inventory is about to stop being a nice-to-have. The EU AI Act puts a date on it.
SBOMix on GitHub. MIT licensed, unlimited local scans.