DEV Community: Grumpy Sage

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

Grumpy Sage — Thu, 15 Oct 2026 17:39:12 +0000

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 anand@cybrium.ai.

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

Grumpy Sage — Thu, 08 Oct 2026 19:11:11 +0000

A friend of mine runs security at a mid-market fintech. About 900 engineers, Series D, the kind of place where the AI budget tripled in eighteen months and nobody can quite explain where it all went. She called me in August because her board had asked a question she couldn't answer: What AI are we actually running?

Not "what did we buy." What are we running. In production. Right now.

She pulled her procurement list. Fourteen vendors. Then she pulled her cloud bills and found another six AI services nobody had logged. Then her platform team mentioned the three internal Llama fine-tunes they'd deployed on an EKS cluster for the fraud team. Then someone remembered the LangChain app the growth team shipped, which calls OpenAI, Anthropic, and a Cohere reranker depending on the query. Then the data science org admitted to a vLLM instance running a quantized Mistral variant that had been up for seven months, serving an internal tool nobody had security-reviewed.

By the end of the week her "AI inventory" was a 73-row spreadsheet, and she still didn't trust it. The part that bothered her most wasn't the sprawl. It was that two of those models had been downloaded directly from Hugging Face by a staff engineer who had since left the company. Nobody knew what training data they'd been exposed to. Nobody knew if they'd been tampered with. They were just... running. Taking customer input. Returning answers.

She asked me what I'd do. I told her: you need an AIBOM. A real one. And no, your GRC vendor's new "AI Governance Module" isn't it.

The thesis

An AI Bill of Materials is the single most undervalued security artifact of 2026, and ninety percent of what gets sold under that name is theater — a spreadsheet of vendor names dressed up as governance. A functional AIBOM has to answer four questions continuously, not quarterly: what models are running, where did they come from, what can they reach, and who is allowed to change them. If your AIBOM can't answer those four at any moment, you don't have an AIBOM. You have a compliance screenshot.

What an AIBOM actually is

The SBOM analogy is useful but it undersells the problem. An SBOM tracks dependencies that are deterministic — version 2.14.3 of a library behaves the same way across your fleet. A model doesn't. A model has weights, a tokenizer, a config, a prompt scaffold, a serving runtime, system prompts, retrieval sources, tool definitions, and in most production stacks, a half-dozen downstream integrations that materially change its behavior. Two deployments of the "same" Llama-3-70B can behave like different systems because one has a RAG pipeline hitting your CRM and the other doesn't.

So an AIBOM isn't a list. It's a graph. Here's what has to be in it, at minimum:

The model artifact itself: name, version, weights hash, source, license, quantization
The serving runtime: Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp, or a hosted API endpoint
The deployment surface: which cluster, which namespace, which network segment, which ingress
The data plane: what the model can read (RAG indexes, tools, databases) and what it can write
The identity plane: which service accounts can call it, who can update the weights, who can change the system prompt
The provenance chain: where did the weights come from, what signed them, what's the chain of custody from Hugging Face or an internal training job to the running pod

If your AIBOM stops at bullet one and two, which is where most vendor products stop, you've described the engine. You haven't described the car, the driver, or the road.

Where most vendors get it wrong

I've evaluated eleven products that pitch themselves as "AI inventory" or "AI governance" platforms this year. I'll spare the names. Here's what they consistently get wrong.

They inventory procurement, not runtime. The majority of these tools integrate with your SSO logs, your CASB, and your contract management system. They produce a list of AI vendors you've paid. That is useful for finance. It is nearly useless for security. The Llama fine-tune running on an unmonitored EKS node doesn't show up in your SSO logs. The quantized GGUF model someone loaded into LM Studio on a developer laptop doesn't show up in your CASB. The models that scare me most are precisely the ones that generate no procurement paper trail.

They treat the model as a black box. A real AIBOM has to inspect the model artifact. What's the hash? Does it match a known provenance? Has anyone fine-tuned it, and on what? Is the tokenizer the one that shipped with the base model or has it been swapped? Most governance tools can't answer any of this because they never touch the artifact. They just ingest the name.

They ignore the application layer. The riskiest thing in your stack is not the model. It's the code around the model — the LangChain glue, the custom retrievers, the tool definitions, the prompt templates with injected user data, the Flask endpoint that passes a raw user string to a function-calling API with access to your production database. An AIBOM that lists "GPT-4" but doesn't catalog the fifty lines of Python that wrap it is lying to you about your attack surface.

They refresh on a cadence. Weekly. Daily if you're lucky. In an environment where a developer can deploy a new model in forty minutes, cadence is the wrong primitive. Your AIBOM has to be event-driven. New container with a model weight in it? AIBOM entry. New Ollama endpoint reachable on an internal subnet? AIBOM entry. New Hugging Face download in a build pipeline? AIBOM entry, with the hash, right now, not at the next sync.

They don't correlate findings. This one bothers me the most. An AIBOM that's just an inventory is table stakes. An AIBOM that cross-references each entry against known model vulnerabilities, insecure runtime configurations, exposed inference endpoints, and application-layer flaws in the surrounding code — that's security. The inventory is the beginning of the conversation, not the end.

What a functional AIBOM pipeline looks like

Let me describe how I'd build this, because I think concretely about it and I've watched too many teams get stuck in slide-deck purgatory.

Start at the artifact layer. Every build pipeline that produces a container, lambda, or image gets scanned for model weights, tokenizer files, and the obvious AI framework imports. You're looking for .gguf, .safetensors, .bin, .onnx, pytorch_model.*, and the Python signatures of transformers, llama-cpp, vllm, langchain, llamaindex, haystack, and the long tail. This is a code-scanning problem. On Cybrium we handle it with cyscan, which runs 1,815 rules across 75+ languages and specifically covers the AI-adjacent code patterns most SAST tools miss. The output is: for every repo and every build, what AI code and what AI artifacts are present.

Move to the runtime layer. You need an active scanner that walks your internal network — your VPCs, your Kubernetes clusters, your developer VLANs — and identifies inference endpoints. Ollama has a signature. vLLM has one. TGI, LocalAI, Triton, LM Studio, llama.cpp — all identifiable. Cybrium's cyradar does this specifically for AI inference surfaces, and the finding we see most often is an Ollama instance bound to 0.0.0.0 on a developer's EC2 that's reachable from a peered VPC. Nobody put that in the procurement spreadsheet.

Move to the application layer. Every web endpoint, every API, every Lambda function that mediates between a user and a model gets fuzzed. Prompt injection, system prompt leakage, tool abuse, output handling flaws, SSRF through retrieval, the full taxonomy. cyweb runs 22 fuzz categories across these, and the finding rate on production LLM apps is substantially higher than most CISOs expect. The AIBOM has to carry those findings as attributes of the component, not as separate tickets.

Correlate. Every artifact gets a stable ID. Every runtime endpoint gets linked to the artifact it serves. Every application gets linked to the runtime it calls. Every finding gets attached to the right node in the graph. Now when the board asks "what AI are we running," you have an answer. When your IR team asks "if this CVE drops tomorrow for vLLM, what's exposed," you have an answer. When legal asks "which of our customer data flows touch a model trained on scraped web data," you have an answer.

That graph, continuously updated, event-driven, correlated with findings — that's an AIBOM.

The provenance problem

I want to spend a minute on provenance because it's the hardest part and the part vendors handwave hardest.

If an engineer runs:

ollama pull llama3:70b-instruct-q4_K_M

What did they just download? They downloaded a quantized GGUF file from Ollama's model library, which was packaged from Meta's release, which was trained on a dataset Meta hasn't fully disclosed. The chain of custody has at least three hops, and at every hop the artifact could have been swapped. Hugging Face has had typosquatted model names. Compromised accounts have pushed malicious weights. Pickle deserialization in older model formats has been a reliable RCE primitive for years.

A real AIBOM pins the hash. Not the name, not the version tag — the hash of the actual bytes on disk. And it tracks that hash against a known-good reference. If the hash doesn't match what Meta published, that's a finding. If the hash matches but the tokenizer has been swapped, that's a finding. If the model was downloaded from a mirror you don't trust, that's a finding.

Most governance tools do none of this. They record "llama3-70b" as a string and move on. That string tells you nothing about what's actually running in your cluster.

Why one platform instead of five

The reflex at a mature security org is to buy best-of-breed and glue it together. SBOM tool here, model scanner there, DAST for the LLM apps, posture management for the inference endpoints, a GRC overlay to roll it up. I've watched a lot of teams try this and it collapses for one reason: the correlation layer is the hardest part, and nobody owns it when it lives between five vendors.

The AIBOM only works as an AIBOM when the code findings, the artifact provenance, the runtime discovery, and the application-layer vulnerabilities land in the same graph. If they land in five different consoles with five different IDs for the same model, you don't have an AIBOM. You have five dashboards and a Jira project to reconcile them.

This is why Cybrium builds all four layers under one roof and exposes them through a single MCP server with 10 tools, so your AI agents and your SOC can query the same graph. I'm not neutral on this. I built it this way because I spent years watching customers try the five-vendor approach and I never once saw it produce a trustworthy inventory.

The recomposition happening right now

Here's what I think is actually going on in the market, and why I'm writing this now.

For the last two years, "AI security" has been a category defined by whoever showed up first with a slide. Red-teaming startups, prompt-injection scanners, data-leakage classifiers, model firewalls, governance overlays. Each one is a feature. None of them is a program.

In 2026 the center of gravity is shifting toward the AIBOM because every other control depends on it. You can't red-team a model you don't know exists. You can't apply a policy to an endpoint you haven't discovered. You can't do incident response on a system whose provenance you can't reconstruct. The inventory is the substrate. Everything else is a function that takes the inventory as input.

