Two months ago I sat in a conference room in Palo Alto with the CISO of a mid-size fintech — 800 engineers, Series D, publicly considering an IPO in 2027. Their board had just asked, in writing, for an "AI Bill of Materials." The GC had heard the term on a podcast. The audit committee wanted it before Q4.
She had a PDF from her MLOps vendor. It was 34 pages. It listed the foundation models the company had "approved" — GPT-4o, Claude Sonnet, an internal Llama fine-tune — with tidy little cards showing training data provenance, license type, and a green checkmark next to "safety evaluated."
Then I asked her one question: how many models are actually running in production right now?
She didn't know. Neither did the vendor's PDF.
We spent the next forty minutes doing a live discovery pass. Her platform team had spun up two vLLM instances for an internal copilot. A data science group had a Triton server serving three embedding models nobody had documented. Someone in growth had wired an Ollama sidecar into a Shopify workflow. And the "approved Llama fine-tune" on the PDF? It was version 3. Production was running version 7, which had been re-trained on customer support transcripts that included PII.
The PDF wasn't wrong exactly. It was fiction. A snapshot of what someone had told a compliance team eleven months ago, hardened into a document that looked like an inventory but functioned like a wish.
That's the AIBOM problem in 2026. Everyone has a document. Almost nobody has an inventory.
The thesis
An AIBOM is not a compliance artifact. It's an operational system. If it isn't continuously discovered, continuously verified, and queryable at incident-response speed, it's worse than nothing — because it gives your board and your regulators a false sense of coverage while your actual risk surface drifts underneath. The vendors selling static AIBOMs are selling the 2013 version of SBOMs, and we already know how that story ended.
What an AIBOM actually is (and what most vendors ship instead)
An SBOM answers a specific question: if a CVE drops tomorrow, which of my applications ship the vulnerable library, and where are they deployed? It's useful precisely because it's mechanical. You generate it from build systems, you diff it across releases, you query it under fire.
An AIBOM has to answer a bigger, messier question: if a model, a dataset, a serving framework, or a fine-tune becomes untrustworthy tomorrow, what in my organization depends on it, and how do I contain the blast radius?
That "untrustworthy" clause is doing a lot of work. It might mean:
- A foundation model provider gets breached and their weights leak
- A training dataset turns out to have been scraped from copyrighted material
- A serving framework — vLLM, Triton, LocalAI, TGI — ships a CVE that allows RCE
- A fine-tune drifts because someone re-trained it on production data without approval
- A prompt injection technique lands in a public repo that defeats your guardrails
Any one of those requires you to know, in minutes, which surfaces are exposed. Not which surfaces you approved — which surfaces are live.
Most vendor AIBOMs I've reviewed in the last year answer none of these questions. They're export artifacts from model registries. They document what data scientists checked in. They do not know what's running. They do not know what's exposed to the internet. They do not know which serving stack version is in production, and they cannot tell you whether that serving stack has a known CVE this morning.
What the seven layers of a real AIBOM look like
Every useful AIBOM I've built or advised on contains seven distinct layers. Skip any of them and you have a document, not an inventory.
Layer one: model artifacts. The obvious one. Foundation model, version, license, provenance, quantization, fine-tune lineage. Most vendors get 60% of this right and stop.
Layer two: serving infrastructure. This is where vendors fall off a cliff. Which inference engine? Which version? Ollama 0.3.14 or 0.4.2? vLLM with which CUDA driver? Is the Triton server exposed on the internal network or has someone accidentally bound it to 0.0.0.0? An AIBOM without serving-layer inventory is like an SBOM that lists dependencies but not the servers running them.
Layer three: data lineage. Not just training data. Fine-tuning data, RAG corpora, embedding stores, and — critically — production feedback loops. If you're logging conversations and periodically re-training, your training data changes weekly, and your AIBOM needs to know.
Layer four: prompt and agent scaffolding. Every system prompt is a security control. Every tool definition in an agent is an attack surface. If your AIBOM doesn't inventory the prompts and MCP tools your agents can invoke, you don't know what your agents can do.
Layer five: guardrails and evaluation state. Which guardrails are deployed against which models? When were they last evaluated? Against which adversarial dataset? Static "we use Llama Guard" is not an answer.
Layer six: dependencies. The Python packages, the CUDA versions, the tokenizer libraries, the model-loading code. This is where a normal SBOM meets the AIBOM. Ninety percent of the AI supply chain vulnerabilities in the last eighteen months have been in this layer, not in the models themselves.
Layer seven: access and identity. Which service accounts can invoke which model endpoints? Which employees have keys to which providers? When someone leaves, whose OpenAI API key still works?
If your current AIBOM covers layers one and three and stops there, you have a model registry, not an AIBOM. Most vendors are selling model registries with new marketing.
The discovery problem
Here's the part vendors don't want to talk about. You cannot build an AIBOM by asking developers to fill out a form. You've tried this with SBOMs. It didn't work then either.
Real AI inventory has to be discovered the same way we discover cloud assets: from the outside in and from the inside out, continuously. The inside-out pass looks at your code — every repository, every deployment manifest, every Terraform file — and finds the AI. This is the layer where cyscan runs. Its 1,815 rules across 75+ languages catch model-loading patterns, embedded API keys, hardcoded prompts, LangChain scaffolds, agent tool registrations, and about forty other AI-native code signatures. It builds the inventory from what your engineers have actually shipped, not what they've documented.
The outside-in pass is where cyradar lives. It hits your network — internal and edge — and probes for exposed inference endpoints. Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp. Every one of those has a signature. Every one of those, at some point in 2025, ended up unintentionally exposed at some Fortune 500 I know about. If your AIBOM doesn't include the results of an active network scan for these frameworks, you are documenting a fantasy.
Both passes have to run continuously. Not quarterly. Not before audits. Continuously — because the half-life of an AI system in 2026 is measured in weeks, and by the time your quarterly review lands, three of your teams have shipped agents you've never heard of.
The query problem
Once you have discovery working, you have a second problem: the AIBOM has to be queryable by humans in a hurry.
I've watched incident response teams try to answer "which of our services depend on this specific model?" using a JSON export. It's brutal. By the time they've grepped through the artifact, containment is thirty minutes late.
A real AIBOM is a graph. Models connect to serving infrastructure connect to services connect to data connect to identities. When something turns untrustworthy, the question is always the same: what depends on this, transitively? You should be able to ask that question in plain English, get an answer in seconds, and pivot into containment.
This is why we exposed the platform through an MCP server with ten tools. Your incident commander shouldn't have to remember our query DSL at 2 a.m. She should be able to ask Claude or ChatGPT, connected to your AIBOM, "which production services use this model, which of them are internet-facing, and which of them have the vulnerable vLLM version installed?" and get a real answer, cited to real data. That is what "AI-native security tooling" actually means. Not chatbots that make dashboards. Data structures that LLMs can reason over.
What the compliance frameworks actually require in 2026
The regulatory environment moved faster than most CISOs I talk to realize. The EU AI Act's high-risk system obligations became binding in August. NIST's AI RMF profile for generative systems now has audit criteria. ISO 42001 certification is being asked for in vendor questionnaires. The SEC has settled two disclosure cases involving undisclosed AI dependencies.
None of these frameworks require a static PDF. Every one of them requires demonstrable, current inventory. The auditors I've been in rooms with this year ask three questions:
Show me what's running in production right now. Show me how you found it. Show me what changed since last quarter.
If your AIBOM cannot answer question two — how did you find it — you are on the wrong side of the "reasonable measures" clause in three separate regulations. "The vendor sent us a spreadsheet" is not going to hold up.
The web-app AI attack surface nobody's inventorying
Here's one I don't hear enough CISOs talking about. Your AI systems aren't just the models. They're the web endpoints in front of them. The chat UI. The API gateway. The RAG-augmented search. The support ticket auto-responder.
Every one of those is a web application, and every one of them has an AI-specific attack surface — prompt injection, context leakage, indirect injection via user-uploaded documents, tool-invocation abuse. Traditional DAST does not test for these. WAFs do not catch them.
This is why cyweb ships 22 fuzz categories specifically for AI-fronting web applications, and why we invested in a 95% template conversion pipeline against the upstream community rulesets — so that when a new injection technique lands in a public template on Tuesday, your scans are catching it by Wednesday. An AIBOM that inventories your models but doesn't inventory the web surfaces exposing those models is auditing the vault while ignoring the doors.
Why this has to be one platform
I get pushback on this. There are good specialist tools for model registries. Good specialist tools for network scanning. Good specialist tools for code analysis. Why one platform?
Because the AIBOM only works if the graph is connected. If your code scanner knows about a vllm.LLM(model="mistral-7b") in a repo, and your network scanner separately finds a vLLM instance on 10.20.4.17, and your model registry separately has a mistral-7b entry — those three facts are useless as three facts. They're only useful when they resolve to a single node in a graph, with a single confidence score, exposed to a single query.
Multi-vendor AIBOMs fail at the join. I've watched teams try to reconcile three vendor exports in a Snowflake warehouse. They gave up in six weeks. The identifiers don't match. The versioning schemes don't align. The refresh cadences drift. You end up with a compliance artifact that's stale from three different directions.
One platform, one graph, one query surface. Or a PDF.
The recomposition happening now
Something bigger is going on underneath the AIBOM conversation. The last decade of security tooling was built around the assumption that software was written by humans, deployed on infrastructure you provisioned, and executed on hardware you'd audited. AI breaks all three assumptions simultaneously. Software is written by models. Infrastructure is provisioned by agents. Hardware — specifically GPU inference — sits in configurations that were experimental three years ago and are now customer-facing.
The security stack is being recomposed. SAST becomes AI-aware code analysis. DAST becomes prompt-injection fuzzing. asset inventory becomes AIBOM. Threat detection becomes model-behavior monitoring. Access control becomes agent-tool authorization. IR becomes model-containment.
The vendors who understand this are rebuilding from the primitive up. The vendors who don't are rebranding old products with "AI" in the name and shipping PDFs.
The CISO in Palo Alto asked me at the end of our meeting what to do next. I told her the same thing I'll tell you: stop treating the AIBOM as a document your GC needs. Treat it as the underlying data structure that everything else in your AI security program depends on. If you get the inventory right, guardrails, IR, compliance, and vendor management all become tractable. If you get it wrong, everything downstream is theater.
Start with discovery. Run cyscan across your code and cyradar across your network. Look at what comes back. It will be more than you expected. It always is. Then decide what belongs there, what doesn't, and what needs to be governed. That's an AIBOM. Everything else is a PDF.
If you want to see what your real inventory looks like — not what your vendor's spreadsheet says — start with cyscan and cyradar, and if you want to talk through what your first honest AIBOM should contain, find me at anand@cybrium.ai.
Top comments (0)