Every CISO Needs an AIBOM in 2026 — Most Vendors Ship Theater

A friend of mine runs security at a mid-market fintech. Last month she got a 48-hour deadline from a European banking customer: produce a complete AI Bill of Materials for every model, dataset, and inference endpoint in the product, or lose the renewal. Standard enterprise ask in 2026. She said sure, we have one.

Then she opened it.

What she had was a spreadsheet her ML team maintained. Model names, a HuggingFace link, a rough description of training data, and a column called "owner" that was 40% stale. No hashes. No fine-tuning lineage. No record of which GPU host was serving which quantized variant. No mention of the three LoRA adapters her growth team had bolted onto the customer-support model six weeks earlier. No inference runtime versions. No prompt templates. No eval history. No embedding store contents.

She called me that night. "I thought we had an AIBOM. We have a vibes document."

She's not alone. I've looked at maybe thirty AIBOMs this year across customers and prospects, and I'd say two of them would survive a real incident. The rest are the AI equivalent of a 2015 SBOM — a list of top-level dependencies with none of the transitive, runtime, or provenance detail that actually matters when something goes wrong. We are repeating the SBOM mistake, at higher speed, with worse tooling, under tighter regulatory pressure.

Here's my thesis for the rest of this post: an AIBOM is not a document, it's a continuously-generated graph. If your vendor is selling you a PDF or a static JSON export, they are selling you compliance theater. The AIBOMs that matter in 2026 are the ones that can answer a question like "which of our production inference endpoints is currently running a model whose base weights were fine-tuned on a dataset that included PII from region X" in under a minute. Everything else is a filing cabinet.

What an AIBOM is actually for

Let me ground this. There are four moments where an AIBOM earns its keep, and if yours can't handle these four, it's not an AIBOM:

An incident. A novel jailbreak drops on a Tuesday. You need to know, right now, every endpoint running a model family that's susceptible, every tenant touching those endpoints, and every data path that feeds them. A spreadsheet cannot do this.

A regulator. The EU AI Act's high-risk provisions are live. Someone asks you to demonstrate the training data provenance of the model making a credit decision. "We think it's Llama-3-something" is not an answer.

A customer. Enterprise procurement wants model cards, data lineage, eval results, and a list of every third-party model you call during their request lifecycle. Including the embedding model. Including the reranker. Including the guard model.

A build. Your own engineers need to know which model version to pin, which adapter is approved for production, and whether the dependency they just imported pulls a model from a registry you don't control. If the AIBOM isn't in the CI pipeline, it's wrong by Friday.

Notice none of these are "generate a report for the board." The AIBOM is operational infrastructure, not a governance artifact. Governance is a side effect of having the data correctly in the first place.

The seven things most vendor AIBOMs leave out

I'm going to be specific here because I'm tired of PDFs. When I audit a vendor AIBOM, these are the gaps I find in rough order of frequency.

Runtime inventory, not just registry inventory. Most AIBOMs catalog what's in your model registry. That's maybe 30% of what's actually serving traffic. The rest is adapters loaded at runtime, quantized variants spun up on GPU hosts for cost reasons, shadow deployments, dev endpoints that leak into prod, and the Ollama container someone ran on a jumpbox for a demo and forgot. If your AIBOM doesn't scan running inference servers — vLLM, TGI, Ollama, LocalAI, Triton, llama.cpp, LM Studio — you're documenting intent, not reality. This is the gap we built cyradar to close.

Adapter and fine-tune lineage. A base model plus a LoRA is not the base model. It's a new artifact with new behavior, new risks, and new provenance obligations. Most AIBOMs list the base and ignore the adapters. That's where the actual customer data ends up fused into weights. If you can't answer "what training data went into this adapter and when," you have no AIBOM for the thing actually making decisions.

Prompt templates and system prompts. This one gets eye-rolls and I don't care. The system prompt is executable code. It changes model behavior as drastically as a weight update. It frequently contains sensitive business logic, data handling rules, and tool-use permissions. It needs to be versioned, hashed, and inventoried. Most AIBOMs don't mention prompts exist.