The CISOs I talk to who are ahead of this are already treating their AIBOM as the primary artifact and everything else — the red-teaming, the policies, the runtime guards — as consumers of that artifact. The CISOs who are behind are still buying point tools and trying to produce a spreadsheet for the board every quarter. The gap between those two postures is going to be the thing regulators, insurers, and acquirers notice next year. I'm already seeing it in diligence questionnaires.

If your board hasn't asked yet, they will. And "we have a spreadsheet" is not going to survive the follow-up question.

What to do this quarter

If I were sitting in my friend's chair at that fintech, this is the sequence I'd run.

Week one, inventory the artifact layer. Scan every repo and build pipeline for model files and AI framework imports. You'll find more than you expect. On Cybrium that's a cyscan deployment and about two days of triage.

Week two, discover the runtime. Point a scanner at every internal subnet and surface every inference endpoint, hosted or self-hosted. Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp — all of them. That's cyradar, and the finding rate is uncomfortable. Good. That's the point.

Week three, test the application layer. Every LLM-fronted endpoint gets fuzzed across the 22 categories cyweb covers — prompt injection, tool abuse, output handling, retrieval SSRF, the rest. The findings here are the ones most likely to produce an actual incident.

Week four, correlate. Build the graph. Link artifacts to runtimes to applications to findings. Give every node a stable ID. Make it queryable by your SOC and by your AI agents through the MCP interface.

Then operate it continuously. Not quarterly. Not weekly. Event-driven, every build, every deploy, every new endpoint. That's the bar for 2026.

The AIBOM is not a document. It's a system. If you treat it like a document you'll keep producing screenshots for the board and discovering surprises at 2 a.m. If you treat it like a system you'll know what you're running, where it came from, what it can reach, and who can change it — at any moment, for any model, in any environment.

That's the baseline now. Not aspiration. Baseline.

If you're building this out and want to compare notes on what's working and what isn't, or if you want to see how we assemble the four layers into a single graph on Cybrium — cyscan for the code, cyradar for the runtime, cyweb for the apps, and the MCP server for querying it all — find me at anand@cybrium.ai.

Every CISO Needs an AIBOM in 2026 — And Most Vendors Ship a Fiction

Grumpy Sage — Mon, 31 Aug 2026 19:25:17 +0000

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.

Every CISO Needs an AIBOM in 2026 and Most Vendors Are Faking It

Grumpy Sage — Thu, 13 Aug 2026 14:23:53 +0000

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.

Why Every CISO Needs an AIBOM in 2026 — And What Most Vendors Miss

Grumpy Sage — Mon, 06 Jul 2026 16:21:54 +0000

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.

Why Every CISO Needs an AIBOM in 2026 — And What Vendors Get Wrong

Grumpy Sage — Mon, 29 Jun 2026 16:39:58 +0000

A friend who runs security at a mid-sized fintech called me three weeks ago. Her board had asked a question her team couldn't answer in under a week: "How many models are running in production, and which ones touch customer PII?"

She sent me her first draft of the answer. It was a spreadsheet. Forty-seven rows. The columns were Model Name, Owner, Risk Tier, Data Classification. Most of the cells said "TBD" or "see Notion." Two rows were duplicates of the same model deployed in different namespaces. One row was a model that had been deprecated six months earlier but was still receiving traffic because a forgotten Lambda kept calling its endpoint. Another row didn't exist on the spreadsheet at all — it was a fine-tuned Llama variant running inside a vendor's SaaS that her data science team had embedded via SDK. Nobody had told security.

The part that bothered her wasn't the spreadsheet. It was what the spreadsheet implied. Her org had stood up an AI governance committee, hired a head of responsible AI, and bought a "model risk management" platform from a name-brand vendor. And she still couldn't answer the board's question without two weeks of Slack archaeology. The vendor's tool had a beautiful dashboard. It just didn't know about half the models, none of the agents, zero of the MCP tools, and obviously nothing about the prompts and retrieval indexes hanging off them.

She asked me a simple question: "What does a real AIBOM look like in 2026?"

This is my answer.

The thesis

An AIBOM — AI Bill of Materials — is not a spreadsheet of models, and it's not an SBOM with three extra columns. It's a living graph of every artifact that participates in an AI decision: weights, base models, training and fine-tuning datasets, prompts, system instructions, retrieval indexes, agents, tools, MCP servers, evaluation suites, and the humans accountable for each. Most vendors are selling you the 2023 version of this — a static registry. In 2026, that's worse than useless, because it gives the board false confidence while the actual attack surface lives in the gaps.

What an AIBOM has to cover that vendors keep missing

Let me be specific about where the 2023-era tooling falls apart.

Self-hosted inference. When OpenAI was the only game in town, an AIBOM was easy: list your API keys, log your prompts, done. In 2026, every serious enterprise I talk to has at least three self-hosted inference stacks running concurrently. Ollama for the experimentation team. vLLM for the production serving. Maybe TGI or LocalAI for a regulated workload that has to stay in a specific VPC. Maybe Triton for the computer vision pipeline that predates the LLM craze. Maybe llama.cpp on an edge device. Maybe LM Studio on a developer's laptop that somehow ended up serving an internal Slack bot.

A real AIBOM has to discover and fingerprint each of these runtimes, identify which models they're serving, and continuously monitor them for drift. Most vendor tools assume "the model" is a SaaS endpoint. That assumption is now wrong more often than it's right.

Agents and tools, not just models. A model is a function. An agent is a process. When your customer success team builds a workflow where a model calls a tool that calls another model that writes to your CRM, the security-relevant unit isn't the model — it's the agent-tool graph. An AIBOM that lists "GPT-5-turbo" and stops there is hiding the actual blast radius. The blast radius is the tools the agent can invoke, the data those tools can touch, and the authority gradient between them.

Prompts as code. Every system prompt in production is a security control. Every system prompt in production is also unversioned, untested, and edited by whoever has access to the LangChain repo. The 2023 AIBOM treated prompts as ephemera. The 2026 AIBOM treats them as first-class artifacts with their own signing, their own change log, and their own evaluation history. If a prompt changed yesterday and an incident happened today, you need to be able to draw that line in seconds.

Training and fine-tuning provenance. Did your fine-tuned support model train on customer conversations? Which ones? Were the opt-outs honored? Was any of it scraped from a forum that has since issued a takedown? When the regulator asks — and in the EU they're now asking — "spreadsheet" is not an answer.

The vendor SaaS that embeds models you didn't approve. This one is brutal. Your CRM vendor added an AI assistant. Your dev tool vendor shipped Copilot-for-our-thing. Your HR platform now does "smart" summarization. Each of those is a model in your decision path that no internal procurement process saw. A real AIBOM has to ingest vendor disclosures and treat third-party AI as part of your surface area, not someone else's problem.

Why static registries are worse than no registry

I'm going to make an unpopular claim: a stale AIBOM is more dangerous than no AIBOM.

When you have nothing, your incident responders know they have nothing. They go look. They grep. They ask questions. They find things.

When you have a registry that says "we have 47 models," your responders trust the 47. They don't grep. They don't ask. And the 48th model — the one your data science intern stood up in a forgotten GCP project to test something on a Friday — is exactly where the breach lives.

This is the same dynamic that played out with CMDBs in the 2010s. Every enterprise had one. None of them were right. The ones that mattered were the ones generated continuously from observed reality, not declared by humans on a wiki. AIBOMs are CMDBs for AI, and we're going to repeat every mistake unless we start from "discover, don't declare."

Discovery means scanning the code that defines models and prompts. It means watching the network for inference traffic. It means probing inference endpoints to identify what they actually serve. It means parsing CI/CD pipelines for training jobs. It means reading IaC to find GPU instances. And it means doing all of that on a cadence measured in hours, not quarters.

What we built, and why we built it this way

I'll be direct: this is the problem Cybrium is built around, and our architecture reflects a strong opinion about how to solve it.

cyscan is our static analysis engine. It runs against your repos and finds the AI artifacts the way a SAST tool finds SQL injection — by understanding code, not by waiting for someone to fill out a form. 1,815 rules across 75+ languages, looking for model loads, prompt definitions, agent constructions, tool registrations, MCP client wiring, and the patterns that indicate AI is happening even when nobody labeled it. If your repo has from transformers import or a LangChain agent or a raw HTTP call to an Ollama port, cyscan finds it and tags it.

cyradar is the runtime side. It fingerprints self-hosted inference: Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp. The point isn't to brag about coverage. The point is that these are the runtimes actually deployed in 2026, and a tool that only knows about OpenAI endpoints is solving a 2023 problem. cyradar tells you what's running, what model it's serving, what version, what configuration, and whether it's exposed in ways it shouldn't be.

cyweb handles the offensive validation. 22 fuzz categories, 95% template conversion from the upstream community templates, plus our own. Because an inventory entry that says "this model is deployed" is half the story. The other half is "and here's what an attacker can do to it right now."

The MCP server exposes 10 tools that let an agent — yours or ours — query this graph the way you'd query a database. "What models touch PII?" becomes a tool call, not a two-week investigation.

The reason these are one platform rather than four products is the graph. A model finding from cyscan and a runtime fingerprint from cyradar and a fuzz result from cyweb are not three reports. They're three edges on the same node. The value isn't the scan results. The value is being able to ask, in one query, "show me every model that (a) touches PII according to cyscan, (b) is exposed on a runtime cyradar can reach from the internet, and (c) failed a cyweb prompt injection probe in the last 24 hours." That query is the AIBOM doing its job. You can't run that query across four siloed vendors. I've tried. I gave up.

The five questions your AIBOM has to answer in under a minute

I tell every CISO who asks me about AIBOM to forget the vendor pitches and write down the questions their board, their regulator, and their incident responders will actually ask. If your AIBOM can't answer these in under a minute, it's not an AIBOM. It's a spreadsheet.

