SBOM tooling grew up. Point a scanner at your repo and it reads the lockfile, lists every npm and pip and cargo dependency, flags the known CVEs, and hands you a clean CycloneDX file. Compliance asks for an SBOM, you produce one. Good.
Then it stops.
It stops at the exact line where your software starts calling models.
Look at what a normal scan misses. Your app imports torch and transformers. It loads a model weight file from disk. It talks to the OpenAI API. It runs three MCP servers, one of which has filesystem access wide enough to read anything in the working tree. None of that lands in a standard SBOM. The dependency graph sees a Python package called openai and moves on. It has no concept of which model you called, where the weights came from, or what an agent is allowed to touch.
That is not a small gap. That is the part of your supply chain with the least history, the youngest tooling, and the fastest-moving risk.
What you'll learn in this series
- Why the AI layer is invisible to the SBOM tools you already run
- What an AI Bill of Materials records that a software one cannot
- Why MCP server scope is the entry that should make you nervous
- How the EU AI Act turns this inventory from optional into evidence
- How to wire the whole thing into CI in one command
The blind spot, concretely
Three things hide from a package-level scan.
Model provenance. You pulled a model. Which one, which version, hashed how. A requirements.txt line for transformers==4.x tells you the library. It says nothing about the weights you loaded at runtime or where they came from.
Data lineage. The dataset a model was tuned on carries its own license and its own governance baggage. Your SBOM has no field for it.
Agentic scope. This is the one people skip. An MCP server is not a passive dependency. It is a capability. Shell access, broad filesystem reach, network egress, unpinned tool versions. A package scanner records that you installed something. It does not record what that something is allowed to do once it runs.
You can have a perfect CycloneDX file and still have no idea that an agent in your stack can read every secret in the repo. The clean SBOM gives you a false sense of done.
Why this is happening now
Two years ago "what AI does your app depend on" was a fuzzy question with no standard answer. It has an answer now. CycloneDX, the OWASP standard published as ECMA-424, defines an AI/ML-BOM profile alongside the software one. The format exists. The hard part was never the schema. It was generating the thing without a human sitting down to inventory models by hand, which is stale the moment they finish.
That is the gap SBOMix fills. Same scan that produces your CycloneDX and SPDX files also detects the AI frameworks, hashes the model weights, catalogs the MCP servers and their scope, and writes a standalone aibom.json. One command. No flags. No separate tool you have to remember to run.
See your own blind spot
You don't have to take my word for the gap. Look at your own repo.
npx sbomix owner/repoIt clones, scans, and writes three files. The one to open first is aibom.json. If it comes back with models and MCP servers you forgot were in there, that is the point of this whole series. If it comes back empty, good. Now you have proof, not a guess.
Next post breaks down exactly what lands in that AI-BOM, field by field, and why the agentic scope section is the part worth reading twice.
The CLI is free and MIT licensed. Run it, then come back.