A friend of mine runs security at a mid-market fintech. About 400 engineers, Series D, the usual. Last month her board asked what should've been a simple question: "How many AI models are in production, and where did they come from?"
She gave the confident answer any CISO would give. Thirty-eight models. All tracked. All approved through the AI review board.
Then her team spent two weeks actually checking.
The real number was 147. Not thirty-eight. One hundred and forty-seven. The gap wasn't malice or shadow IT in the dramatic sense. It was ordinary engineering. A data scientist had pulled a fine-tuned Llama variant off Hugging Face for a churn model and never registered it. A backend team was calling an embeddings model through a wrapper library that shipped its own default. A customer support tool had swapped its underlying LLM twice in six months and nobody updated the review board doc. The vendor SBOM said "OpenAI API" and stopped there.
The part that got her: forty-one of those unregistered models had known safety issues. Not zero-days. Publicly disclosed problems with training data provenance, jailbreak susceptibility, or license terms that conflicted with her company's data handling policies. All fixable. All invisible because there was no real inventory.
She called me because she'd just spent $180K on an "AIBOM platform" that produced exactly the same thirty-eight-model view her team had already curated by hand. It found nothing new. It couldn't. It was reading the same registry her team had populated.
The thesis
An AI Bill of Materials is not a list of models. It's a runtime, buildtime, and dependency-time record of every AI artifact that touches your data or your users, with the provenance chain intact. Most vendors selling "AIBOM" in 2026 are shipping model registries with a compliance skin. That's not an AIBOM. That's a spreadsheet with an API. If your AIBOM doesn't tell you about the fine-tuned Mistral variant a contractor ran on a laptop last Tuesday, or the vLLM instance a platform team spun up for internal chat, it isn't doing the job.
What people actually mean when they say AIBOM
The SBOM conversation from 2021-2023 taught us a lesson we're about to relearn: bills of materials only matter if they're generated from truth, not asserted by policy. An SBOM that a developer types into a form is worthless. An SBOM extracted from the build system is useful. An SBOM correlated against running production is what you actually want.
AIBOMs need the same discipline, but the surface area is worse. For a traditional SBOM, you're inventorying code that a compiler produced. For an AIBOM, you're inventorying:
- Foundation models and their versions
- Fine-tunes, LoRAs, adapters, and merged variants
- Training and evaluation datasets, with provenance
- Prompt templates and system prompts (yes, these are artifacts)
- Vector stores and their embedding models
- Inference runtimes (vLLM, Ollama, TGI, Triton, LocalAI, llama.cpp, LM Studio)
- Guardrail models and safety classifiers
- MCP servers and the tools they expose
- Agent frameworks and their configured tool permissions
Any AIBOM that stops at "we use GPT-4o and Claude" is a rounding error on the actual attack surface. The self-hosted inference stack alone has become a distinct category. When we built cyradar, we specifically targeted Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp because that's where models actually run inside enterprises now. The API vendors get all the press. The self-hosted runtimes are where the incidents happen.
What most vendors ship and why it fails
Walk into any AI security vendor booth at RSA this year and you'll see the same pitch. A dashboard. A model registry. A compliance report generator. NIST AI RMF mapped to line items. EU AI Act attestation. It looks great in a demo.
Here's what's wrong with it.
The data is asserted, not observed. Someone had to enter the model into the registry for it to exist. If your registry has 38 models and your engineers deployed 147, the platform has no mechanism to close that gap. It's a passive vessel for information that already existed.
The provenance stops at the top-level artifact. "We use Llama-3.1-70B-Instruct" tells you nothing about which fine-tune, from which repo, quantized with which method, aligned with which preference dataset. In 2026 the interesting attacks live in exactly this middle layer. Training data poisoning, backdoor triggers embedded in LoRAs, license laundering through model merges. If your AIBOM can't distinguish between a base model and a fine-tune that was trained on scraped support tickets from your competitor, you're not doing AIBOM work. You're doing branding.
The runtime is invisible. The registry says "customer support bot uses Claude 3.5 Sonnet." The actual deployment has a fallback to a self-hosted Mistral for cost reasons that kicks in 8% of the time. Your AIBOM will not see this. Your incident response team will find out when a customer screenshots something the fallback said.
The scan surface is wrong. Every AIBOM vendor I've evaluated scans the model card, maybe the config.json, maybe the tokenizer. None of them scan the actual code that instantiates the model. Which is where the real detail lives. When cyscan runs across a repo, it applies 1,815 rules across 75+ languages, and a meaningful chunk of those rules are specifically about how models get loaded, wrapped, called, and chained. That's where the ground truth is. Not in a curated card.
What a real AIBOM looks like
I'll describe the shape rather than list features, because features are how vendors hide the actual gaps.
A real AIBOM starts from three sources of truth and reconciles them. The first is code. Every repo in your org, scanned for model instantiations, API calls, framework usage, inference client libraries, MCP server registrations, and the graph of what calls what. The second is build and deploy. Every container image, every model artifact stored in your registry, every checkpoint file, every deployment manifest. The third is runtime. Every process actually serving inference, every endpoint responding to prompts, every embedded model on employee laptops or in edge deployments.
Reconciliation is the hard part. The code says the service uses model X. The container has model Y baked in. The runtime is serving model Z because someone hot-swapped it during an incident and never updated the manifest. All three are true simultaneously. Your AIBOM has to hold that contradiction and surface it, not paper over it.
Provenance has to go two levels deep, minimum. Not "Llama-3.1." Not even "Llama-3.1-70B-Instruct." You need the specific weights hash, the fine-tune lineage, the training dataset attestation if the upstream provided one, and a diff against the base model that tells you what actually changed. This is achievable. Hugging Face metadata plus weight fingerprinting plus behavioral probing gets you there for 90% of open-weight deployments. Closed models are harder but you at least record the API endpoint, model ID string, and version pin.
Prompts belong in the AIBOM. This is the part most people miss. A system prompt is a security-critical artifact. It carries data (customer info, internal terminology, business logic), it carries policy (what the model will and won't do), and it changes without code review at most companies. If your AIBOM doesn't inventory prompts, you don't have an AIBOM. You have a hardware manifest.
Tool permissions belong in the AIBOM. If an agent can call a Slack webhook, a database, a shell, or another agent, that's a supply chain edge. In our own MCP server we expose 10 tools, and I can tell you exactly which tools which agents in our system can call and under what conditions. That mapping is the AIBOM for agents. Nothing less counts.
A concrete example
Here's what generating a real AIBOM looks like on a repo. This is close to the workflow I run when I'm evaluating a company we might partner with.
# Scan code for model usage, inference client calls, MCP tool defs
cyscan scan ./repo --output aibom-code.json --rules ai-inventory
# Scan built artifacts for embedded model files and quantized weights
cyscan artifacts ./build/output --output aibom-build.json
# Probe running endpoints to identify actual served models
cyradar probe https://internal-inference.corp.example.com \
--runtime-detect --output aibom-runtime.json
# Reconcile the three views
cyscan reconcile aibom-code.json aibom-build.json aibom-runtime.json \
--output aibom-final.spdx.json --format spdx-3.0-ai
That last file is what should be sitting in your GRC system, not a curated registry. And it should regenerate on every merge, every deploy, every runtime configuration change. If your AIBOM is not continuous, it's a snapshot, and snapshots decay in days.
The regulatory beat, briefly
The EU AI Act's high-risk provisions are in force. NIST AI RMF 2.0 dropped last year. ISO 42001 is table stakes for any regulated buyer. All of them require some form of inventory. None of them are prescriptive about how you produce it, which is exactly the loophole vendors are exploiting.
If a regulator or a customer asks for your AIBOM and you hand them the output of a self-attestation form, you're technically compliant right up until an incident. Then the plaintiff's expert is going to ask how you knew the registry was accurate. And "the team maintained it" is not going to hold up when the discovery process finds 109 unregistered models sitting in your Kubernetes clusters.
I've said this in every board meeting I've done this year: the AIBOM is the SOC 2 of AI governance. It will start as a checkbox. It will become a differentiator. It will end as a lawsuit exhibit. Get ahead of the third phase now.
Why one platform, and specifically why observation over assertion
Here's the architectural argument. AIBOM generation touches code, build systems, container registries, running inference endpoints, prompt stores, agent configurations, and MCP servers. If you stitch that together from six vendors, the reconciliation problem becomes worse than the original inventory problem. You're now maintaining an inventory of your inventory tools.
The reason we built cyscan, cyradar, cyweb, and our MCP server on the same substrate is that reconciliation only works when the observers share a data model. cyscan sees code. cyradar sees runtime. cyweb, with its 22 fuzz categories and 95% template conversion rate against the community upstream, sees behavior. The MCP server with 10 tools exposes all of it to agents that can query, correlate, and act. A finding in code that matches a fingerprint at runtime that fails a behavioral probe is not three separate signals. It's one story about one artifact. Vendors selling AIBOM as a standalone dashboard cannot tell that story because they never see the code or the behavior. They see the registry someone told them about.
I'm not saying you have to buy from us. I am saying that if you're evaluating an AIBOM vendor, ask them to demonstrate reconciliation across code, artifacts, and runtime on a repo they've never seen. If they can't, or if they need six weeks of "integration," they're selling you a registry.
What's actually recomposing
Here's the pattern I keep seeing, and it's bigger than AIBOM specifically. The tools that mattered in 2020 were point solutions. SAST here, DAST there, SBOM over yonder, model registry off to the side, prompt management as a SaaS, agent governance as another SaaS. Each of them solved a slice. None of them talked to each other.
The AI-native security stack is recomposing all of that into a single continuous inventory-and-behavior graph. Code produces artifacts. Artifacts deploy to runtimes. Runtimes exhibit behaviors. Behaviors reveal composition. Composition feeds back into inventory. The loop closes.
An AIBOM is not a document you generate quarterly for auditors. It's the state of that loop at any given moment. Vendors who understand this are building platforms. Vendors who don't are building spreadsheets with APIs and calling them AIBOMs.
The companies that will do well in 2026 and 2027 are the ones that treat their AIBOM as production infrastructure. Same SLOs as their monitoring stack. Same on-call as their observability. Same seriousness as their SBOM pipeline, plus more, because the surface area is bigger and the artifacts change faster.
My friend at the fintech ended up scrapping the $180K registry and starting over. She's now generating her AIBOM continuously from code, artifacts, and runtime probes, and reconciling the three views into a single SPDX-AI document that regenerates on every deploy. Her current model count is 163. Not 147. The extra 16 showed up in the first week of continuous scanning. Some were legitimate deployments the team hadn't caught up on. Some were experiments left running from Q3. One was a fine-tune a departed contractor had spun up on a lingering GPU node. She would never have found it through a registry.
That's the difference between an AIBOM and an inventory ceremony.
If you're staring at your own AI governance program and wondering whether your registry is telling you the truth, run the experiment. Take one production service. Scan the repo with something that reads code, not model cards. Scan the runtime with something that fingerprints served models, not deployment manifests. Compare. If the numbers match, congratulations, your process is unusually mature. If they don't, the delta is your actual AIBOM.
You can do that comparison with cyscan (https://cybrium.ai/cyscan) and cyradar (https://cybrium.ai/cyradar) this week. If you want to talk through yours, find me at anand@cybrium.ai.