Which models, in which environments, touch which data classifications, owned by whom?
For any given model, what's the full dependency chain — base model, fine-tuning data, prompts, retrieval indexes, tools, agents?
What changed in the last 24 hours, 7 days, 30 days, across any of the above?
Which of our deployed AI components currently have a known vulnerability or exploitable misconfiguration?
If we deprecate model X tomorrow, what breaks?

That last one is the one most teams underestimate. The deprecation question is where you discover the Lambda nobody remembered, the vendor SDK that embeds a forgotten endpoint, the eval suite that's secretly running in production traffic. If you can answer the deprecation question, you have a real AIBOM. If you can't, you have decoration.

What 2026 regulators are actually asking for

I sit on a couple of advisory boards where regulators show up. Let me tell you what they're asking, because it's not what the marketing decks say.

They're not asking for a list of models. They're asking for provenance and reproducibility. Given an output that affected a customer, can you reconstruct the chain that produced it — which model, which version, which prompt, which retrieval, which inputs — and would the same chain produce the same output today? If yes, you have governance. If no, you have a press release waiting to happen.

They're asking for human accountability per artifact. Not "the AI team owns AI." Which specific person is accountable for this prompt? For this fine-tuned model? For this agent's tool permissions? An AIBOM that doesn't carry accountability at the artifact level is a compliance theater prop.

They're asking for change velocity with safety. They've stopped pretending change freezes are realistic. What they want is evidence that every change to an AI artifact passed through evaluation, that the evaluation suite is itself versioned, and that production deployment is gated on those evals. The AIBOM is the evidence layer for that.

If your vendor is showing you risk-tier dashboards and skipping the provenance graph, they're optimizing for the 2024 audit. The 2026 audit is going to eat that approach.

The recomposition

Here's the broader pattern I keep seeing. The previous generation of security tooling fragmented every problem into its own product: SAST, DAST, CSPM, CWPP, SIEM, SOAR, vuln management, asset inventory. Each was justifiable. Together, they produced the dashboard sprawl every CISO complains about.

AI security is being born into a different world. The artifacts cross every boundary at once. A prompt lives in code (SAST territory), runs in a container (CWPP territory), gets attacked over a network (DAST territory), produces logs (SIEM territory), and is an asset (inventory territory). You cannot solve AI security by buying five tools and hoping the integrations work. You have to start from the graph and let the capabilities compose around it.

That's the recomposition. The previous decade fragmented; this decade is recomposing. The AIBOM is not a product category. It's the substrate the next ten years of security will run on, the same way the CMDB tried and failed to be in the last decade. Get it right and everything else — detection, response, governance, audit — gets easier. Get it wrong and you'll be the CISO sending the spreadsheet to the board at 11 p.m. the night before earnings.

Where to start this quarter

If I were standing up an AIBOM program tomorrow, I'd do three things this quarter and resist the urge to do more.

First, get discovery running across every code repo and every production environment. Not declared inventory. Discovered inventory. cyscan against the repos, cyradar against the runtimes, and reconcile the two graphs. The gap between what code says you have and what runtime says you have is, in my experience, where 80% of the risk lives.

Second, instrument prompts and agent definitions as versioned artifacts with named owners. This is the cheapest high-leverage thing on the list and almost nobody does it. A prompt change without a diff is malpractice in 2026.

Third, build the deprecation query. Pick one model. Ask the AIBOM what would break if you turned it off. If you can't answer in under a minute, your AIBOM isn't real, and now you know where to invest.

Skip everything else for the first 90 days. Risk tiers, executive dashboards, board reporting — they're all downstream of having a discovered graph with owners. Build the substrate. The reporting layer is easy once the substrate is right.

If you want to see what discovered-not-declared AIBOM looks like in practice, start with cyscan for repo-side discovery and cyradar for runtime fingerprinting at cybrium.ai. If you want to talk through your specific environment — the messy one, the one with the forgotten Lambda and the vendor SDK and the intern's GCP project — find me at anand@cybrium.ai.

Why Every CISO Needs an AIBOM in 2026 — And What Vendors Miss

Grumpy Sage — Mon, 22 Jun 2026 17:41:41 +0000

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.

Why Every CISO Needs an AIBOM in 2026 — And What Most Vendors Get Wrong

Grumpy Sage — Thu, 04 Jun 2026 16:22:06 +0000

A friend of mine runs security at a mid-size fintech. Last month she got a Slack DM from her general counsel at 9:47 on a Tuesday night. The Italian DPA had sent a questionnaire. Standard stuff on paper: list the AI systems processing EU resident data, the foundation models behind them, the training data sources, the fine-tunes you've deployed, and the third-party inference endpoints you call. Forty-eight hours to respond.

She opened a ticket with her platform team. By midnight she had a partial answer for the two flagship products. By noon the next day she had partial answers for six more. By the deadline she had submitted a document that, in her words, "was 70% true and 30% me hoping." The part that made her sick wasn't the gaps. It was that engineering had stood up a new RAG pipeline against a self-hosted Mixtral fine-tune the week before, and nobody in her org had known until she went looking. Not the platform team. Not procurement. Not her. A whole production AI system with customer PII flowing through it, and the security team learned about it from a regulator.

She told me this story over coffee and asked the question every CISO I talk to is asking right now: "How do other people have an actual answer to this?" The honest reply is that most don't. They have an SBOM, maybe a vendor inventory in a GRC tool, and a Notion page someone updated in October. That is not an AIBOM. That is a wish.

The thesis

An AI Bill of Materials isn't an SBOM with "model name" added as a column. It's a fundamentally different artifact because AI systems have layers SBOMs were never designed to capture: weights, training data, fine-tunes, prompts, retrieval indexes, agent tool graphs, and the runtime serving stack. Every one of those layers is a security boundary. Every one of them changes independently. If you can't enumerate them with the same rigor you enumerate Python packages, you can't reason about your risk, you can't respond to regulators, and you can't tell your board what you actually run. In 2026, that gap is no longer tolerable.

What an AIBOM actually contains

Let me be concrete, because vagueness is how this whole space went sideways.

A real AIBOM has seven layers. The first is the model layer itself: which base models you depend on, with versions, licenses, and provenance. Llama-3.3-70B-Instruct is not the same as a quantized GGUF derivative someone pulled from Hugging Face on a Thursday. The hash matters. The source matters. The license matters because Meta's community license has acceptable use clauses your legal team has probably never read.

The second is the adapter layer: every LoRA, every QLoRA, every full fine-tune sitting on top of a base. Each of these inherits the base model's vulnerabilities and adds its own attack surface. A fine-tune trained on internal support tickets will memorize PII. Your AIBOM has to know that fine-tune exists, where the training data came from, who approved it, and which products consume it.

The third is the data layer: training corpora, evaluation sets, retrieval indexes, vector databases, and the embedding models that populate them. This is where the GDPR questions live. A vector store containing customer email embeddings is a database of personal data, full stop, and most orgs treat it like cache.

The fourth is the inference layer: where models actually run. Self-hosted on Ollama? Behind vLLM with continuous batching? Through OpenAI's API? Bedrock? An employee's laptop running LM Studio on Tailscale? Each of these has different threat models, different network exposure, and different telemetry. The number of orgs I've seen with shadow vLLM servers running on a forgotten GPU box is genuinely funny if you don't think about it too hard.

The fifth is the prompt and tool layer: system prompts, prompt templates, RAG retrieval logic, agent tool definitions, and MCP server endpoints. This is the layer that the OWASP LLM Top 10 actually maps to. It's also the layer that changes most often and is documented least.

The sixth is the identity and access layer: which humans and which services can call which models, with which permissions, against which data. If your AIBOM doesn't tie back to your IAM model, it's a museum exhibit.

The seventh is the dependency layer: the boring software supply chain underneath everything. Transformers version. CUDA version. Triton kernels. The PyTorch wheel. The 1,815 rules in our scanner catch a lot here, but the point is that AI infrastructure is software, and software has the supply chain problems software has always had.

You need all seven. Drop any of them and your AIBOM has a blind spot a regulator or attacker will find.

What vendors are getting wrong

Here's where I'm going to make some people unhappy.

Most "AIBOM" tooling on the market right now is one of three things. It's a CSPM with a tab labeled "AI." It's a discovery tool that scrapes git repos for import openai and calls it inventory. Or it's an SBOM generator that added a JSON field for model name. None of these are AIBOMs in any meaningful sense.

The CSPM-with-a-tab products will tell you which Azure OpenAI deployments exist in which subscriptions. Useful. Stops at the cloud boundary. Can't see your self-hosted Ollama instance, can't see the LoRA your data science team trained last quarter, can't see the prompts, can't see the vector store. You get maybe 20% of the picture and a confident dashboard about it.

The code-scraping discovery tools find the calls. They don't find the runtime. They don't know if that client.chat.completions.create() is actually wired up in production or if it's dead code from a prototype. They especially don't know about the responses: what data flows back, what gets logged, what gets cached.

The SBOM-with-extra-fields products are the most cynical of the three. SBOM formats like SPDX and CycloneDX have been bolting on ML-BOM extensions, and the extensions are fine as a serialization format. But generating one requires the underlying inventory work, and the vendors selling "we support ML-BOM" usually mean "we let you fill in the fields manually." That's not inventory. That's a form.

The other thing vendors get wrong is treating the AIBOM as a static artifact. Your AIBOM has to be a continuously regenerated view, not a PDF you ship to a regulator once. Models get swapped. Adapters get retrained. RAG indexes get rebuilt nightly. A snapshot from Tuesday is wrong by Thursday. Anyone selling you an "AIBOM" without a story for continuous generation is selling you a fossil.

The self-hosted blind spot

I want to spend a minute on this because it's the part nobody wants to talk about.

The center of gravity in enterprise AI has moved. Three years ago every interesting AI workload ran on someone else's API. Today, a huge fraction of the AI that actually touches sensitive data runs on infrastructure you own, on runtimes like Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp. Each of those has a different deployment story, a different default network posture, and a different set of known vulnerabilities.