Embedding stores and retrieval sources. Your RAG pipeline is part of the model from a behavior perspective. The vector DB contents, the chunking strategy, the embedding model used, the reranker — all of these shape output. "We use Pinecone" is not an inventory. Which indices, with what contents, refreshed from which sources, with what access controls.

Inference-time tooling and MCP servers. If your model calls tools — which, in 2026, it does — those tools are part of the model's effective capability surface. The MCP servers it talks to, the function schemas, the tool-use policies, the auth model. We ship 10 tools through our own MCP server and I treat every one as part of the AIBOM for anything that calls them. Most vendors don't even have a column for this.

Eval and red-team history. An AIBOM without evidence of what you tested is a parts list without a QC log. For each model and major config change, you need the eval suite run, the red-team results, the known failure modes, and the mitigations applied. Not "we ran MMLU." The adversarial stuff. The jailbreak corpus you ran against it. The domain-specific harms you checked.

Dependency graph at the code level. Models don't float in space. They're wrapped in Python code that preprocesses inputs, postprocesses outputs, handles retries, and calls other services. That code has its own supply chain. If an AIBOM doesn't link to a traditional SBOM for the serving stack and to the SAST findings on the glue code, you've got an isolated artifact. This is why we run cyscan with 1,815 rules across 75+ languages against the inference-serving code and treat those findings as AIBOM entries. The model is only as safe as the Flask app in front of it.

If a vendor's AIBOM covers four of these seven, they're ahead of the pack. If they cover all seven and keep it live, they're doing the real work.

Why most vendors ship theater

I want to be fair here. The reason vendor AIBOMs are bad is not that vendors are lazy. It's that an honest AIBOM is architecturally hard, and most vendors picked an architecture that can't produce one.

If you're a pure cloud security posture tool, you can see what's in registries and what's deployed as a managed service. You cannot see what's loaded into a vLLM process on a self-hosted GPU host. You guess.

If you're a model governance platform, you can see what's registered through your approval workflow. You cannot see the Ollama install someone ran during an experiment that's now serving an internal tool. You pretend it doesn't exist.

If you're a code scanning tool, you can see dependencies declared in requirements.txt. You cannot see what model actually loaded at runtime after a dynamic HuggingFace Hub call. You document the intent, not the fact.

Each of these tools produces a partial AIBOM. Then the vendor markets it as the AIBOM. The CISO stitches four partial AIBOMs together with a spreadsheet and calls it governance. Eighteen months later a regulator asks a question that spans two of the four tools, and nobody can answer it because the identifiers don't line up and nothing was ever actually joined.

The architectural answer is that an AIBOM has to be assembled from runtime observation of inference servers, static analysis of the surrounding code, scanning of the registries and model stores, and a graph that joins all three with stable identifiers. One system, one graph, one query surface. Anything else is federation theater, which works until the first incident.

What a real AIBOM entry looks like

Let me get concrete. Here's roughly what a single entry should contain, in prose because the schema will change but the content won't:

For each model actually serving traffic, you need the base model identity with a cryptographic hash of the weights, every adapter applied with its own hash and training data manifest, the quantization and precision config, the serving runtime and its version, the host and its hardening posture, the endpoint URL and auth model, the system prompts and their hashes, the tool and MCP permissions, the embedding stores it reads from, the eval results from the most recent production push, the red-team findings outstanding and accepted, and the code SBOM for the serving stack. Plus owner, plus data classification, plus customer tenant exposure.

That's one entry. You probably have hundreds. If you're a company with any serious AI footprint, probably thousands when you count the shadow stuff. The spreadsheet era is over.

A quick example of what this looks like at the command line when you're actually operating one. Scanning a GPU host:

cyradar scan --host gpu-prod-07.internal \
  --runtimes vllm,ollama,tgi \
  --emit aibom --format cyclonedx-ai

Joining that to source analysis:

cyscan repo ./inference-gateway --emit sbom \
  --link-aibom aibom-gpu-prod-07.json

And then the thing that matters, which is querying across all of it:

