AIBOM: Why AI Needs Its Own Bill of Materials

My friend Bryan Patton — a Principal at Quest Software and someone who’s spent decades in enterprise infrastructure — dropped a term on LinkedIn last week that I haven’t been able to stop thinking about.

AIBOM. AI Bill of Materials.

If you’ve worked in software security, you know what an SBOM is. After Log4Shell ripped through the internet in December 2021, every enterprise buyer, every auditor, every regulator suddenly wanted to know: what’s actually in your software?

SBOMs went from a nice-to-have to a presidential executive order in months. The logic was simple and brutal: you can’t protect what you don’t know you have.

That same logic is about to hit AI. Hard.

---

The Log4J Parallel — And Why It’s Worse for AI

Here’s what happened with Log4J. A single library — buried three, four, five levels deep in dependency trees — turned out to have a critical vulnerability. Organizations scrambled to figure out if they were affected. Most couldn’t answer the question because they’d never inventoried their dependencies with enough granularity.

Now apply that to AI. Instead of one library, you’ve got:

• Multiple AI providers embedded in your codebase (OpenAI, Anthropic, AWS Bedrock, Google Vertex — sometimes all four)
• Model versions that change behavior without warning
• SDK dependencies that pull in their own dependencies
• API calls that route data to third-party infrastructure you’ve never audited
• And increasingly, AI agents that call other AI tools autonomously through protocols like MCP

The difference? Log4J was a dependency. AI providers are data processors. They’re not just running code — they’re ingesting your customers’ data, making decisions, and generating outputs that your customers rely on.

When a buyer’s security team asks “what AI are you running?” — that’s not a compliance question. It’s a data sovereignty question. A liability question. A “do you even know what’s in your own product” question.

Most vendors can’t answer it. Not because they don’t care, but because they’ve never built an AIBOM.

---

What an AIBOM Actually Contains

An SBOM lists your software components. An AIBOM lists your AI components. But the scope is wider than most people think.

A real AIBOM covers:

1. Provider inventory. Every AI service your product calls. Not just the ones you chose deliberately — the ones that came in through dependencies too. We’ve scanned codebases where teams thought they used two AI providers and actually had six, because LiteLLM or LangChain was routing to providers behind the scenes.

2. Model registry. Which specific models you’re calling, which versions, and what data classification applies to each. GPT-4o for summarization is a different risk profile than Claude for customer PII analysis.

3. Data flow mapping. What data goes to each provider, what comes back, and where it’s stored. This is where most governance frameworks (NIST AI RMF, ISO 42001, EU AI Act) focus their control requirements.

4. Dependency chain. The AI SDKs, orchestration libraries, and middleware between your code and the AI provider. This is the lateral traversal problem — a compromised AI dependency can become a supply chain attack vector.

5. Regulatory exposure. Which providers operate under which jurisdiction’s data laws. Which providers are on export control lists. Which providers have GDPR-compliant Data Processing Agreements — and which don’t.

That last point is where things get uncomfortable.

---

The China Problem Nobody’s Talking About

We’ve now scanned enough codebases to see a clear pattern: Chinese AI providers are showing up in Western SaaS products, and nobody’s tracking them.

In one open-source codebase with 326,000 GitHub stars, we found 11 AI providers. Six of them were Chinese — including three on the US Bureau of Industry and Security Entity List. Nobody had inventoried any of them. Nobody had assessed the data sovereignty implications.

Here’s what that means practically:

• Three providers (Zhipu AI, iFlytek, SenseTime) are on the BIS Entity List. Using their APIs may require an export license with a presumption of denial. Most companies don’t even know they’re using them.
• Seven more (Alibaba Qwen, Baidu ERNIE, DeepSeek, Moonshot, MiniMax, Baichuan, 01.AI) operate under China’s AI regulations, which mandate government access to training data and API logs. Zero GDPR or CCPA-compatible Data Processing Agreements exist for any of them.
• None of this shows up in a SOC 2 audit. SOC 2 doesn’t ask what AI providers are in your codebase. It doesn’t check for Entity List violations. It doesn’t flag data sovereignty risks by jurisdiction.

An AIBOM catches all of this. A compliance certificate doesn’t.

---

The Dependency-of-Dependency Problem

Bryan’s AIBOM framing clicks because it captures something frameworks miss: the supply chain depth of AI.