A vLLM server in production with no authentication on its OpenAI-compatible endpoint is a fully unauthenticated inference oracle for anyone who can reach it. An Ollama instance bound to 0.0.0.0 on an internal subnet is a model exfiltration risk and, if it's loaded with a fine-tune of your proprietary data, an IP exfiltration risk. Triton has had a real CVE history. LocalAI ships with defaults that I would charitably describe as "trusting."

Our radar scanner covers all of these because we built it specifically to map the self-hosted runtime layer. You cannot have an AIBOM in 2026 that omits self-hosted inference. That's not opinion. That's where the workloads are. If your vendor's discovery story stops at the cloud control plane, you don't have an AIBOM. You have an Azure inventory with extra steps.

What continuous AIBOM generation looks like

The mechanics matter. Let me walk through what we actually do, because I think it's the right shape and I want other vendors to copy it.

You start with a scan of the code repositories. Not for import openai calls, but for the full surface: model loading code, training scripts, prompt templates, agent tool definitions, RAG pipelines, MCP server registrations, evaluator harnesses. Our static scanner catches all of this across 75+ languages with 1,815 rules. That gives you the declared intent of your AI systems.

Then you scan the network. You enumerate inference runtimes that are actually live, fingerprint them, and check them against a known-issue catalog. This is where the radar piece earns its keep. The intent layer tells you what engineers said they were building. The runtime layer tells you what's actually running. The delta between those two is where the worst surprises live.

Then you scan the web-facing surface. Any agent that takes external input, any RAG system with user-controlled retrieval, any model behind a public endpoint needs to be probed. We run 22 categories of fuzzing against these surfaces and convert about 95% of community templates so you're not reinventing prompt injection wheels.

Then you correlate. A finding on a runtime is interesting. A finding on a runtime that you can prove is reachable from a public agent endpoint that has tool access to a database with PII is a Sev 1. Correlation is where AIBOMs become useful instead of just exhaustive.

And then you publish. Through an API, through a dashboard, and through an MCP server that exposes the inventory as 10 tools an LLM can query. That last piece sounds gimmicky until you've watched an incident response where the responder asks "what models touch the payments service" and gets an answer in three seconds instead of three hours.

A CLI example, because the abstraction is doing too much work:

cybrium aibom generate --org acme --output cyclonedx-mlbom.json
cybrium aibom diff --from last-week --to now
cybrium aibom query "models with PII training data exposed to internet agents"

The diff is the part that matters operationally. AIBOM as a verb, not a noun.

Why this has to be one platform

I get asked constantly why we built scan, radar, and web fuzz as one platform instead of three products. The answer is correlation, but the deeper answer is that the layers of an AI system don't respect product boundaries.

A prompt injection in a web-facing agent is a web vulnerability. The model it exploits is a runtime vulnerability. The tool it calls is a code vulnerability. The data it exfiltrates is a data governance failure. If your AIBOM lives in one product, your runtime scanner lives in another, and your web fuzzer lives in a third, you have three inventories and zero correlation. You have to write the JOIN yourself, in a spreadsheet, at 2 a.m., while a regulator is waiting.

Single platform isn't a marketing position. It's the only way the math works. The MCP server exposing the inventory matters because it lets the same correlation graph answer questions from a SOC analyst, a compliance auditor, an engineering lead, and an LLM agent doing automated triage. One graph. Ten tools. Many consumers.

The recomposition

What I'm watching happen across the industry in 2026 is a recomposition of the security stack around AI as a first-class asset class. We had CMDBs for hardware. We got CSPMs for cloud. We got SBOMs for software supply chain. Now we need AIBOMs for AI, and the orgs that treat it as a checkbox on an existing tool are going to be the orgs explaining to regulators why their inventory was wrong.

The reason this matters more than the last asset class additions is that AI systems are stochastic, composable, and rapidly mutating. A package version is a fact. A model's behavior is a distribution. A fine-tune changes that distribution. A prompt change changes it again. RAG retrievals change it on every query. Your AIBOM isn't just an inventory of nouns. It's an inventory of behaviors-in-context, and the tooling has to reflect that.

The EU AI Act high-risk system documentation requirements landed for real this year. NIST AI RMF mappings are now showing up in customer security questionnaires. SOC 2 auditors are starting to ask about model inventory in the controls walkthrough. The market is converging on AIBOM as a required artifact, and the vendors who got there with real architectural answers are going to look very different from the ones who bolted a tab onto an existing dashboard.

My friend at the fintech is rebuilding her program around continuous AIBOM generation right now. The Italian DPA letter was the forcing function, but she would have gotten there anyway because the alternative is doing this work manually every time a regulator, customer, or board member asks. Manual doesn't scale past the third question.

If you're a CISO in 2026 and you can't answer "what AI runs in our environment, what data touches it, what's reachable from the internet, and what changed this week" in under five minutes, you have an AIBOM problem. The good news is it's a solvable problem. The better news is the tooling finally exists to solve it without an army of analysts.

Start with cyscan for the code surface, layer in cyradar for the runtime, add cyweb for the web-facing agents, and pipe the whole correlation graph through the MCP server so your team can ask it questions in English. That's an AIBOM. Everything else is a spreadsheet with ambitions.

If you want to talk through yours, find me at anand@cybrium.ai.

Why Every CISO Needs an AIBOM in 2026 and What Vendors Get Wrong

Grumpy Sage — Mon, 01 Jun 2026 18:39:07 +0000

A friend of mine runs security at a mid-sized fintech. About 400 engineers, Series D, the kind of place where the AI strategy memo got written in a weekend and shipped to prod the following Tuesday. She called me in March, somewhere between annoyed and panicked, because her board had asked a simple question: "What models are we running, and where did they come from?"

She had answers. They were wrong.

The official answer was "GPT-4 and Claude, through the standard gateway." The actual answer, after two weeks of digging, was seventeen models. A Llama 3.1 8B fine-tune hosted on a self-managed vLLM box that someone in the ML team spun up for a customer-support prototype, then forgot to tear down. Three Hugging Face embedding models pulled at container build time with no pinned hashes. A Whisper variant running on a developer's GPU workstation that was, somehow, reachable from the staging VPC. Two LoRA adapters fine-tuned on customer support tickets, sitting in an S3 bucket with a permissive policy. And a llama.cpp build serving a 7B model to an internal Slack bot that nobody could remember authorizing.

The part that got me, when she walked me through it, was that none of this was shadow IT in the old sense. Every one of these systems had a Jira ticket. Every one had been "approved." The inventory just didn't exist. There was no single place she could point at and say: this is what we run, this is where the weights came from, this is what data trained them, this is what they're allowed to talk to.

That's the AIBOM problem. And in 2026, if you don't have one, you don't have an AI security program. You have vibes.

The thesis

Most AIBOM products being sold right now are spreadsheets with a UI. They list model names and versions, slap a CycloneDX export on top, and call it done. That's not an AIBOM. That's a parts list pretending to be a bill of materials. A real AIBOM is a living graph that connects models, weights, datasets, prompts, tools, agents, and the data flows between them, and it has to be generated continuously from what's actually running in your environment, not from what someone typed into a form six months ago.

What an AIBOM actually contains

The SBOM analogy is useful but it breaks down fast. A traditional SBOM tells you which libraries are in a binary. The relationships are mostly one-directional: this binary depends on this package at this version. You can run Syft or Trivy and get something reasonable.

An AIBOM has to capture relationships that aren't dependencies in the SBOM sense. A fine-tuned model depends on a base model, sure, but it also depends on the training dataset, the fine-tuning configuration, the RLHF rewards, and increasingly, the prompts that shape its runtime behavior. An agent depends on the model serving it, the tools it can call, the memory store it reads from, and the MCP servers it's connected to. None of this shows up in a CycloneDX schema unless you stretch the schema until it tears.

So at minimum, an AIBOM has to capture: the models themselves with their weights provenance and hash; the training and fine-tuning datasets with lineage back to source; the inference infrastructure (whether that's vLLM, Ollama, TGI, Triton, LocalAI, LM Studio, or llama.cpp); the prompts and prompt templates in use; the tools and MCP servers exposed to those models; the data flows in and out of each model boundary; and the humans or service accounts who can change any of the above.

If your vendor's AIBOM is missing three or more of those, you bought a model registry, not an AIBOM.

Where most vendors fail

I've looked at probably a dozen AIBOM products this year. The failure modes cluster into four patterns.

The first is the form-based AIBOM. Engineers fill out a questionnaire, and the platform stores it. This is theater. The model running in production at 3 a.m. on a Wednesday is not the model someone described in a form during onboarding. Within six weeks the inventory drifts and you're back to vibes.

The second is the API-gateway-only AIBOM. The product hooks into your OpenAI and Anthropic API calls, watches the traffic, and infers what models you're using. This catches your hosted model use. It catches nothing else. Your self-hosted Ollama instance, your vLLM cluster, your llama.cpp processes, the LM Studio sessions on developer laptops, the LocalAI deployments your data team set up - all invisible. And by my estimate, self-hosted inference accounts for somewhere between 30 and 60 percent of model usage at any serious engineering org right now. You're missing half your attack surface.

The third is the registry-as-AIBOM trap. The product is really a model registry with provenance fields. It's great if every model goes through the registry. But registries are opt-in. They don't see what they don't see. And the entire point of a BOM is to discover the things you forgot to register.

The fourth, and this one annoys me the most, is the static AIBOM. The product generates a CycloneDX file at build time, hands it to you, and considers the job done. AI systems aren't static. The same model with a different system prompt is a different system, for security purposes. The same agent with a new tool connected is a different blast radius. If your AIBOM only updates at deploy time, it's already stale by the time it lands in your SIEM.

What you actually need to generate one

If I were building an AIBOM program from scratch today, here's how I'd think about the inputs.

You need code scanning that knows about AI. Not just "is there a call to openai.ChatCompletion in this file," but the structure of agent definitions, RAG pipelines, prompt templates, tool registrations, and model loads from disk or HF Hub. This is why we built cyscan with 1,815 rules across 75-plus languages, with a heavy investment in AI-aware detection. A traditional SAST tool will tell you nothing useful about whether your agent has access to a tool it shouldn't. An AI-aware scanner can.

You need runtime discovery for self-hosted inference. Somebody has to walk your network and your container runtimes and find the Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp processes. They have to fingerprint them, identify the models being served, and check for the eight ways each of those servers can be misconfigured. That's what cyradar does. If you're scanning only for the hosted APIs, you're playing a different game than the one your attackers are playing.

You need web-layer awareness. Most AI apps end up behind an HTTP boundary eventually. A model is a backend. If your AIBOM doesn't connect the HTTP endpoints in your app to the models behind them, you can't reason about external attack surface. We use cyweb for this with 22 fuzz categories tuned for AI-shaped vulnerabilities, and we get to a 95 percent template conversion rate from the upstream community templates so we don't miss the boring web stuff while we're chasing the new stuff.

You need to model the agent and tool graph. Every MCP server is a capability boundary. Every tool a model can call is a potential confused deputy. Our MCP server exposes 10 tools and we treat each one as a documented edge in the AIBOM graph, with explicit allowlists for which agents can invoke which tools. If you can't answer "which models can call which tools" in your AIBOM, you can't answer the actually-important question, which is "what's the worst thing this model can do if it gets jailbroken."

You need provenance for weights. Hashes. Signatures where they exist. Download source. License. Known-bad lists for poisoned or trojaned models on Hugging Face. This is the part that looks most like a traditional SBOM, and it's also the part most vendors do least badly.

Finally, you need this to be continuous. Daily at minimum. Ideally on every deploy and on a scheduled drift check. Otherwise it's a snapshot, and snapshots lie.

A small example of what continuous looks like

Here's a sketch of what we run on customer environments. You don't need to use our tools to do this; the pattern matters more than the implementation.

# Discover self-hosted inference servers across the environment
cyradar discover \
  --targets ./targets.yaml \
  --servers ollama,vllm,tgi,localai,triton,lmstudio,llamacpp \
  --output aibom-runtime.json

# Scan repos for AI surface: models loaded, agents defined, tools registered
cyscan code \
  --repos ./repos.txt \
  --rules ai \
  --output aibom-code.json

# Walk the HTTP attack surface for AI endpoints
cyweb scan \
  --targets ./web-targets.yaml \
  --ai-categories all \
  --output aibom-web.json

# Merge into a single AIBOM graph and diff against last known good
cybrium aibom merge \
  --inputs aibom-runtime.json,aibom-code.json,aibom-web.json \
  --diff-against last-good.json \
  --output aibom-current.json

The diff is the part most people skip. The AIBOM itself is interesting. The change from yesterday's AIBOM to today's is what you should be alerting on. A new model appeared. A tool got connected to an agent that didn't have it before. A vLLM server is suddenly exposed on a new port. That's the security signal.

The fine-tuning and RAG blind spot

The other place most AIBOM products fall over is anything that touches your data.

Fine-tunes inherit the security posture of their training data. If you fine-tuned a Llama variant on a corpus that included customer PII, the model is now a potential data exfiltration vector even if your inference layer is perfectly locked down. The AIBOM has to know this. It has to record what data went into the fine-tune, who approved it, what residency constraints apply, and what the deletion story is when a customer invokes their rights.

RAG is similar but worse, because the data isn't baked in at training time, it's fetched at runtime. Your AIBOM needs to know which vector stores each agent can read from, what's in those stores, how they're populated, and what the access control model is at the chunk level. Most products treat the vector store as opaque infrastructure. It isn't. It's part of the AI system, and it belongs in the BOM.

I've seen one customer discover, through an honest AIBOM exercise, that their support agent was retrieving from a vector store that contained the contents of an internal HR wiki because the embedding pipeline was pointed at "all of Confluence" with no filtering. The AIBOM caught it. Their old "AI governance committee" had been signing off on the agent for nine months.

Why this has to be one platform

I get asked a lot why we bundled code scanning, runtime AI discovery, web fuzzing, and the MCP server into one platform instead of selling them as separate products. The reason is exactly the AIBOM problem.

An AIBOM is, by definition, a join across surfaces. Code surface plus runtime surface plus web surface plus agent-and-tool surface. If those four sources of truth live in four different vendors with four different schemas and four different update cadences, the join is hopeless. You end up with four partial inventories that disagree, and a quarterly meeting where everyone explains why their slice is the right one. Nobody ships anything.

When the surfaces share a graph, the diff is meaningful. You can ask: this new HTTP endpoint that cyweb found, what model does it route to, what tools does that model have, and is any of that change new compared to last week. You can ask that in one query because it's one graph. Not because we're smarter than other vendors. Because we made the architectural decision to keep the model coherent across surfaces from day one.

The recomposition

What's actually happening in the market right now is that the old vendor categories are being torn up and re-glued around the AI system as the unit of analysis. SAST, DAST, CSPM, model registry, data catalog, agent observability - those are five products and three buyer personas in 2024. In 2026 they're one workflow with one BOM at the center.

The CISOs who get this are quietly rebuilding their security architecture around the AIBOM. They're treating it as the central inventory, the way CMDB was supposed to be in the ITIL era and never quite was. They're plumbing it into change management, into incident response, into vendor risk, into audit. They're using it as the source of truth for which AI systems exist and what each one is allowed to touch.

The CISOs who don't get it are still buying point products and trying to staple them together with a Jira board. They're going to spend 2026 explaining to their boards why they keep getting surprised. The surprises are the AIBOM gaps. There's no other word for them.

If you remember one thing from this post, remember this: the question your board is going to ask in 2026 is not "are you doing AI security." It's "show me the inventory." If your answer involves opening five different consoles, you've already lost the meeting.

What to do this quarter

Start with the discovery problem. Run cyradar against your environment and find the inference servers you didn't know about. That alone will reframe how you think about scope. Then run cyscan on your repos with the AI rules enabled and find the agent definitions, tool registrations, and model loads in code. Then merge. Look at the diff against your current "official" inventory and prepare to be surprised.

You can dig into the specifics at cybrium.ai/cyradar, cybrium.ai/cyscan, and cybrium.ai/cyweb, or read the AIBOM architecture notes at cybrium.ai/aibom.

If you want to talk through yours, find me at anand@cybrium.ai.

Pitt Season 3 Already Premiered in 400 Hospital Server Rooms This Year

Grumpy Sage — Fri, 15 May 2026 03:41:55 +0000

A 180-bed regional hospital in the Midwest lost its EMR at 2:14 a.m. on a Tuesday. The night-shift charge nurse noticed first — the Cerner terminal froze, came back to a lock screen she didn't recognize, then went black. By 2:40, the entire fourth floor was on paper. By 3:15, the ED was running on whiteboards and memory. Nurses were walking lab results between floors because the pneumatic tube system's controller had also gone down — it ran on the same network segment.

The CIO told me later that the part that shook him wasn't the ransomware demand. It was watching his team revert to procedures none of them had practiced since nursing school. He said it felt like watching an episode of Pitt, except the cameras weren't rolling and nobody was going to yell cut.

He wasn't being dramatic. If you've watched Pitt — the Max series set in a Pittsburgh trauma center — you've seen what happens when a hospital's digital infrastructure disappears. Systems go dark. Staff improvise. Patient data lives on sticky notes and shouted vitals. The show treats it as a dramatic set piece. For 389 U.S. hospitals hit by ransomware in 2025 alone, it was a Tuesday.

I keep coming back to this gap between fiction and operations. The entertainment industry has figured out that hospital cyberattacks make great television because the stakes are life and death and the failure mode is visceral — humans scrambling without the tools they've been trained to rely on. What the entertainment industry hasn't figured out, and what most healthcare security vendors haven't either, is that the attack surface making this possible is not the EMR. It's the building.

The systems that fail first and recover last in a healthcare cyberattack are not the clinical applications. They're the operational technology: HVAC controllers, pneumatic tube systems, nurse call stations, infusion pump networks, building management systems, medical gas monitors. These are the systems that turn a ransomware event from a billing disruption into a patient safety crisis. And almost nobody is scanning them.

The building is the attack surface

I spent a week last year walking the basements of three hospitals — two mid-size, one rural critical-access — documenting every networked device that wasn't a workstation or a printer. The list was longer than anyone expected.

Building management systems running BACnet on flat networks with no segmentation. Pneumatic tube controllers on Windows Embedded that hadn't seen a patch since 2019. HVAC units with default credentials accessible from the same VLAN as the nursing stations. Nurse call systems whose firmware update process required a vendor visit that nobody had scheduled in four years. Medical gas monitoring panels with Modbus/TCP interfaces that responded to unauthenticated queries from any device on the subnet.

None of these showed up in any of the three hospitals' IT asset inventories. The IT teams knew about servers, workstations, network gear. The facilities teams knew about the physical plant. Nobody owned the gap between them, and that gap was running on protocols designed in the 1990s for environments where the threat model was "the serial cable might get unplugged."

This is what I mean when I say the building is the attack surface. A ransomware operator who lands on a hospital network and finds BACnet devices responding to unauthenticated read/write requests doesn't just have leverage for a ransom. They have the ability to alter HVAC setpoints in surgical suites, disable nurse call systems, disrupt pneumatic tube routing, and interfere with medical gas monitoring — all without touching a single clinical application. The EMR can stay up and running. The hospital still can't safely operate.

In the Pitt pilot, the chaos starts with monitors going dark. In the real incidents I've reviewed, the chaos starts with the infrastructure nobody thought of as "cyber."

AI made the attacker faster than your patch cycle

The asymmetry in healthcare cybersecurity has always been stark. Attackers move fast; hospitals move slow. But AI has made this gap qualitatively different, not just wider.

I've been tracking the evolution of healthcare-targeting ransomware groups for two years now. The shift started in late 2024 and accelerated through 2025. What changed wasn't the malware itself — it was the reconnaissance. Groups are using LLM-assisted tooling to automate the exact kind of OT discovery I described doing manually in those hospital basements. Automated BACnet enumeration. Automated Modbus device fingerprinting. Automated identification of which building-management protocols are exposed and what default credentials they ship with.

A human operator doing this manually against a single hospital takes days. An AI-assisted pipeline does it against dozens of targets concurrently, triaging which hospitals have the most exposed OT infrastructure and therefore the most operational leverage for a ransom demand. The attacker doesn't need to understand HVAC control systems. The LLM reads the protocol documentation and generates the probe sequences.

This should worry every healthcare CISO, regardless of institution size. The economics of targeting have changed. It used to be that a 50-bed rural hospital wasn't worth the effort compared to a 500-bed academic medical center. When reconnaissance is automated and nearly free, every hospital with an internet-facing IP range is a candidate. The attacker's AI doesn't care about your bed count. It cares about your exposed BACnet port.

The 2025 numbers bear this out. Of those 389 ransomware incidents in U.S. hospitals, 41% were at facilities with fewer than 100 beds. The long tail of small and mid-size hospitals — the ones least likely to have dedicated security staff — is now the primary target pool. The Pitt scenario isn't reserved for large urban trauma centers with dramatic storylines. It's playing out in critical-access hospitals where the nearest backup facility is forty miles away and the IT department is one person who also manages the phone system.

Compliance frameworks know this but compliance alone doesn't fix it

HIPAA's Security Rule has required technical safeguards since 2005. The problem was never the requirement — it was the gap between what the regulation demands and what hospitals actually have the capability to assess.

Ask a compliance officer at a 120-bed community hospital whether they've conducted a risk assessment of their OT infrastructure. Most will tell you their risk assessment covers the EMR, the billing system, the patient portal, and the network perimeter. Maybe the medical devices if they're forward-leaning. Almost never the building management systems, the pneumatic tubes, the nurse call stations, or the HVAC controllers. Not because they don't care, but because they don't have a scanner that speaks BACnet and Modbus, and their compliance framework templates don't have a line item for "building automation system running unauthenticated protocol on clinical network."

This is where I think the industry has failed healthcare. We've built compliance tools that check boxes against the EMR and call it done. We've built vulnerability scanners that speak HTTP and SSH and call the network "scanned." Neither finds the Siemens HVAC controller with default credentials on the same subnet as the cardiac monitors.

The frameworks themselves are getting better. NIST's Healthcare Cybersecurity Framework, HHS's updated HIPAA Security Rule proposed in 2025, and the FDA's premarket cybersecurity guidance all now explicitly call out connected medical devices and operational technology. But a framework that says "assess your OT" is useless without a tool that can actually do it safely — without disrupting the devices it's scanning, without flooding fragile BACnet networks with traffic they can't handle, and without requiring a protocol expert on-site to interpret the results.

What OT scanning in healthcare actually looks like

This is the problem we built cyprobe to solve. It's a purpose-built OT and SCADA discovery and posture engine — not a network scanner with OT support bolted on as a feature checkbox. A tool that speaks the native protocols — BACnet, Modbus/TCP, EtherNet/IP, DICOM, HL7 MLLP — and understands what the responses mean in a healthcare context.

Here's what a cyprobe scan against a hospital network actually produces. First, it discovers every OT device on reachable subnets using protocol-native probes. No aggressive port scanning. No banner grabbing. It speaks BACnet Who-Is and reads the device's object list. It sends Modbus function code 43 to read device identification. It does DICOM C-ECHO to find imaging endpoints. The output is a typed inventory: device class, manufacturer, firmware version, protocol, authentication status, network segment.

Second, it assesses posture against the device's actual capabilities. Can this BACnet device be written to without authentication? Does this Modbus device respond to function codes that should be restricted? Is this DICOM endpoint accepting associations from any calling AE title? Is this HL7 interface transmitting PHI over an unencrypted channel?

Third, it maps what it finds to the compliance frameworks that matter. Each finding carries references to HIPAA Security Rule sections, NIST CSF subcategories, and the specific controls from whatever framework your compliance team is working against.

The output is not "port 47808 is open." The output is "Siemens Desigo CC building controller at 10.4.12.15 accepts unauthenticated BACnet WriteProperty requests on HVAC setpoint objects for the surgical suite air handling unit. HIPAA 164.312(a)(1) — access control. Risk: an attacker on this network segment can alter surgical suite environmental conditions without credentials."

That's the difference between a network scan and an OT assessment. One tells you a port is open. The other tells you what it means for patient safety.

Posture, not just scanning

Scanning is the beginning, not the end. What I've learned building Cybrium is that healthcare organizations — especially smaller ones — need a platform that turns scan results into a compliance posture they can act on and maintain over time.

A 50-bed critical-access hospital doesn't have a team of five security engineers to triage findings. They might have one IT person who also manages the phone system and the printer fleet. What they need is not a 200-page vulnerability report. They need a prioritized action list that says: here are the three things that will reduce your risk this week, here's exactly what to do for each one, and here's how this maps to the HIPAA requirement your auditor is going to ask about in October.

This is what the Cybrium platform does around cyprobe's scan results. Every finding feeds into a compliance posture dashboard that maps your OT, network, and application security state against HIPAA, NIST CSF, HHS CPGs, and — if you're in scope — PCI DSS and SOC 2. The dashboard is not a checklist. It's a live score that changes as your environment changes, because we run continuous assessments, not annual point-in-time audits that are stale before the PDF is delivered.

For healthcare organizations that need to demonstrate compliance to auditors, insurers, or regulators, the platform generates evidence-backed reports. Not "we believe we are compliant." Instead: here is the scan data, here are the controls it maps to, here is the residual risk, here is what we're doing about it, and here is the timeline. Auditors can drill into the underlying findings. Insurers can see the trend over quarters. Regulators get the artifact they need without the hospital spending six weeks preparing for the review.

We price healthcare at $5 per bed per month. That's deliberate. A 50-bed critical-access hospital pays $250 a month for the same platform, the same scanners, and the same compliance mapping that a 500-bed system gets. The attack surface doesn't care about your revenue. The security tooling shouldn't either.

The recomposition happening in healthcare security

What's happening in healthcare cybersecurity right now is a recomposition of the same kind that's reshaping the rest of the security industry, but with higher stakes and tighter constraints.

For twenty years, hospitals have bought point solutions: one tool for the EMR, one for the network, one for endpoints, and nothing for OT. Each tool produces its own reports, speaks its own language, and gets reviewed by a different person — if it gets reviewed at all. The result is a pile of point-in-time assessments that nobody can synthesize into a coherent picture of institutional risk.

The Pitt scenario — everything goes dark at once — happens precisely because these systems are connected in ways that no single point solution can see. The ransomware that encrypts the EMR server also encrypts the BACnet controller that happens to be on the same network segment because nobody ever segmented it, because no scanning tool ever flagged it as a risk, because no compliance framework ever asked about it specifically enough to force the question.

The recomposition is toward platforms that see all of it. OT and IT. Clinical and facilities. Network and application. Compliance and posture. Not because platforms are inherently better than point solutions — sometimes they're worse — but because in healthcare, the attack chains cross every boundary that point solutions draw, and the risk can only be assessed by something that sees across those boundaries.

That is the bet we've made with Cybrium. One platform that scans your code, your cloud, your network, your web applications, your AI infrastructure, and your operational technology. That maps every finding to the compliance frameworks your auditor cares about. That gives a 50-bed clinic the same quality of security posture visibility that a 500-bed academic medical center gets from a dedicated security team.

If you're running a hospital, a clinic, or a healthcare IT organization of any size and you want to know what your OT attack surface actually looks like — not what you hope it looks like, but what an attacker with an LLM and a free afternoon would see — find me at anand@cybrium.ai. The Pitt scenario makes great television. It makes a terrible incident report.

Every CISO Needs an AIBOM in 2026 — Here's What Vendors Get Wrong

Grumpy Sage — Thu, 14 May 2026 15:19:36 +0000

A friend of mine runs security at a mid-sized fintech. Last month her board asked a question that should have been simple: "How many AI models are in production, and where did they come from?"

She had a vendor-provided AIBOM. It listed seventeen "AI components" — which turned out to be seventeen pip packages with names like transformers and langchain. That was the entire inventory. No mention of the three fine-tuned Llama variants her ML team had pushed to a Triton server two quarters earlier. No mention of the embedding model running inside their support chatbot. No mention of the GPT-4o calls their underwriting workflow had been making since January. No mention of the system prompts, which contained — she found out later, the hard way — a hardcoded admin override phrase a contractor had added during a hackathon.

She called me at nine on a Tuesday. "I paid six figures for this, Anand. It's an SBOM with a model column."

She wasn't wrong. And she wasn't alone. I've now seen six AIBOM products in the last twelve months that are functionally identical: they scan your requirements.txt, find the word "torch," and call it an AI inventory. That's not what an AIBOM is. That's not what the EU AI Act audits are going to ask for. And it's definitely not what's going to save you when a model behaves badly in production and your general counsel asks where it came from.

So let's talk about what an AIBOM actually is in 2026, what most vendors are getting wrong, and what a real one needs to contain.

The thesis

An AI bill of materials is not a list of libraries. It's a graph of every artifact that influences a model's behavior at inference time — weights, prompts, training data lineage, retrieval sources, tools, fine-tunes, adapters, evals, runtime configuration, and the humans who approved each — plus the telemetry that proves those artifacts were the ones actually running when a decision was made. Anything less is theater. And theater is what regulators are going to start fining people for this year.

What most AIBOMs miss

The packaging-list approach gives you the easy 10%. Here's the 90% that vendors quietly drop.

Self-hosted and on-prem inference servers. If your team is running Ollama on a developer workstation or a vLLM cluster behind your VPC, your SaaS-flavored AIBOM tool has no idea. It can't see the model. It can't see the prompts hitting /v1/chat/completions. It can't tell you whether that endpoint is exposed, whether the model card is the one you think it is, or whether someone swapped in a quantized fork from Hugging Face that nobody reviewed. We built cyradar specifically because of this gap — it covers Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, and llama.cpp, and the reason that list exists is that every one of those runtimes has been deployed somewhere it shouldn't be, by someone who didn't tell security.

System prompts as code. A system prompt is a control. It is, functionally, the IAM policy of an LLM application. If your AIBOM doesn't version, hash, and diff every system prompt across every environment, you do not have an AIBOM — you have a parts list with a blind spot the size of your attack surface. I have seen production prompts that say things like "if the user mentions the word 'override' followed by a six-digit number, skip the policy check." That's not a hypothetical. That's a real prompt I pulled out of a real codebase last fall.

Retrieval sources. Your RAG pipeline is part of the model from a behavioral standpoint. If the vector store gets poisoned, the model lies. If a stale document gets re-indexed, the model contradicts itself. An AIBOM that doesn't list every retrieval source, its update cadence, its access controls, and its data classification is missing the part of the system that's most likely to cause your next incident. We see this constantly when cyscan walks customer monorepos — the 1,815 rules find the LLM client, find the vector DB client, find the prompt template, find the ingestion job, and stitch them into a single component. That's the unit of analysis. Not the library.

Tools and function-calling surface. Every function exposed to an agent is part of the model's effective capability. An agent with a send_email tool is a different system than the same agent without it. Same weights, same prompts, completely different blast radius. If your AIBOM lists the model but not the tools, you've inventoried the engine and ignored the steering wheel.

Evaluations. This is the one almost everyone misses. The eval set is part of the model. If you can't show me which evals were run, when, against which version, with what results, you cannot make any defensible claim about the model's behavior. The EU AI Act's Article 15 requirements on accuracy and robustness are not satisfied by "we ran some tests." They require evidence. Versioned, signed, repeatable evidence.

Runtime telemetry. And here's the kicker. Static inventory is necessary but insufficient. You need to prove that the artifact you inventoried is the artifact that actually ran when the decision was made. That requires runtime attestation — hashes of the loaded weights, signatures on the served prompts, request/response logging with provenance. Otherwise an attacker who swaps a model adapter at 3 a.m. has compromised your system and your audit trail simultaneously.

The composability problem

Here's why this is genuinely hard, and why I think a lot of vendors haven't tackled it: AI systems compose at runtime in ways traditional software doesn't.

A microservice is what it is at deploy time. You ship the container, you know what's running. An LLM application is different. The model is one artifact. The prompt is another, often loaded from a config service. The retrieval context is generated per-request from a vector store that's being updated continuously. The tool registry might be fetched from a service mesh. The user's session history influences behavior. The model's own previous outputs feed back in via memory.

So the "bill of materials" for a single inference call is computed on the fly. It's not a static document. It's a query.

This is the part that breaks the SBOM mental model. SBOMs are documents. AIBOMs need to be live indexes that can answer the question: "For the inference request that produced output X at timestamp T, what were all the artifacts in play, what were their versions, and who approved each?"

If your AIBOM can't answer that question, it's not going to survive a regulator's first follow-up email.

What a real AIBOM contains

Let me be concrete. Here's the minimum I'd accept on a vendor review in 2026.

A discovered inventory of every model artifact — base models, fine-tunes, adapters, LoRAs, quantizations — with cryptographic hashes, source provenance (where did it come from, who signed it, what license), and the environments where it's deployed. This includes the self-hosted runtimes I mentioned. If your tool can't enumerate a vLLM deployment, you have a hole.

A versioned registry of every prompt — system prompts, user prompt templates, tool descriptions, guardrail prompts — tied to the application and the model version it pairs with. With diff history. With approval metadata. With injection-test results.

A catalog of every retrieval source, with data classification, update cadence, access controls, and the embedding model used to index it. Plus the ingestion pipeline that populates it, because that pipeline is itself an attack surface.

A function and tool registry: every callable exposed to every agent, with input/output schemas, the permissions it executes under, and the human approval trail.

A linked eval history: which evals ran against which version, with results, signed, with reproducibility metadata.

Runtime telemetry that ties inference requests back to all of the above, with enough fidelity to reconstruct any given decision after the fact.

And — this is the part vendors hate hearing — it needs to be open and queryable, not a PDF export. If I can't run SQL against it or hit it from an MCP server, it's not operational. It's a compliance artifact. Those are different things.

Why the platform shape matters

This is the part where I tell you what we built and why, and you can take it as marketing or as honest reasoning, your call.

We didn't set out to build an AIBOM product. We set out to build the security tools an AI-native engineering org actually needs: cyscan for code and configuration analysis (1,815 rules across 75-plus languages, because AI code is polyglot in a way nothing has ever been), cyradar for AI runtime and inference exposure, cyweb for web application fuzzing with proper LLM-aware coverage (22 fuzz categories, 95% template conversion versus the upstream community feed).

The AIBOM emerged as the thing that ties them together. Because if cyscan finds a model invocation in your repo, and cyradar finds an inference endpoint on your network, and cyweb finds a prompt-injection-reachable form on your website — those are the same system. The value isn't three reports. The value is one graph.

That's why our MCP server exposes ten tools across the platform: so an LLM can do what auditors and incident responders do, which is pivot between code, runtime, web surface, and inventory. "Show me every model in production." "Now show me the prompts paired with that model." "Now show me which of those prompts were modified in the last thirty days." "Now show me whether the runtime endpoints serving them are externally reachable." That's an investigation. That's the unit of work. A vendor that only sees one of those layers cannot answer those questions.

I'm not arguing every customer needs all four tools. I'm arguing that the AIBOM is the wrong thing to buy as a standalone product, because the inventory is only as good as the discovery surface feeding it. And the discovery surface needs to cover code, runtime, web, and configuration to be useful in 2026.

The recomposition

What I've noticed in the last six months is that the categories from the last decade are dissolving. AppSec, CSPM, SBOM, ASPM, DSPM, AI governance — these were sold as separate products because the underlying problems used to be separable. They aren't anymore.

A modern AI application is a piece of code, that calls a model, that runs in a container, that pulls from a vector store, that exposes a web interface, that processes regulated data, that gets approved by a governance workflow. Securing it means seeing all of those layers as one thing. The product category that emerges from that is not "AIBOM." It's not "AI-SPM." It's something we don't have a great name for yet — but it's the security layer for AI-native engineering. The AIBOM is a view into that layer. An important view. But just a view.

The vendors who are selling AIBOMs as standalone products in 2026 are, I think, repeating the SBOM mistake from 2022. SBOMs as standalone products didn't work either. They became useful only when they were embedded into vulnerability management, supply chain attestation, and incident response workflows. AIBOMs will follow the same path, but faster, because the regulatory pressure is sharper and the architectural surface is bigger.

If you're a CISO evaluating AIBOM vendors right now, the question I'd ask is not "what fields does your AIBOM contain." The question is: "Show me the workflow that starts at a runtime alert and ends at the line of code, the prompt version, the approver, and the eval result that allowed it through." If they can demo that, they have an AIBOM. If they can only export a JSON file, they have a parts list.

My friend at the fintech has since replaced her vendor. She now has an inventory she can actually defend in front of her board, and — more importantly — in front of the regulator that's coming for her industry next year. The thing that haunted her about her old AIBOM was that the missing models had been in production for three quarters. The inventory said zero. Reality said three. That gap is the entire problem. Closing it is the entire job.

If you want to see what real AI inventory looks like — across code, runtime, and web surface — start with cybrium.ai/cyscan and cybrium.ai/cyradar. If you want to talk through your AIBOM strategy, or have me look at the one you just bought and tell you what it's missing, find me at anand@cybrium.ai.

Why Every CISO Needs an AIBOM in 2026 — And What Vendors Miss

Grumpy Sage — Mon, 11 May 2026 15:56:58 +0000

A friend of mine runs security at a mid-market fintech. Last month she got asked a question by her board that should have been trivial: "How many AI models are in production at our company, and where did they come from?"

She had a vendor-provided AIBOM. A real one. Generated by a well-known platform you've heard of. She pulled it up on the projector during the board meeting.

The AIBOM listed 14 models. She knew there were more.

After the meeting she spent two days with her platform team running their own inventory. The real number was 47. Some were embedded in SaaS tools her business teams had bought without telling her. Some were running locally on engineering workstations — llama.cpp instances developers had spun up to avoid the OpenAI rate limits. Two were fine-tuned variants of Llama 3 that a data science team had deployed inside a Kubernetes namespace nobody was scanning. One was a vLLM server somebody stood up on a GPU node six months ago and forgot about.

The vendor AIBOM had captured the API-based stuff. Anthropic. OpenAI. Bedrock. Easy targets. Everything that left a billing trail.

What it missed was the actual AI surface area. The part that sits inside her perimeter, runs on her hardware, processes her data, and has no rate limit or vendor SOC 2 to fall back on. The part that, if compromised, doesn't ring an alarm at a third party.

This is the AIBOM problem in 2026. The artifact exists. The compliance checkbox gets ticked. And the inventory is still wrong.

The thesis

An AIBOM is not an SBOM with a "model" row added. It's a fundamentally different artifact because AI systems have a fundamentally different supply chain — one that includes weights, prompts, embeddings, retrieval indexes, fine-tuning datasets, inference runtimes, and the agent scaffolding that ties them together. If your AIBOM doesn't capture all of those, what you have is a marketing document. And most of what's being shipped right now is exactly that.

What an AIBOM actually has to contain

Let me be specific, because the vendor space has gotten lazy about this.

A real AIBOM tracks the model itself — name, version, weights hash, license, provenance. That's the easy part. The part everyone gets right.

Then it has to track the inference runtime. This is where the wheels start coming off. Are you running Ollama? vLLM? TGI? LocalAI? Triton? LM Studio? llama.cpp? Each of those has its own CVEs, its own auth model, its own default configurations, and its own attack surface. A Llama 3 8B running on vLLM behind proper auth is a different risk than the same weights running on a default Ollama install with the API exposed on 0.0.0.0. The AIBOM has to know the difference.

Then the data lineage. What did the model get trained on? What does it get fine-tuned on? What sits in the retrieval index it's pulling from at inference time? An AIBOM that doesn't capture the RAG corpus is missing maybe 40% of the actual attack surface, because that's where prompt injection lives now. The model is fine. The PDFs your sales team uploaded last Tuesday are the threat.

Then the prompt layer. System prompts, tool definitions, agent loops, MCP server bindings. If your model has access to ten tools through an MCP server, those ten tools are part of the bill of materials. If one of them is a "send_email" tool with no human approval gate, that's a fact your AIBOM should be screaming about. Not buried in an appendix.

Finally, the runtime context. What network does this thing live on? What service account does it run under? What does it have IAM access to? You cannot reason about AI risk without that context, because the same model is a different risk profile depending on whether it can read your S3 buckets.

If you accept that list, you've already disqualified maybe 80% of the AIBOM tooling on the market. Most of it stops at "model name + version + license."

Where vendors go wrong, specifically

I want to name patterns, not vendors, because the patterns will outlive the vendors.

Pattern one: the SBOM-with-extra-columns approach. Some vendor took their existing software composition analysis tool and added a "model" detection rule. They find references to openai in your package.json and call that an AIBOM entry. This catches nothing self-hosted, nothing embedded in vendor SaaS, and nothing running outside the codebase you happen to be scanning. It's a checkbox.

Pattern two: the API-trail approach. Vendor watches your egress traffic or your cloud billing and infers AI usage. Better than nothing — catches shadow Anthropic accounts. But useless for anything inside the perimeter. A vLLM server on your internal GPU cluster generates zero egress traffic. It also generates zero AIBOM entries in this model.

Pattern three: the survey approach. Vendor sends a questionnaire to your dev teams. "List all AI systems in production." This is governance theater. The teams that fill it out conscientiously are not the teams you're worried about.

Pattern four: the model-registry approach. Vendor integrates with MLflow or SageMaker Model Registry and treats that as ground truth. Great if your entire organization uses one model registry. Nobody's entire organization uses one model registry. The shadow Ollama instance isn't in MLflow.

What all four of these share is that they're trying to generate an AIBOM from one perspective — the codebase, the network, the people, or the registry. AI systems live across all of those. You need detection that lives across all of those too.

The detection problem is a code problem first

Here's an opinionated take. The single highest-leverage place to build AI inventory is the codebase itself. Not because that's where everything lives, but because that's where most of the self-hosted, embedded, and shadow stuff originates. Somebody, somewhere, wrote an import statement.

This is what cyscan does in our platform. We've got 1,815 detection rules across 75+ languages, and a meaningful chunk of those are AI-specific patterns — runtime imports, model loading calls, agent framework usage, embedding library references, MCP client instantiations. If a developer imported vllm or instantiated an Ollama client or wired up a LangChain agent with a tool list, we want to know.

cyscan ai-inventory --repo ./monorepo --output aibom.json

The output isn't a list of models. It's a graph. Here's a service that loads Llama-3-8B-Instruct, runs it on vLLM, exposes it on port 8000, and is called by these three other services, one of which has an MCP server attached with these four tools. That's an AIBOM entry that you can actually reason about.

But code scanning alone isn't enough — that's the lesson I keep watching CISOs learn the expensive way. Code tells you what should exist. It doesn't tell you what's actually running on the GPU node nobody documented.

The runtime side: scanning what's actually live

This is where cyradar comes in, and where the architectural choice we made matters. cyradar specifically targets the self-hosted inference layer — Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp. We picked those seven because they cover almost everything self-hosted in 2026. If you've got a GPU running an LLM, it's almost certainly one of those.

The point isn't just to find them. The point is to fingerprint them. What model is loaded? What version of the runtime? Is the auth configured? Is the API exposed on the management network or the data network? What's the context window, the max tokens, the system prompt baked in at startup?

cyradar discover --cidr 10.0.0.0/8 --runtimes all
cyradar fingerprint --target 10.4.12.88:11434

That second command tells you not just "there's an Ollama at this IP" but "there's an Ollama 0.5.7 with llama3:70b and nomic-embed-text loaded, the API is open, no auth, last queried 14 minutes ago." That's an AIBOM entry the code scanner can't produce because the code that spun this up may not exist in any repo you scan. Someone ran ollama pull on a server.

Combine the code-side inventory with the runtime-side inventory, reconcile them, and now you have something that looks like a real AIBOM. The reconciliation is the hard part. The code says service X should be talking to Ollama. The runtime says Ollama is running on host Y. Are those the same instance? You need topology.

The agent and tool layer

I said earlier that tools are part of the bill of materials. I want to push on that, because it's where I see the most magical thinking in current AIBOM standards.

In 2024 you had models. In 2025 you had models with tools. In 2026 you have agents with toolchains that span MCP servers, traditional APIs, and other agents. The "thing" you're inventorying isn't really a model anymore. It's a capability graph.

Our own MCP server exposes 10 tools. Each one represents a capability — scan a repo, fingerprint a runtime, pull a fuzz template, query the rule database. Any agent that connects to our MCP server inherits those 10 capabilities. If your AIBOM lists "Claude" as one entry, you've underspecified the system by an order of magnitude. The relevant entry is "Claude + these MCP servers + these tool permissions + this system prompt + this RAG corpus."

That's a mouthful. It's also reality. Any AIBOM standard that can't express that — and most of the current ones can't, cleanly — is going to be obsolete within a year.

Web-facing AI surface, which everyone forgets

The other gap I see constantly: AI in the web tier. Chatbots embedded in marketing sites. AI search bars. Internal admin tools with an LLM assistant bolted on. Customer support widgets backed by some RAG pipeline somebody set up in a hurry.

These rarely show up in model registries. They rarely show up in code scans of the main monorepo because they live in their own little frontend repo. They almost never show up in network discovery because they call out to a vendor, not in.

cyweb's 22 fuzz categories include LLM-specific ones — prompt injection across the wire, jailbreak attempts via input fields, system prompt extraction, tool invocation abuse. When we scan a web property, we're not just looking for SQLi anymore. We're testing whether the friendly chatbot in the bottom corner can be talked into revealing the system prompt or executing tool calls it shouldn't. If it can, that goes into the AIBOM as a finding, attached to the model and runtime entry for that chatbot.

Our 95% template conversion rate vs upstream community templates matters here because the upstream community is fast — new prompt injection payloads land daily, and the gap between "known technique" and "we can test for it" needs to be small. An AIBOM that catalogs your AI systems but can't test them is a museum exhibit.

Why one platform

I keep getting asked why we built all of this — cyscan, cyradar, cyweb, the MCP server — instead of just picking one and going deep. The answer is exactly the AIBOM problem we've been talking about.

You cannot generate a real AI bill of materials from one vantage point. Code-only misses runtime. Runtime-only misses provenance. Network-only misses the SaaS-embedded stuff. Survey-only misses everything anyone forgot. To get an inventory that's actually correct, you have to triangulate from at least three of those.

If those three tools are bought from three vendors with three data models, the reconciliation happens in a spreadsheet maintained by an exhausted security engineer. I've watched this fail in real organizations. The spreadsheet drifts. The board gets the wrong number.

When the inventory comes from one platform with one data model, reconciliation is a join, not a meeting. That's the architectural choice. It's not about wanting to sell more SKUs. It's that the AIBOM problem is fundamentally a correlation problem, and correlation across vendor boundaries doesn't work.

The recomposition

Here's what I think is actually happening, beyond the AIBOM specifically.

The security industry spent twenty years building tools for a world where software was deployed by humans, ran in known places, and changed on quarterly release cycles. Every tool category — SAST, DAST, SCA, EDR, CSPM — assumes that model.

AI broke the model. Software is now partly deployed by agents, runs in places nobody documented, and changes when a developer types ollama pull. The asset isn't a server or a service anymore. It's a capability graph that includes weights, prompts, tools, data, and runtime. The discovery problem isn't "what hosts do I have" but "what can my systems do, and who taught them to do it."

The AIBOM is the first artifact that tries to express this. The current versions of it are bad because the standards bodies are still thinking in SBOM terms. The good versions, the ones that will actually matter when regulators start asking for them — and they will, by end of 2026 in at least three jurisdictions I'm tracking — those are going to look like capability graphs, not parts lists.

The vendors who get this right are the ones rebuilding their data model around the AI supply chain rather than retrofitting their old one. Everyone else is going to spend 2027 explaining to their customers why the AIBOM they shipped missed half the surface area.

What to do Monday

If you're a CISO reading this and your current AIBOM came from a vendor demo, do one experiment. Run your own inventory — survey the engineering teams, scan the internal network for the seven self-hosted runtimes, grep the monorepo for AI imports. Compare your number to the vendor's number.

If they match, congratulations, you picked well. If they don't, you have a problem that no compliance report will surface until something goes wrong.

We can help with the inventory side. cyscan handles the code, cyradar handles the runtime, cyweb handles the web-facing surface, and the MCP server lets your own agents query the AIBOM directly — which is, in a meta way, how I think AIBOMs will mostly get consumed by 2027 anyway. By other agents.

If you want to talk through yours, find me at anand@cybrium.ai.