What is an AIBOM? AI bill of materials explained for security teams

TL;DR - An AIBOM is a machine-readable inventory of models, datasets, dependencies, AI services, agents, and tools, plus evidence of origin, rights, integrity, and evaluation. - It extends an SBOM rather than replacing it. CycloneDX and SPDX both support AI components, so many teams extend their existing SBOM pipeline. - Mark unknowable fields, like hosted API hashes or partial training data lineage, as unknown. Blank fields make an inventory look complete when it isn't. - Much everyday risk isn't malicious: unpinned models, deprecated versions, licenses that forbid commercial use, and fine-tunes with no recorded base model. - The EU AI Act and ISO/IEC 42001 don't require an AIBOM by name, but it helps assemble the component and data evidence they expect. - An AIBOM can't prove a model is safe, capture runtime behavior, or record AI coding agent actions. Those need evaluation, runtime monitoring, and agent audit logs. An AI bill of materials (AIBOM) is a structured, machine-readable inventory of the components in an AI system: models, datasets, software dependencies, AI services, agents, and tools. It also records evidence of each component's origin, rights, integrity, and evaluation. The OWASP AIBOM project uses this framing. It describes an inventory of AI components such as models, datasets, agents, tools, guardrails, and runtime elements, plus evidence of where they came from and what you're allowed to do with them. If you already produce SBOMs, the idea will feel familiar. An AIBOM is an SBOM extended to cover the parts of an AI system that a package manifest misses. You'll also see it called an AI SBOM, SBOM for AI, or ML-BOM. These are overlapping names for the same idea. Security, engineering, and governance teams use an AIBOM to answer one basic question: what AI is in this system, and where did it come from? What an AIBOM contains An AIBOM covers six broad categories. Each one maps to a question someone will eventually ask you. - Models and provenance. Model name, version or commit, provider or publisher, file hashes, license, source registry, and any fine-tuning lineage. This answers "which model is this, exactly?" - Datasets. References to data used for training, fine-tuning, and evaluation, including source, license, and known gaps in lineage. This answers "what shaped this model's behavior?" - Software and ML dependencies. Frameworks, tokenizers, inference runtimes, serving libraries, and container images. This is the overlap with a traditional SBOM. - AI services and infrastructure. External model APIs, vector databases, and inference endpoints your application calls. - Agents, tools, and MCP servers. The agents in the system and the tools they can invoke, including Model Context Protocol (MCP) servers and their versions. - Security and governance metadata. Owner, approval status, risk scores, evaluation results, intended use, and known limitations. A worked example: an internal support assistant Here's a realistic application and what its AIBOM entries might look like. The app is an internal support assistant. It answers employee questions using company docs and opens tickets when needed. It uses: - An open-weight chat model pulled from Hugging Face and fine-tuned on internal support tickets - An open source embedding model for retrieval - A self-hosted vector database - A hosted LLM API as a fallback for complex queries - One MCP server that lets the assistant create and look up tickets Two of those rows are hard to fill in. The hosted LLM API has no hash. You can't fingerprint weights you never download, and the provider can update the model behind an identifier. Record the exact model identifier, the date you verified it, and the contract terms. Mark the hash field as unknown rather than leaving it blank. Dataset lineage for the base model is partial. Many publishers describe their training data in general terms only. Record what the model card states and flag the gap. An AIBOM that says "unknown" is honest and useful. An AIBOM that leaves fields blank looks complete when it isn't. Here's a trimmed CycloneDX-style entry for the fine-tuned model. Treat it as illustrative and validate it against the current CycloneDX schema before you use it. { "type": "machine-learning-model", "bom-ref": "support-assistant-ft@1.4.0", "name": "support-assistant-ft", "version": "1.4.0", "hashes": [ { "alg": "SHA-256", "content": "" } ], "licenses": [ { "license": { "id": "Apache-2.0" } } ], "pedigree": { "ancestors": [ { "type": "machine-learning-model", "name": "mistralai/Mistral-7B-Instruct-v0.3", "purl": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3@" } ] }, "modelCard": { "modelParameters": { "task": "text-generation", "datasets": [ { "ref": "support-tickets-2025Q3" } ] } } } The pedigree block links the fine-tuned model to its base. That link is what lets you answer "are we affected?" if the base model turns out to have a problem. AIBOM vs. SBOM An AIBOM extends and complements an SBOM. It doesn't replace it. A production AI application still ships libraries, containers, and runtimes, and your SBOM still covers those. If you need a refresher on the software side, our practical guide to software bills of materials covers the fundamentals. Most production AI applications need both, and they work better linked. A single export that covers your npm packages and your fine-tuned model saves your incident responders from cross-referencing two documents at 2 a.m. CycloneDX and SPDX both support AI components within the same document family, which is why many teams extend their existing SBOM pipeline instead of starting a separate one. Why AIBOMs matter now Answering "are we affected?" When a model publisher discloses a problem, or a popular ML library ships a vulnerable release, the first question is always the same: are we affected, and where? Without an inventory, the answer takes days of Slack threads and grep. With an AIBOM, it's a query against data you already have. The same inventory supports license compliance, provenance checks, incident response, and audit evidence. Inventories drift faster than you think AI and ML teams pull models from Hugging Face and other open registries all the time, often without consistent vetting or provenance tracking. A spreadsheet inventory drifts the moment a developer pulls a new model into a notebook that later becomes a service. Shadow AI features show up the same way: a quick prototype ships, and nobody updates the list. Most risk isn't obviously malicious Are most AI supply chain incidents caused by obviously malicious components? We haven't found credible aggregate data that answers that with a number, so here's the qualitative picture. Malicious models do exist. Some model serialization formats, such as Python's pickle, can execute arbitrary code when a model loads. That's a real, documented mechanism, and it's why safer formats like safetensors exist. But plenty of everyday risk comes from components nobody intended to be harmful: - A model pulled without pinning, so the weights silently change - A deprecated model version still running in production - A model whose license forbids commercial use, shipped in a commercial product - A dataset with unclear lineage, which makes it hard to answer a customer's data questions - A fine-tune whose base model nobody recorded This is why provenance and license fields matter as much as malware checks. Most of the value of an AIBOM is ordinary hygiene, done consistently. Regulation and standards expect traceability The EU AI Act requires technical documentation from providers of high-risk AI systems (Annex IV) and from providers of general-purpose AI models. That documentation covers items such as system components, data, and development process. The Act doesn't require an "AIBOM" by name. An AIBOM is a practical way to assemble and maintain much of the component and data information the Act asks for. ISO/IEC 42001 asks organizations to establish and maintain an AI management system and to show it works. Knowing which AI assets you have, across their lifecycle, with traceable evidence over time, is a practical precondition. Check the standard's control language for your own scope. ISO/IEC 42001 doesn't name an AIBOM either. For a deeper technical treatment, NIST's Computer Security Resource Center hosts the 2024 presentation Securing AI Ecosystems: The Critical Role of AI Bills of Materials (AIBOM) in Mitigating Software Supply Chain Risks, a useful reference for teams building a program. If you're working on the wider risk program the AIBOM feeds into, our guide to managing AI risks covers assessment through implementation. AIBOM standards and frameworks Readers often treat these as interchangeable. They aren't. Two are formats, two are community efforts from OWASP (one of them a tool), and one is government guidance. CycloneDX ML-BOM. CycloneDX's ML-BOM capability adds machine-readable descriptions of models, datasets, configurations, and their dependencies. It introduced a machine-learning-model component type and model card support in version 1.5. If you search "CycloneDX AI BOM," this is what you're looking for. SPDX 3.x AI and Dataset profiles. SPDX 3.0 introduced profiles for AI packages and datasets. Teams already on SPDX can represent AI components without switching formats. Check the profile pages for exact field names before you map your data. OWASP AIBOM project and AIBOM Generator. The OWASP AIBOM project maintains a community definition and guidance for what an AIBOM should contain. Separately, the OWASP AIBOM Generator, run under the OWASP GenAI Security Project, is an open-source tool that produces a CycloneDX AIBOM for a Hugging Face model and scores how complete it is. It's a low-effort way to see what a real AIBOM looks like for a model you already use. CISA and G7 guidance. In May 2026, CISA and its G7 partners (Canada, France, Germany, Italy, Japan, the United Kingdom, and the European Union) released joint guidance, Software Bill of Materials for AI: Minimum Elements. It groups AI SBOM information into seven clusters: metadata, system-level properties, models, dataset properties, infrastructure, security properties, and key performance indicators. The guidance is voluntary and is meant to sit on top of CISA's general SBOM minimum elements, not replace them. Treat it as a baseline, not a mandate. One caveat applies to all of these: there's no single universally adopted AIBOM schema yet. Standards are still evolving. Choose based on the tooling you already run and the parties you need to share data with. If your customers ask for CycloneDX, use CycloneDX. Architecting security into the agentic SDLC How to build and maintain an AIBOM You don't need a new program. If you already run dependency scanning and SBOM export, you have most of the plumbing. AI models are dependencies. The habits you use for open source packages (discovery, version pinning, policy, SBOM export) carry over to models directly, which is how Endor Labs approaches it: govern open source AI models like any other dependency. Here's a tool-agnostic sequence a team can start this quarter. - Inventory AI assets. Scan code and configs for model loads, API clients, embedding calls, vector database clients, and MCP server configs. Include shadow AI features: prototypes that quietly made it to production count. Our walkthrough on discovering open source AI models shows one way to find Hugging Face models in your code. - Capture provenance and versions. Pin models to a commit or digest. Record hashes, source registry, license, base model for fine-tunes, and dataset references. Mark unknowable fields as unknown. - Generate a machine-readable file. Emit CycloneDX or SPDX, whichever your existing SBOM pipeline uses. Link or merge it with the application SBOM. - Connect it to existing tooling. Feed the AIBOM into your software composition analysis, SBOM management, and model registry workflows so it lives where your team already works. If you're still shaping that program, these key questions for your SBOM program apply to AI components too. - Regenerate automatically. AIBOMs built by hand go stale fast. Regenerate in CI/CD and ML pipelines whenever a model is downloaded, fine-tuned, promoted, or replaced. The timing questions from comparing SBOMs across lifecycle stages matter here: an AIBOM from training time and one from deployment can differ. - Monitor and enforce policy. Define which models, licenses, and sources are acceptable. Check new entries against that policy before they ship. Our guide to AI model governance covers how to set and enforce those rules. What does good look like? A useful inventory is continuously updated and attaches version and provenance to every AI model and component. It scores each asset for vulnerability, deprecation, and license risk before it ships. It includes AI components in your SBOMs, so the inventory is auditable and exportable on demand. Here's a practical test. If an auditor or customer asks for your AI inventory tomorrow, can you export it in minutes? Or does someone spend a week rebuilding a spreadsheet? Where AIBOMs fit in the agentic development lifecycle An AIBOM improves traceability. It's also worth being clear about what it can't tell you. - It doesn't prove a model is safe. Knowing a model's version and source says nothing about how it behaves on your inputs. - It doesn't prove a model is unbiased or vulnerability-free. Evaluation results can be recorded in an AIBOM, but the AIBOM isn't the evaluation. - It doesn't capture runtime behavior. Prompt injection, data leakage, and unexpected outputs happen at runtime, not in a manifest. - It doesn't record what AI coding agents do. An AIBOM can list the agents, models, and MCP servers in use. It can't tell you which shell commands an agent ran, which files it read, which MCP tools it called, or which packages it installed. Each gap needs a complementary control. Model evaluation and red teaming cover safety and bias. Static analysis for issues like those in the OWASP Top 10 for LLM Applications covers risky code patterns. Runtime monitoring covers live behavior. Agent activity is a separate evidence stream entirely. The AIBOM says which models and tools are present. Governing AI coding agents needs an audit log of the actions they take, plus deterministic policy that blocks destructive commands, sensitive file access, or unapproved MCP servers regardless of what the model decides. This is how we think about the secure agentic development lifecycle (ADLC) at Endor Labs. Inventory is one layer. Agent governance, code analysis, and supply chain controls are others. An SBOM, as we've argued before, is a means to an end, and the same is true of an AIBOM. Its value comes from the decisions it makes possible. For the full picture, read our explainer on the secure agentic development lifecycle (ADLC), then our guide to AI coding agent governance for the agent-actions side. FAQs Is an AIBOM the same as the AI Bill of Rights? No. The Blueprint for an AI Bill of Rights is a US policy framework that sets out principles for automated systems. An AIBOM is a technical inventory of the components in an AI system. Searches for "AI bill" sometimes mix the two up. Is an AIBOM legally required? Not by that name in the frameworks covered here. The EU AI Act requires technical documentation for high-risk AI systems and general-purpose AI models, ISO/IEC 42001 expects evidence that your AI management system works, and the CISA and G7 guidance on SBOM for AI is voluntary. An AIBOM is a practical way to produce much of the component and data information those frameworks ask for. Check with your legal and compliance teams for your specific obligations. Do I need a separate AIBOM if I already produce SBOMs? You need the AI-specific information, but it doesn't have to live in a separate file. CycloneDX and SPDX both support AI components, so many teams extend their existing SBOM pipeline. What matters is that model versions, datasets, lineage, and model licensing are captured and linked to the software SBOM. Can I generate an AIBOM for a model I pull from Hugging Face? Yes. The OWASP AIBOM Generator, part of the OWASP GenAI Security Project, can produce an AIBOM for a Hugging Face model and shows a completeness score for which fields are filled in. Expect gaps, especially around training data lineage. Record those gaps as unknown, then build automated generation into your pipeline so the AIBOM stays current as models change. What's next? When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: