A friend runs security at a mid-size fintech. Last month she got a Slack ping from her GRC lead: the EU AI Act auditor wanted a full inventory of AI systems in production, plus provenance for each model, plus a mapping to the risk tiers by Friday. She figured, fine, we have an SBOM pipeline, we have a model registry, we have vendor questionnaires. Two hours of work.
Nine days later she was still reconciling.
The model registry knew about the four models the data science team had shipped. It did not know about the Copilot-style assistant a product team had built by wiring their app to Claude through a wrapper library. It did not know about the two internal RAG systems that had swapped their embedding model in April without telling anyone. It did not know that the "AI-powered search" feature was actually a fine-tuned Llama variant a contractor had left running on a GPU box in a colo, or that the customer support tool their vendor had "upgraded" now shipped user tickets to a third-party inference API in Singapore.
The part that got me when she told the story: the auditor wasn't even being aggressive. He was asking the baseline questions. Model name. Model version. Training data provenance. Deployment location. Data flows in. Data flows out. Who owns it. What it can do. What it can't do. And she couldn't answer half of them without hunting through Jira, Terraform, vendor contracts, and two Notion pages that hadn't been updated since 2024.
That is the AIBOM problem in one story. It is not a compliance checkbox. It is the realization that your AI surface area has grown faster than your ability to enumerate it, and the tooling most vendors are selling you as an "AI Bill of Materials" is a repackaged SBOM with a model column.
The thesis
An AIBOM is not a document. It is a live, queryable graph of every model, every dataset, every inference endpoint, every prompt template, every agent, every tool a model can call, and every data flow between them — enriched with provenance, risk posture, and change history. If your AIBOM is a static JSON file generated at build time, you already lost. And if your vendor is telling you their AIBOM feature is "SPDX with model metadata," they are selling you a spreadsheet.
What an AIBOM actually needs to contain
Let me be specific, because the market is full of hand-waving. When I say AIBOM, I mean an inventory that answers these questions on demand, without a human going and looking:
The model layer is the obvious one. Base model, fine-tunes, LoRA adapters, quantization variant, license, source (HuggingFace repo, internal S3 bucket, vendor API). Everyone gets this part directionally right. Where they fail is versioning — most tools capture the model name and miss the fact that "gpt-4o" resolves to a different weight file every quarter, or that your local Llama-3.1-8B-Instruct got silently replaced with a Q4_K_M quantization when someone tried to fit it on a smaller GPU.
The data layer is where the sophisticated vendors start to sweat. Training data lineage. Fine-tuning corpus. RAG source documents. Vector index composition. Embedding model version. What PII sits in which index. Which customer's data is in which retrieval bucket. This is where regulators actually live. The EU AI Act's Article 10 is data governance. Colorado's AI act cares about training data. If your AIBOM can't tell you which datasets fed which model, you are writing a fantasy novel.
The runtime layer is the one every SBOM-style tool gets catastrophically wrong. Where is this model served? Ollama on a developer laptop? vLLM behind a load balancer? A managed API? What are the endpoints exposed? What auth is in front? Which agents can invoke which tools? What prompt templates are in production, and who changed them last? What guardrails are active, and are they actually running or bypassed by a flag someone set in staging six months ago?
The integration layer is what makes AI systems actually dangerous. Which apps call which models. What data crosses the boundary. Which MCP servers are exposed. Which tools an agent has permission to call. Whether the model can read from your production database or write to your ticketing system. This is the blast radius map, and it changes weekly.
The posture layer is the part I care most about, because it's the one that makes an AIBOM operational rather than archival. For every entry above, what is the current security posture? Has the model been scanned for prompt injection resilience? Are its endpoints exposed without auth? Are its dependencies vulnerable? Are its serving frameworks patched? When was the last time anyone actually tested it?
If your AIBOM is missing any of those five layers, it is not an AIBOM. It is a spreadsheet.
What most vendors get wrong
I've evaluated a dozen "AIBOM" products in the last eighteen months. Here are the failure modes, in the order they annoy me.
They treat models like packages. The SBOM lineage is strong for software supply chain because packages are relatively static. A model is not a package. It is a service. It has behavior. It has drift. A gpt-4o call today is not the same as a gpt-4o call in March. An SBOM-style manifest snapshot at build time captures none of this. You need continuous discovery, not a build-time artifact.
They ignore the local and self-hosted stuff. Every vendor's AIBOM demo starts with OpenAI and Anthropic keys because those are easy — you scrape the API bills. Try asking their tool about the Ollama instance a research engineer is running on a workstation, or the vLLM cluster your platform team stood up last week, or the LM Studio someone installed on a Mac Mini to demo a customer feature. The interesting attack surface lives in the self-hosted layer. That is why cyradar covers Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp — because "AI inventory" that skips your on-prem inference stack is a fiction.
They treat prompts as documentation. Prompts are code. Prompt templates in production are executable configuration that can be modified without a code review if you're not careful. An AIBOM that doesn't track prompt versions, prompt owners, and prompt changes over time is missing the most frequently-modified part of the whole system.
They don't connect to code. The AI in your company was written by humans in a repo. That repo has calls to openai.chat.completions, references to model names, embeddings clients, LangChain graphs, agent frameworks. If your AIBOM tool isn't scanning source code, it's guessing. This is why cyscan matters here — 1,815 rules across 75+ languages includes AI-specific patterns for detecting model invocations, prompt injection sinks, unsafe deserialization of model outputs, and hardcoded keys to inference providers. The AIBOM starts with the code. Anything else is downstream.
They confuse "governance" with "policy documents." I have seen AIBOM tools whose primary output is a PDF you send to auditors. This is the wrong artifact. The right artifact is a query interface. When a CVE drops for vLLM, I want to ask my AIBOM: which of my endpoints are running the affected version, which apps call those endpoints, and which of those apps handle regulated data? If the answer requires humans and hours, your AIBOM failed.
They stop at inventory. This is the biggest one. Every vendor sells you the list. Nobody tells you what's wrong. An inventory without a posture assessment is homework you assigned yourself. You need the AIBOM to tell you: this model endpoint has no auth, this RAG index contains PII, this agent has tool access to your CRM and was jailbroken in three of the last ten test runs, this dependency in your inference stack has a known RCE.
The architecture that actually works
Here's the model I've landed on after building this at Cybrium and watching customers deploy it. An AIBOM is a graph, not a document. The nodes are models, datasets, endpoints, apps, prompts, agents, tools, keys. The edges are data flows, invocations, ownership, dependencies. And the graph is populated by continuous scanners, not by humans filling in forms.
At the code layer, cyscan finds every place your codebase talks to a model. Every openai.ChatCompletion.create, every AutoModelForCausalLM.from_pretrained, every LangChain agent constructor, every MCP tool definition, every prompt template hardcoded in a Python file. That gives you the code-side map: which repos, which services, which model names, which providers.
At the runtime layer, cyradar sweeps your networks for exposed inference endpoints. It knows what an Ollama server looks like, what vLLM exposes, what a Triton inference server responds to. It finds the shadow AI — the workstation with a model server bound to 0.0.0.0, the forgotten dev environment still running last quarter's fine-tune. Combined with the code scan, you now have both sides: what your code says it talks to, and what is actually running on your network. The delta is where the interesting problems live.
At the application layer, cyweb probes the AI-facing web surfaces. 22 fuzz categories built for LLM-integrated apps: prompt injection, indirect injection through retrieved content, tool abuse, data exfiltration through function calls, jailbreaks. And 95% template conversion versus upstream community fuzz corpora means you're testing against the current state of the art, not last year's tricks.
At the integration layer, the MCP server (ten tools) lets your existing agents — your incident response bots, your GRC copilots, your engineering assistants — query the AIBOM in natural language. "Show me every production model that has been touched in the last thirty days." "Which of our RAG indexes contain data classified as customer confidential." "Which endpoints have no authentication." The AIBOM becomes something you talk to, not something you read.
The output is not a JSON file. It's a graph you can query, alert on, diff over time, and hand to an auditor as a live view. When a new CVE drops for a serving framework, you get a notification with the blast radius already computed. When a developer merges code that instantiates a new model, the AIBOM updates before the deploy hits production. When someone spins up a rogue Ollama instance, you see it within a scan cycle.
Why one platform for this specifically
I get the "best-of-breed" argument. I've made it myself for other categories. But an AIBOM is fundamentally an integration problem, and integrations between separate security tools are where inventories go to die.
If your code scanner is one vendor, your runtime discovery is another, your web app testing is a third, and your governance layer is a fourth, then your AIBOM is a Kafka topic and a lot of hope. Every seam is a place where a model gets lost. The vLLM instance shows up in the runtime tool but doesn't get correlated to the repo that deploys it. The prompt injection finding from the web scanner doesn't get attached to the model node in the governance graph. The CVE in the serving framework doesn't propagate to the apps that depend on it.
The reason we built cyscan, cyradar, cyweb, and the MCP layer as one platform is that they all write into the same graph. A model discovered by cyradar gets automatically linked to the repo that references it, discovered by cyscan. A prompt injection finding from cyweb gets attached to the specific endpoint that failed, which gets attached to the app that owns it, which gets attached to the team that ships it. The AIBOM emerges from the correlation, not from a nightly ETL job.
I'm not saying you have to buy it from us. I am saying that if you assemble your AIBOM from six vendors and a warehouse, you are building the exact system that let my friend spend nine days answering a Friday deadline.
The recomposition
The bigger shift underneath all this: the security stack that made sense in 2022 does not describe the 2026 attack surface. We spent a decade building tools to inventory servers, then containers, then serverless functions, then packages. Each generation was a recomposition, and each generation retired some of the previous vendors.
AI is the next recomposition, and it is faster and messier than the ones that came before. Models are not packages. Prompts are not config. Agents are not services. The taxonomy doesn't map cleanly, and vendors trying to force it into old shapes are producing tools that miss the surface area entirely.
The CISOs I see winning right now have accepted that AI inventory is its own discipline. They're not extending their SBOM tool. They're not adding a column to their CMDB. They're building — or buying — a system designed for the shape of AI, and treating the AIBOM as the foundation of every downstream governance, compliance, and incident response workflow.
My friend, by the way, got her answers to the auditor. She spent the following month rebuilding her inventory approach from the ground up. The static document she produced for the audit is already stale. The live system she's building won't be.
That is the choice in front of every security leader in 2026: build the artifact that satisfies this quarter's audit, or build the system that answers the next one before anyone asks.
If you're thinking through your AI inventory strategy — what belongs in it, how to keep it live, how to make it queryable by the humans and agents who need it — take a look at cyscan for the code-side discovery, cyradar for the runtime layer, and the MCP integration for making it all conversational. If you want to talk through yours, find me at anand@cybrium.ai.
Top comments (0)