When you install LiteLLM, you don’t just get a library. You get a routing layer that can send data to 100+ AI providers based on configuration. Your engineers might configure it for OpenAI. A test environment might default to something else. A fallback route might send data somewhere you’ve never heard of.

Same story with LangChain, CrewAI, AutoGen, Semantic Kernel. These orchestration frameworks make it trivially easy to add AI providers — and equally easy to lose track of what’s running where.

We built our scanner to catch exactly this. When we scan a codebase, we don’t just look for direct import openai statements. We trace through orchestration layers, check dependency manifests, and flag every provider that could be invoked — whether the team intended it or not.

In one MCP server scan, we found a privileged access management company whose AI integration gave agents direct access to PAM secrets through OpenAI and Azure OpenAI — with no human-in-the-loop controls. The financial exposure estimate: $172K to $2.9M. The company had no AI inventory of any kind.

That’s the AIBOM gap. You can’t govern what you can’t see.

---

Why SBOMs Solved the Wrong Problem (For AI)

SBOMs work because software components are relatively static. You install a package, it has a version, it stays put until you update it. The Bill of Materials is a snapshot that holds true for a while.

AI components are different:

• Models update without notice. When OpenAI rolls a minor update to GPT-4o, your behavior changes and your AIBOM should reflect it — but nothing in your dependency tree actually changed.
• Routing is dynamic. AI orchestration libraries choose providers at runtime based on configuration, load balancing, or even cost optimization. Your Monday AIBOM might be different from your Thursday AIBOM.
• Data sensitivity varies by call. The same API endpoint might process marketing copy one minute and customer health records the next. The risk profile isn’t just “which provider” — it’s “which provider, with which data, under which customer’s contract.”

This is why static SBOMs — even good ones — don’t cover AI governance. You need something that understands the AI-specific risks: provider jurisdiction, data classification per call, regulatory framework mapping, Entity List screening.

That’s an AIBOM. And right now, almost nobody has one.

---

What Enterprise Buyers Are Starting to Ask

The questionnaire landscape is shifting fast. Eighteen months ago, AI questions were an afterthought in security reviews. Now I’m seeing dedicated AI sections with 10-15 questions — and the questions are getting specific:

• “Provide a complete inventory of AI models deployed in your product, including provider, version, and data classification.”
• “Which AI providers process customer data? What are their data residency commitments?”
• “Do any of your AI providers or their subprocessors operate under foreign data sovereignty laws?”
• “How do you detect and inventory AI components introduced through third-party dependencies?”

These are AIBOM questions. The buyers might not use the term yet — but they’re asking for the artifact.

The vendors who can answer with evidence win the deal. The vendors who say “let me get back to you” lose the deal. It’s that simple.

---

Building Your AIBOM (The Practical Path)

Here’s the good news: you don’t need a six-month compliance project to build an AIBOM. You need a codebase scan.

A proper AIBOM scan covers:

1. AI SDK detection — find every import, API call, and provider reference in your codebase. Not just the obvious ones — the ones buried in dependencies and orchestration layers.
2. Model identification — map which specific models are being invoked, at which versions, for which purposes.
3. Risk assessment — flag data privacy gaps, missing DPAs, Entity List violations, agentic AI without human oversight.
4. Framework mapping — connect findings to the frameworks your buyers care about: NIST AI RMF, ISO 42001, EU AI Act.
5. Evidence packaging — produce an artifact your security team can hand to a buyer. Not a policy document — evidence from your actual codebase.

This is exactly what a Trust Pack delivers. We scan your repos, detect every AI provider and model, map risks to frameworks, and produce a buyer-ready AIBOM plus a Response Kit that pre-answers the 27 most common enterprise AI due diligence questions.

Customer-ready results in minutes. Not months of consulting. Not a policy document disconnected from your actual code.

The SBOM revolution taught us one lesson: inventory comes before governance. You can’t manage risk in systems you haven’t mapped.

AI’s SBOM moment is here. The companies that build their AIBOM now will own the trust advantage. The ones that wait will spend six figures scrambling when the questionnaire lands.

Bryan’s right. You need an AIBOM. And you need it before your next enterprise buyer asks for one.

---

Want to know what’s actually in your codebase? Book a 20-minute scoping call and we’ll show you what an AIBOM reveals.