What Is an AI Bill of Materials (AI BOM)? A Complete Guide

When people think about any AI applications, they only talk about a large language model like GPT-4, Claude, or Llama generating responses to user prompts. The model is actually just a small part of what they are seeing. There is much more inside an AI system. This shows the importance of an AI Bill of Materials (AI BOM) to understand what’s inside your AI system. 

IBM’s 2025 Cost of a Data Breach Report reveals that 13% of organisations have already suffered security incidents involving AI models or applications, while another 8% were not able to assess if their AI systems were compromised. Modern AI programs rely on several interconnected elements like foundation models, machine data, vector databases, external APIs, orchestration frameworks, and third-party services. If you can’t see these dependencies, you can’t solve the problem that happens inside, which can cause security, governance, and operational issues.

In this article, you are going to understand the concept of an AI Bill of Materials (AI BOM), its growing significance, the information it should include, and how it can help in the security, governance, and risk management of AI initiatives.

Key Takeaways

• AI BOM is an extension of SBOM to track AI assets like models, datasets, vector databases, prompts, and AI agent tools.
• The CycloneDX 1.6 and SPDX 3.0 standards provide machine-readable AI BOMs for automated governance, compliance, and security workflows.
• A complete AI BOM documents model metadata, data provenance, software dependencies, runtime infrastructure, and third-party AI services.
• AI BOM makes it easier to see who uses AI products and their associated risks, such as malicious models, prompt injection, shadow AI, and vulnerable dependencies.
• To ensure that AI BOM remains relevant and accurate, it must be continuously updated using MLOps and CI/CD pipelines, incorporating updates to AI models, data, and runtime environments. 

What Is An AI Bill of Materials (AI BOM)?

The AI Bill of Materials (AI BOM) is a machine-readable, structured list that includes each technical artifact, data asset, model parameter, and dependency on third parties needed to develop, optimise, deploy, and run an AI system. It serves as a foundational component of AI security by providing complete visibility into the AI supply chain.

It acts as an auditable supply chain manifest that tracks assets from training data provenance and weight checksums down to inference runtime engines and function-calling permissions.

Traditional software management systems used to handle only the existence of a binary dependency, or third-party open-source software packages. An AI BOM captures the multi-dimensional nature of AI. It helps to understand:

• Which model checkpoint variant is currently running in production
• What training, validation, and retrieval data was used, and what licensing constraints apply to it
• Which vector indexes and embedding models are being used in the RAG pipeline
• Which external API endpoints and system-level permissions have been granted to autonomous agentic tools
• What are the cryptographically verifiable hashes of the model weights currently running on the GPU clusters

An AI BOM is not a PDF or documentation page; it’s a programmatic asset that’s embedded in security operations, risk management, incident response, and continuous compliance automation.

What Is The Difference Between an AI BOM and an SBOM?

The difference between an AI BOM and an SBOM lies in the fact that the AI BOM provides detailed information about the AI-related dependencies apart from the software ones, like the models, data sets, vector databases, external AI services, and governance details. While an SBOM is all about the software supply chain, an AI BOM gives the whole picture of the AI world.

What Components Every AI BOM Must Have? 

AI BOM should document the core components that make an AI system work, including its data sources, model artifacts, application dependencies, runtime environment, and third-party integrations. Together, these components provide a complete inventory of the AI supply chain, making it easier to identify security risks, verify provenance, support compliance, and investigate incidents. It includes:

• Layer 1: Raw & Synthetic Data Sources
• Layer 2: Foundation & Fine-Tuned Models
• Layer 3: Orchestration & Middleware Frameworks
• Layer 4: Vector Storage & Embedding Engines
• Layer 5: Runtime Inference Servers
• Layer 6: Agentic Tools & External APIs

Layer 1: Data Sources & Provenance

It should contain components like Raw web crawls, proprietary enterprise document stores, synthetic datasets, fine-tuning pairs (RLHF/DPO), and validation subsets.

These help to find vulnerabilities like Data poisoning, Training set copyright infringement, Improper inclusion of PII, and unauthorised data retention.

Layer 2: Foundation & Fine-Tuned Models

The components include Open-weight base models like Llama 3 and Mistral, Closed-Source commercial API, such as OpenAI and Anthropic, fine-tuned LoRA adapters, and quantised weights (GGUF, EXL2, AWQ).

It addresses risks like supply chain attacks through malicious model serialisation formats, backdoor triggers embedded in weights, and licensing breaches.

Layer 3: Orchestration & Middleware Frameworks layer

Components include: AI BOM frameworks like LangChain, LlamaIndex, Semantic Kernel, Haystack; prompt management tools. It demonstrates risks like Indirect prompt injection, broken access control between user sessions and system prompts, and unverifiable library dependencies.

Layer 4: Vector Storage & Embedding Engines

It includes Vector databases like Pinecone, Qdrant, Milvus, and pgvector, and embedding models. It identifies risks like retrieval manipulation, cross-tenant data leakage within vector Indexes, and embedding storage without encryption.

Layer 5: Runtime Inference Servers

It includes Inference engines such as vLLM, TGI, Ollama, Triton Inference Server, and underlying hardware runtimes, which are CUDA, ROCm, and TensorRT. This layer identifies risks like Denial of Service (DoS) caused by long context window exhaustion, GPU memory corruption, and unpatched runtime container dependencies.

Layer 6: Agentic Tools & External APIs

It contains Autonomous AI agents, Web search APIs, SQL database connectors, CRM plugins, and custom OpenAPI specs. It identifies operational risks, which are: SSRF (Server-Side Request Forgery) through agent web scraping and excessive permissions for execution scripts.

Need Help Choosing the Right AI Cybersecurity Partner?

Compare security providers with confidence and identify the right partner to protect your applications, cloud, APIs, and AI systems before threats become breaches.

Schedule a Security Assessment
→

Machine-Readable AI BOM Standards: CycloneDX vs. SPDX

An AI BOM is most useful when security tools can read and process it automatically. AI supply chain information is shared consistently between CI/CD pipelines, asset management platforms, vulnerability scanners, and compliance tools by leveraging machine-readable standards instead of manually building AI inventories.

There are currently two prominent open standards for generating machine-readable AI BOMs: OWASP CycloneDX and Linux Foundation SPDX. Although both document AI components, they are designed for slightly different purposes.

1. OWASP CycloneDX (v1.6+)

CycloneDX is all about security and software supply chain visibility. With the help of version 1.6, organisations can structure their documentation with support for dedicated Machine Learning and AI components, enabling them to document models, datasets, dependencies, and runtime information.

A CycloneDX AI BOM can capture information like:

• Model architecture
• Model checkpoint hashes
• Training and fine-tuning datasets
• Identify inputs and outputs in models
• Hyperparameters
• Licensing information
• Runtime dependencies 

The machine-readable format simplifies the automation of security tools to inventory, validate model integrity, identify unauthorised changes, and enable ongoing security monitoring.

Example: CycloneDX v1.6 AI BOM (JSON)

JSON 
{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-31T10:00:00Z",
    "component": {
      "type": "application",
      "name": "enterprise-rag-assistant",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-llama3-8b-custom",
      "name": "Llama-3-8B-Instruct-Finance-Quantised",
      "version": "1.2.0",
      "description": "Fine-tuned financial analysis model quantised to INT4 AWQ",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
        }
      ],
      "modelRequirements": {
        "architecture": "Transformer",
        "parameters": "8B",
        "inputs": [
          {
            "format": "text/plain"
          }
        ],
        "outputs": [
          {
            "format": "application/json"
          }
        ]
      },
      "grant": {
        "type": "license",
        "licenses": [
          {
            "license": {
              "id": "Llama-3-Community"
            }
          }
        ]
      }
    },
    {
      "type": "data",
      "bom-ref": "dataset-financial-qa",
      "name": "proprietary-financial-qa-v2",
      "version": "2.1.0",
      "description": "Financial question-answering dataset",
      "data": {
        "type": "dataset",
        "governance": {
          "owners": [
            {
              "organisation": "Enterprise AI Security Team"
            }
          ]
        }
      }
    }
  ]
}

2. SPDX 3.0 (System Software Package Data Exchange)

SPDX 3.0 adopted a profile-based architecture with specific AI and Dataset profiles. It is good at documenting compliance profiles, data licensing terms, and complex component relationship graphs like Model-A was compiled on Dataset-B, using Environment-C.