cybrium query "endpoints serving models with adapter trained on dataset:customer-tickets-eu"

That last query is the test. If you can't run something like it against your inventory, you don't have an AIBOM, you have a filing cabinet.

The web and API attack surface nobody adds to the AIBOM

One more gap, because this one keeps biting people. Your AI endpoints are web endpoints. They have the same vulnerabilities every API has — authn flaws, authz flaws, injection, SSRF, rate limiting gone wrong — plus the AI-specific stuff. Most AIBOMs document the AI-specific stuff and ignore the API.

Then an attacker gets to the model not through a clever jailbreak but through a boring IDOR on the endpoint that fronts it. I've seen this happen three times this year. The AIBOM listed the model, the eval results, the system prompt. It did not list that the endpoint was reachable without auth from a public subnet.

This is why we run cyweb's 22 fuzz categories against AI endpoints as part of the AIBOM generation flow, and why we hit 95% template conversion versus the upstream community templates for web vuln testing. The AI endpoint is a web endpoint. Treat it like one. The AIBOM has to include the attack surface, not just the artifact.

Why one platform, specifically for this

I know the pitch is predictable, so let me make it narrow. I'm not arguing you need to buy everything from one vendor. I'm arguing an AIBOM, specifically, is a thing that cannot be federated across vendors without losing the properties that make it useful.

The reason is identifier joins. If your runtime scanner calls a model sha256:abc... and your governance platform calls it creditmodel-v3-prod and your code scanner calls it models/credit.py:load_credit_model, you have three inventories, not one. When the incident hits, you spend the first hour of the response figuring out which identifier means what. In the second hour you discover the identifiers don't actually line up because the governance platform was updated last week and the runtime scanner wasn't.

The CISOs winning at this picked a platform where the runtime observation, the code analysis, the web attack surface testing, and the registry inventory all emit into the same graph with the same identifiers. Then they bolt their governance workflow on top of that graph. The graph is the AIBOM. The PDF is a view.

That's the specific architectural choice I'd defend. One identifier space, many collectors, one query surface. Everything else can be federated.

The recomposition

Here's the pattern I keep seeing in 2026. The categories we built the security market around — AppSec, CSPM, model governance, data governance, API security — were drawn when AI was a research project. They were drawn around tools, not around the thing being protected.

Now the thing being protected is a composite. A production AI feature is code plus a model plus adapters plus prompts plus retrieval plus tools plus a web endpoint plus a GPU host. Protecting it means seeing all of those at once, in the same graph, with the same identifiers. The categories don't matter. The composite does.

The AIBOM is the forcing function for this recomposition. Once you accept that the AIBOM has to be live, has to be complete, and has to be queryable, you've accepted that the old category boundaries don't work. You can't buy an AIBOM from the AppSec vendor plus one from the model governance vendor and staple them. The whole point is the join.

The vendors who figured this out early rebuilt around the composite. The ones who didn't are going to spend 2027 explaining why their AIBOM doesn't include adapters, or doesn't include prompts, or doesn't include the GPU host, or doesn't include the API. By then their customers will have moved.

My friend at the fintech, by the way, hit her deadline. Not with the spreadsheet. She ran a runtime scan across her GPU fleet, pulled her code SBOM, joined them, and shipped a real AIBOM with 340 entries — about 230 more than her spreadsheet claimed existed. The customer accepted it. The renewal closed. The scary part, as always, is that for the two weeks before that call, she thought she had this covered.

If you're building your AIBOM program now, start with runtime. The models actually serving traffic are the ones that will burn you. Then join to code, then join to web attack surface, then layer governance on top. In that order. Don't start with the spreadsheet. The spreadsheet is where AIBOMs go to die.

If you want to see what a live AIBOM looks like against your own environment, cyradar covers the self-hosted inference runtimes (cybrium.ai/cyradar), cyscan handles the code side (cybrium.ai/cyscan), and cyweb covers the endpoint attack surface (cybrium.ai/cyweb). The MCP server stitches them for your own agents.

If you want to talk through yours, find me at [email protected].