A friend of mine runs security at a mid-sized fintech. About six weeks ago she called me, mildly furious, because her board had asked a question she couldn't answer: "How many AI models are running in production, and what data do they touch?"
She did what any reasonable CISO would do. Pulled the SBOM exports out of her SCA tool. Cross-referenced with the cloud asset inventory. Asked the platform team. Asked the ML team. Three different answers. The SCA tool said they had four models because it counted the transformers package four times. The cloud inventory found eleven SageMaker endpoints, two of which had been decommissioned a year ago but still had IAM roles attached. The ML team, who actually build the things, said the real number was somewhere around thirty — including a couple of fine-tuned Llama variants nobody on the security team had ever heard of, running on a self-hosted vLLM cluster behind an internal load balancer.
The part that really got her was the fine-tunes. She had no record of what base model they came from, what data was used to tune them, who approved the training run, or what guardrails were in place at inference. Her DLP team had no idea customer PII had been in the training corpus. Her compliance team had been telling auditors for two quarters that the company used "only approved foundation models from approved providers."
It was all technically true. It was also, functionally, a lie.
That's the conversation that convinced me the AIBOM problem is the defining inventory problem of this decade. And it's the conversation I keep having with security leaders who thought they had it covered.
The thesis
An AI Bill of Materials is not an SBOM with a few extra fields. It's a fundamentally different artifact, with different lifecycle semantics, different consumers, and different failure modes. The vendors selling you "AIBOM" today by appending model.gguf rows to a CycloneDX file are not solving your problem. They are giving you a checkbox for an auditor who doesn't know any better — and a false sense of completeness that will absolutely burn you the first time a regulator, a customer, or a board member asks a real question.
Let me walk through what an AIBOM actually has to capture in 2026, where the current tooling falls short, and what I think the architectural answer looks like.
What an SBOM was built to answer, and why that breaks for AI
SBOMs were designed to answer one question: if a CVE drops tomorrow, can I tell you which of my deployed artifacts contain the vulnerable package? That's it. The whole format — package URLs, version pins, dependency trees — is optimized for that lookup. Log4Shell happened, and the industry collectively agreed we needed this artifact, and we built tooling for it.
AI systems break the SBOM model in at least four places.
First, the artifact is not a package. A model is weights plus architecture plus tokenizer plus prompt template plus inference runtime plus, sometimes, a fine-tuning delta. None of those are versioned the way lodash@4.17.21 is versioned. The same Llama 3.1 8B can show up in your environment as a GGUF quant, an AWQ quant, a HuggingFace safetensors checkpoint, a vLLM-served endpoint, and a LoRA adapter on top of a different base — and your SBOM will either miss four of those or count them as five different things with no relationship between them.
Second, the supply chain isn't a dependency tree. It's a directed graph of training runs, data sources, base models, adapters, and evaluation artifacts. The "depends on" relationship between a fine-tuned customer-service model and the original Mistral checkpoint is not the same kind of relationship as the one between your Python app and its requirements.txt. Pretending it is loses all the information that matters.
Third, the risk isn't CVE-shaped. The questions you actually need to answer are: was this model trained on data we had rights to? Does it have known prompt-injection susceptibilities? Is it on a sanctions list or export-controlled? Has its provider changed terms? Was the checkpoint backdoored? Does it leak training data under inversion attacks? None of those map cleanly to a CPE lookup.
Fourth, the artifact is live. A model behind an API can change underneath you with zero notification. Your "AIBOM entry" for gpt-4o-2024-08-06 is a snapshot, not a contract. The provider can deprecate, retrain, A/B test, and change safety filters without telling you. SBOMs assume the package on disk is the package you scanned. That assumption is gone.
If your vendor's AIBOM doesn't reckon with all four of these, what you have is a spreadsheet with a fancier name.
The five things a real AIBOM has to capture
Here's where I'll get specific, because I've watched too many "AI governance" demos that hand-wave this part.
A real AIBOM, in my view, has to capture the model identity as a composite — base model, quantization, adapter stack, tokenizer, runtime, and the cryptographic hash of the actual weights on disk where applicable. Not just llama-3.1-8b. The actual fingerprint. We've found in our own scanning at Cybrium that two checkpoints labeled identically can differ by gigabytes once you hash them, because somebody applied a LoRA and re-saved.
It has to capture the deployment context: where the model runs, what serves it, what data is allowed to reach it, and what egress paths exist. This is where Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp — the seven inference runtimes that cyradar covers — each introduce their own attack surface. A model running behind vLLM with the OpenAI-compatible API exposed on a Kubernetes service is a very different risk than the same model running in Ollama on a developer's laptop. Same weights, different threat model.
It has to capture the data lineage: training data, fine-tuning data, RAG corpora, system prompts, and the provenance of each. This is the field that vendors most often skip, because it's hard, and because customers haven't yet learned to ask for it. They will, the first time someone gets sued.
It has to capture the policy posture: what guardrails are configured, what evals were run, what red-team results exist, and what compensating controls are in place at the application layer. An AIBOM without this is like an SBOM without a vulnerability scan attached.
And it has to capture time: when each of these was measured, by what tool, and against what state of the world. Because models drift, providers change terms, and the AIBOM you generated last quarter is already stale.
That's the irreducible minimum. Anything less is theater.
Where the current tooling falls down
I'll be blunt. Most "AIBOM" products I've evaluated in the last year do one of three things:
They extend CycloneDX with a few ML fields and call it done. CycloneDX 1.6 added an ML component type, which is a step forward. But the format treats a model as a leaf node with metadata, not as a graph of artifacts and training events. You can put a model in a CycloneDX file. You cannot meaningfully describe a fine-tune lineage in one. The schema is fighting you.
They scrape HuggingFace metadata and call it provenance. If your vendor is showing you license info, parameter counts, and model card snippets pulled from the HF API, that's nice, but it tells you what the model claims to be. It doesn't tell you what's actually deployed in your environment, and it certainly doesn't catch the analyst who downloaded a quantized variant from a random repo and dropped it into an internal app.
They focus exclusively on hosted API models. This is the worst failure mode. About half the AI security tools on the market in 2026 still effectively assume "AI" means "calls to OpenAI, Anthropic, or Gemini." Meanwhile, the actual growth in enterprise AI deployment is in self-hosted inference. The teams shipping the most production AI right now are running their own models on their own infrastructure, and the tools that only watch egress to api.openai.com are blind to all of it. This is why cyradar specifically targets the self-hosted stack — because that's where the real inventory gap is.
There's a fourth failure mode I'll mention briefly: tools that generate AIBOMs without ever scanning the code that calls the models. Your AIBOM should agree with what your code does. If cyscan's 1,815 rules across 75+ languages find a call to a Bedrock endpoint that doesn't appear in your inventory, you have a problem — and the only way to catch it is to scan the source, not just the runtime.
The integration question that nobody wants to answer
Here's the thing I want every security leader to internalize. An AIBOM is not a static artifact. It is a continuously reconciled view across at least four data sources: source code analysis, runtime discovery, network behavior, and policy/control state. If any one of those sources is missing, your AIBOM is wrong in a specific, predictable way.
Source code analysis tells you what the developers intended to call. Runtime discovery tells you what's actually loaded. Network behavior tells you what's actually being talked to. Policy state tells you what's supposed to be allowed. The interesting findings — the ones that matter — live in the deltas between these views.
A model loaded on a GPU node but never called from any code path? Probably a dev experiment that got left running. Cost and attack surface, no business value.
A code path that calls a model that doesn't appear in runtime discovery? Either dead code or, more interestingly, a call to a shadow endpoint someone spun up on the side.
A model that's called from code, runs at runtime, and talks to an external API the policy didn't sanction? That's the data exfiltration question your board will ask about eventually.
You cannot answer any of these from a CycloneDX file. You answer them from a system that holds all four views simultaneously and reconciles them on a schedule.
Why one platform actually matters here
I'm going to argue something that sounds self-serving, but I'll defend it. The AIBOM problem is the single best argument I know for unified tooling over best-of-breed point solutions.
Here's why. If your code scanner is one vendor, your runtime scanner is another, your network telemetry is a third, and your policy engine is a fourth, you are now in the integration business. You have to write the reconciliation logic yourself. You have to maintain schema mappings as each vendor evolves. You have to figure out which one is authoritative when they disagree. And they will disagree, constantly, because they each see a slice of the world and none of them sees the whole thing.
The reason we built Cybrium the way we did — cyscan for code (1,815 rules, 75+ languages), cyradar for self-hosted runtime discovery across the seven major inference stacks, cyweb for the application-layer fuzzing (22 categories, 95% template conversion against the community baseline), all surfaced through a single MCP server exposing 10 tools to whatever agent or assistant you point at it — is that the AIBOM only works when the views reconcile against a shared model of the world. Different vendors can absolutely contribute data into that model. But somebody has to own the reconciliation. If it's not your platform, it's you. And you don't have time.
The MCP server piece matters more than people realize, by the way. An AIBOM you can only query through a vendor UI is an AIBOM you'll only look at during incidents and audits. An AIBOM your engineering teams' AI assistants can query directly — through ten well-defined tools — is one that gets used in pull request reviews, in design discussions, in the daily work where the inventory actually changes. That's the difference between governance theater and governance that compounds.
The recomposition that's actually happening
What I've been watching over the last eighteen months is a quiet recomposition of the security tooling stack around the AI control plane. SBOM tools are racing to bolt on AI fields. CSPM tools are adding model discovery. DLP tools are adding prompt filtering. CNAPP vendors are pitching "AI-SPM" as a new module.
All of those are responses to the same underlying truth: the artifacts your business runs on have changed shape, and the existing categories don't fit. The vendors who win this recomposition will not be the ones who staple AI features onto existing products. They'll be the ones who rebuild the data model from scratch around the actual artifacts — models, adapters, prompts, training events, inference endpoints — and treat the older artifacts (packages, containers, repos) as one input among several.
That's the bet I'm making with Cybrium, and it's the bet I'd encourage every CISO to make with their own tooling strategy. Don't ask your vendor "do you support AIBOM." Ask them how their data model represents a fine-tuned adapter stack, how they reconcile code-discovered model calls against runtime-discovered endpoints, and how they handle the case where a self-hosted vLLM instance is serving a model that doesn't appear in any procurement record. The answers will tell you immediately whether they've done the work or they're just selling you a relabeled SBOM.
My friend at the fintech, the one whose board asked the question? She spent about two months building her real inventory. Thirty-one models, eight of which had no clear owner. Three of which were running on infrastructure that had been quietly transferred to a different business unit during a reorg. Two of which were fine-tuned on data that violated her own data-handling policy. She presented the findings to her board, fixed what she could fix, and now she runs a quarterly reconciliation. She told me last week that the inventory itself has become her single highest-leverage control. Not because it prevents anything directly, but because it makes every other conversation — with engineering, with legal, with the board — actually grounded in reality.
That's what an AIBOM is for. Everything else is paperwork.
If you're trying to figure out what your real AI inventory looks like — not the one in the procurement spreadsheet, the one that's actually running — take a look at cyradar for the self-hosted side and cyscan for the code-call discovery side. If you want to talk through yours, find me at anand@cybrium.ai.