OWASP CycloneDX 1.6+ Vs. SPDX 3.0

Before AI BOM became the preferred term, many organizations used Machine Learning Bill of Materials (ML-BOM) to document machine learning models, datasets, and supporting infrastructure. Today, AI BOM extends this concept to include generative AI, RAG pipelines, agentic systems, and external AI services, giving organizations the visibility needed to improve AI and LLM security across the entire AI supply chain.

What Information Should Be Included In An AI BOM? 

AI BOM should include attributes in six major domain types that provide security scanners and governance engines with complete visibility.

1. Model Artifact Metadata

• Model Name & Version: The unique model name and version used in production.
• Weight Cryptographic Hash: The SHA-256 hash of the model file (such as .safetensors, .bin, or .gguf) used to verify that the model has not been modified or tampered with.
• Quantisation & Format: The model’s precision format (FP16, INT8, INT4 AWQ, GGUF), which affects performance, memory usage, and accuracy.
• Licensing & Usage Restrictions: The conditions and terms of the license imposed by the model provider. 

2. Dataset Provenance

• Data Sources & Origins: Where the training, fine-tuning (SFT), or RAG datasets came from, including storage locations or lineage records.
• PII & Privacy Scrubbing Logs: Logs that indicate if personally identifiable information (PII) was removed or anonymised using Presidio before training.
• Rights & Consent Metadata: Documentation that specifies that the dataset has been used legally, such as its copyright, and that it meets data privacy requirements. 

3. Software Dependencies and Runtime Infrastructure

• AI Frameworks/Libraries: AI frameworks and libraries like LangChain, Transformers, vLLM, Torch, and Triton used in the application.
• Hardware Drivers & Compute Stack: Runtime information like CUDA version, ROCm drivers, GPU instance types, and container images.
• Model Servers: The inference engine configuration, including parameters such as context length and runtime settings.

4. Vector Database & RAG Architecture

• Vector Store Specifications: Vector database, Indexing algorithm (HNSW, IVF-PQ), and Similarity Measure (cosine, dot product).
• Embedding Model: Model and version of the vector index.Embedding Model Version: Version of the vector index.
• Chunking Strategies: The way documents should be broken up into chunks before indexing. 

5. API & Dynamic Agent Tools

• Plugin & Tool Schemas: The OpenAPI definitions of external tools and services available to autonomous agents.
• Authentication Scopes: The API keys, OAuth scopes, and system permissions granted to these AI BOM tools.
• Sandbox Environment Specs: The isolation mechanisms (such as gVisor, Docker, or WebAssembly) used when agents execute code.

6. Governance & Risk Metadata

• Ownership & Accountability: The teams or individuals responsible for maintaining, securing, and operating the AI system.
• Known Risk Profiles & Guardrails: Documented security controls, prompt guardrails, safety classifiers like Llama Guard, and red-teaming assessment results.

What AI Security Risks Does An AI BOM Tackle?

AI systems introduce risks that are not typically found in conventional software systems. 

1. Model Supply Chain Attacks & Malicious Weights

Risk: Attackers post unsafe model weights on open model repositories like Hugging Face with embedded Python code or backdoored model weights in unsafe serialisation formats such as PyTorch .bin or pickle.

Solution: An AI BOM records all the weight files in the model and uses a safer serialisation format. In case an unverified or modified weight file is inserted into production, the AI BOM scanner will not let SecOps teams remain unaware of it for long.

2. Vulnerabilities of the Supply Chains

Risk: Machine learning frameworks are built with thousands of Python packages that are open-source. The malicious packages uploaded to PyPI exploit MLOps pipelines to steal API keys or to infiltrate cloud compute instances.

Solution: An AI BOM enables vulnerability management platforms to cross-reference dependencies against databases such as NVD or GitHub Advisory to discover CVEs in real-time when each Python package is mapped through a Package URL (purl).

3. Indirect Prompt Injection & RAG Exploitation

Risk: Malicious actors can put malicious instructions in documents added to the vector database in the RAG systems. These instructions are then retrieved and used with the LLM’s system prompt to retrieve information from the enterprise.

Solution: An AI BOM captures all the components of the RAG pipeline, like data ingestion endpoints, embedding models, vector store indexes, and chunking strategies. The security team can track data lineage, detect untrusted data sources, and be able to locate compromised indexes in a matter of seconds.

4. Excessive Agency & Dynamic Tool Hijacking

Risk: Prompt injection could cause problems such as dropping a database table, deleting a cloud storage bucket, or exfiltrating an email by autonomous agents with dynamic tool-calling capabilities.

Solution: Automated AI BOM analysis tools identify unauthorized or excessive permissions across agent tools, enabling the continuous enforcement of least-privilege principles.

5. Shadow AI Discovery & Regulatory Compliance

Risk: Engineering teams regularly use unapproved open-source models, third-party API keys, or cloud inference services that are not centrally managed under security and compliance guidelines, resulting in unauthorised access to data and non-compliance.

Solution: Continuous AI BOM discovery scans container registries, code repositories, and runtime clusters to identify undocumented AI components, bringing shadow AI assets under centralised governance.

How Organisations Can Build an AI BOM?

Organisations can simply follow some basic steps to create AI BOM tools. Which include:

Step 1: Extract Model Metadata at Training Time (MLOps Integration)

Embed metadata extraction directly into model training scripts or MLOps platforms like MLflow, Hugging Face Hub, and Weights Biases.

Step 2: Automated Package Scanning in CI/CD (Build Time)

Use open-source command-line tools in your GitHub Actions, GitLab CI, or Jenkins pipelines to create software dependency graphs for your AI application runtime.

Step 3: Combine Static and Dynamic Runtime BOMs

To demonstrate the power of modern AI systems using dynamic component loading, you might consider implementing features like agents fetching tool schemas dynamically during runtime, or RAG pipelines switching vector databases based on query intent.

• Static AI BOM (Build Time): Captures static code dependencies, base model binaries, container base images, and infrastructure code.
• Dynamic AI BOM (Runtime): Captured by runtime observability agents or sidecars. It continuously updates the active registry with running inference endpoint URLs, dynamic API tool registrations, live vector index schemas, and active system prompt.

Step 4: Validate and Enforce at Gateways

Integrate AI BOMs with Open Policy Agent (OPA) or Kyverno admission controllers in Kubernetes clusters. Block deployment if:

• The model weight hash is not equal to the signed release manifest
• Unsafe model formats are detected, such as raw .pkl files
• Third-party models include non-compliant licenses

Want To See Real Security Improvements

Gain a comprehensive roadmap for securing your systems with the guidance of our expert cybersecurity professionals.

Download Case Study
⤓

How To Overcome The Technical Challenges?

There are several technical operational challenges happens when deploying an AI BOM strategy at the enterprise level:

1. Dynamic Agentic Complexity

Challenge: Autonomous multi-agent systems generate and execute code or invoke tools dynamically on the fly, rendering static build-time inventories obsolete within seconds.

Solution: Runtime API security gateways that capture and log agent tool registration schemas, and runtime updating of the active runtime AI BOM using live observability metrics.

2. Significant Model Memory Usage

Problem: When the automated CI/CD build pipelines need to calculate cryptographic SHA-256 hashes for large 70B+ parameter model files (greater than 140GB), it can result in significant latency.

Solution: Use chunked parallel hashing or hash each header or layer metadata file.

3. Universal Tooling Standards

Challenge: CycloneDX 1.6 and SPDX 3.0 offer a basic schema, but open-source scanners are still in their developmental stages to capture ML-specific parameters natively.

Solution: Develop modular MLOps wrapper scripts to gather model, dataset, and vector DB metadata from training/export, and auto-format these to standard CycloneDX 1.6 JSON components.

4. Shadow AI & Proprietary API Vendor Opacity

Challenge: Closed-source API providers frequently update underlying model weights behind static endpoints without public notice, breaking static governance tracking.

Solution: Document API endpoint URIs, snapshot timestamps, system prompt hashes, and response schema specs inside the AI BOM to monitor behavioral changes over time.

Common AI BOM Pitfalls To Avoid

Organisations need to avoid some basic mistakes and follow AI BOM best practices to strengthen AI governance and supply chain security. Even a small gap in the documentation can create a large number of vulnerabilities. The basic mistakes organisations make include:

• Considering the AI Bill of Materials (AI BOM)  as a static file.
• Writing down just the names of models but not their lineage.
• Disregarding the source of datasets and any licenses required.
• Not including RAG features such as embeddings and vector databases.
• Overlooking runtime environment and inference setup.
• Failing to track third-party AI tools and APIs.
• Depending on manual updates instead of CI/CD pipelines.
• Omitting periodic checks, thus ending up with an outdated AI BOM.

What Does Qualysec’s AI BOM Report Cover?

Qualysec’s AI BOM report is a systematic way of discovering, documenting, and evaluating the parts of an AI application. Our report does not just provide a list of AI components, but rather illustrates the entire AI supply chain, including the relationships and sources of these components and the risks they could cause. 

We do an assessment, which follows  AI BOM framework guidance to strengthen AI application security, improve AI transparency, supply chain visibility, and governance while helping organisations maintain a clear record of their AI ecosystem.

Step 1 – Identify And Review AI Assets And Standards

In the first step, we determine all the assets that are part of the AI application. These include AI models, datasets, embeddings, vector databases, AI frameworks, APIs, inference engines, and third-party libraries. Additionally, we review the existing SBOM standards (CycloneDX 1.6 and SPDX 3.0) to gain an understanding of how SBOM-specific information can be documented and what additional SBOM-specific metadata might be needed.

Step 2: Collecting Metadata and Provenance

After the assets are identified, we provide a report for detailed metadata of each asset. This includes model versions, cryptographic hashes, publishers, licences, source repositories, dataset provenance, dataset versioning, model lineage, and fine-tuning parameters. The ability to gather this information enhances the traceability of AI models and datasets, and serves to keep a history of their development.

Step 3: Map AI Dependencies

The next step involves establishing the connections between AI models, datasets, APIs, embeddings, vector databases, frameworks, and supporting libraries. It is a dependency mapping that helps your organisation to understand where to place trust boundaries, what the critical dependencies are, and how changes in the components affect the AI supply chain.

Step 4: Assess Supply Chain Risks

The AI ecosystem is then examined, looking for security and governance concerns. The assessment identifies outdated models, unsupported libraries, vulnerable dependencies, licensing issues, data integrity problems, and more potential risks that could impact the security, reliability, or compliance of AI applications.

Step 5: The AI BOM Report Generation

At the end, the collected information is organised into a machine-readable AI BOM using OWASP AIBOM Generator and Snyk AI-BOM. The final report includes a structured record of AI assets, metadata, AI dependencies, the provenance history, and identified risks, which helps in compliance, security assessments, and ongoing AI supply chain management. 

The team should update the AI BOM to ensure accurate visibility throughout the AI lifecycle, as AI models, datasets, and dependencies evolve over time.

Conclusion

AI systems have become very complex and interconnected, which means that there needs to be more visibility in terms of how everything depends on each other. AI Bill of Materials (AI BOM) enables an organisation to have a clear idea about the various models, data sets, tools, and services that form part of their AI system. Even though AI BOM is evolving, it is gradually being seen as a very significant tool in AI governance and security.

Gain complete visibility into your AI systems with AI BOM and AI/ML Penetration Testing. Schedule a Free Consultation with Our AI Security Experts.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Frequently Asked Questions

1. What is the purpose of an AI Bill of Materials?

The purpose of an AI BOM is to provide knowledge on what components are used while implementing an AI system. It helps organisations to understand the systems and prevent future risk.

2. What is an AI Bill of Materials?

An AI Bill of Materials is a document containing a detailed inventory of the models, data sets, software elements, infrastructure, APIs, and other third-party services involved in the AI solution.

3. Who needs an AI BOM?

AI BOM can be helpful for organisations that either develop, implement, or work with AI solutions. Such organisations include businesses utilising generative AI solutions, organisations conducting security assessments, those dealing with governance, and third-party AI vendors for evaluation.

4. How often should an AI BOM be updated?

The team must update the AI BOM in case of any significant changes such as the update of models, addition of integrations, new data sets, changes in infrastructure, or agent capabilities.

5. Can an AI BOM prevent attacks?

AI BOM can’t directly protect against cyberattacks but can increase visibility of AI dependencies, security assessment, incident response, and other processes.

6. What is the future of AI BOM?

In the future, AI BOM is expected to play a larger role in AI governance, supply chain transparency, and security management. Future AI ecosystems may rely heavily on structured documentation to maintain trust and accountability.