AI Bill of Materials (AIBOM): Enterprise Guide 2026

In March 2024, Oligo Security researchers found that thousands of enterprise AI servers running the Ray framework had been compromised for at least seven months. The attackers had stolen Hugging Face tokens, cloud credentials, and GPU compute. The entry point was not a zero-day exploit: it was unauthorized AI components running in production with no inventory, no access controls, and no detection. The AI Bill of Materials (AIBOM) is the governance discipline that would have stopped this before it started.

This guide explains what an AIBOM is, what it must contain, how it maps to EU AI Act and NIST AI RMF requirements, and how to build an AIBOM program from the ground up. If your organization runs AI in production, this is no longer optional planning: EU AI Act Article 13 enforcement begins 2 August 2026.

---

Why AI Supply Chains Are Actively Under Attack

The assumption that AI supply chain risk is theoretical ended in 2024 and accelerated through 2025 and 2026.

ShadowRay (CVE-2023-48022): Ray's Jobs API had no authorization on port 8265, allowing unauthenticated HTTP callers to execute arbitrary jobs. Attackers exploited this for at least seven months before discovery, stealing Hugging Face tokens, AWS credentials, and GPU compute from production AI workloads. In November 2025, a follow-on campaign called ShadowRay 2.0 built a self-propagating GPU cryptomining botnet across more than 200,000 still-exposed Ray servers.

nullifAI (February 2025): ReversingLabs discovered two Hugging Face models containing functional reverse shells that evaded Picklescan entirely. The attack exploited a parser gap: compressed PyTorch files using 7-zip format caused torch.load() to fail while the malicious payload executed first. The reverse shell connected to a hardcoded IP and was platform-aware, running on both Windows and Linux. This maps to MITRE ATLAS AML.T0010: AI Supply Chain Compromise.

Scale: JFrog's 2025 Software Supply Chain Report recorded a 6.5x increase in malicious models on Hugging Face compared to the prior year. Protect AI, after scanning 4.47 million model versions in partnership with Hugging Face, found 352,000 unsafe or suspicious issues across 51,700 models.

Against this backdrop, only 19% of organizations have full visibility into where and how AI is used across their development environment, per Cycode's 2026 State of Product Security Report. Shadow AI tool usage increased 156% from 2023 to 2025.

An AIBOM is the inventory discipline that closes this visibility gap before attackers exploit it.

---

What Is an AI Bill of Materials: AIBOM vs. SBOM

A traditional Software Bill of Materials (SBOM) inventories code packages, libraries, and compiled binaries, represented in formats like CycloneDX or SPDX. Standard package registries (NPM, PyPI, Maven) provide machine-readable metadata for these components.

AI introduces artifact classes that package managers cannot represent:

• Trained model weights (binary blobs with embedded learned behavior, potentially including backdoors)
• Dataset lineage (origin, license, preprocessing steps, privacy properties)
• Fine-tuning configurations (LoRA adapters, PEFT checkpoints with lineage back to the base model)
• Prompt templates and system prompts (versioned strings that shape model behavior at runtime)
• Vector database contents (embedding indexes derived from potentially sensitive documents)
• MCP (Model Context Protocol) server connections (tool-calling integrations with external systems)
• Third-party AI API dependencies (OpenAI, Anthropic, Cohere) with their data retention and processing terms

The two major open standards have extended to address this. CycloneDX 1.6 introduced the ML-BOM specification with dedicated support for datasets, models, and ML configurations. Engineering and security teams favor it for rapid vulnerability matching. SPDX 3.0 introduced 36 specialized AI profile fields and treats datasets and models as first-class supply-chain elements. Legal teams favor it for license expression language. Both are under assessment by EU AI Act GPAI Code of Practice working groups for regulatory alignment.

---

What Must an AIBOM Contain

A complete AIBOM spans seven layers. The depth required at each layer depends on the risk classification of the AI system.

Layer 1: Data Training datasets require: origin and provenance URI, license (Creative Commons, commercial, proprietary), preprocessing steps applied, anonymization methods, confidentiality classification, and datasetType field (mandatory per SPDX 3.0). Inference-time data sources, including feature stores, APIs, and vector databases, require the same treatment.

Layer 2: Models Foundation models require: name, version, source repository, SHA-256 checksum, architecture summary, and training framework. Fine-tuned models require lineage back to the base model, adapter type (LoRA, QLoRA, PEFT), fine-tuning dataset reference, and performance metrics on evaluation benchmarks. Model card metadata covering intended use, limitations, bias evaluation results, and known failure modes belongs here.

Layer 3: Dependencies ML frameworks (TensorFlow, PyTorch, JAX) at exact versions. AI orchestration SDKs (LangChain, LlamaIndex, Semantic Kernel) at exact versions. Embedding models with version and source. Vector store configurations. Prompt templates with version hashes.

Layer 4: Infrastructure Container images (with associated vulnerability scan results from Trivy or equivalent). Compute specifications (GPU type, cloud region). Deployment platform (SageMaker, Azure AI, Vertex AI, Kubernetes). Network egress paths from AI components.

Layer 5: Third-Party AI Services Every external AI API in use, with: provider name, API version, data retention policy, geographic processing location, and applicable terms of service. This layer is where shadow AI typically hides, as developers often integrate external AI services without procurement review.

Layer 6: Security and Governance IAM roles and permissions scoped to each AI component. Access paths between components (for attack path analysis). Guardrail and safety configuration versions. Incident response contacts.

Layer 7: Provenance and Attestation Cryptographic hashes (SHA-256) for all artifacts. SLSA provenance for model artifacts where supported. in-toto attestation chains linking build steps to outputs. Training audit logs. This layer is what transforms an AIBOM from a static document into a verifiable security artifact.

---

Compliance Mapping: EU AI Act, NIST AI RMF, and OWASP

EU AI Act

Article 13 (High-Risk AI Systems): Full compliance required by 2 August 2026, with technical documentation retained for 10 years. Article 13 mandates that high-risk AI systems provide deployers with sufficient information to understand, operate, and appropriately interpret system outputs. Required documentation fields map directly to AIBOM layers: provider identity, system characteristics and limitations, known risk circumstances, training data specifications, hardware requirements, and logging mechanisms for compliance verification.

Article 53 (GPAI Models): Applicable since 2 August 2025, with Commission enforcement beginning 2 August 2026. Legacy GPAI models placed on market before August 2025 must comply by 2 August 2027. Four core obligations: maintain technical documentation of training and testing processes, provide downstream providers with sufficient information to enable their own compliance, adopt a copyright compliance policy, and publish a summary of training content. An AIBOM covering Layer 1 (data) and Layer 2 (models) with provenance fields satisfies the core documentation requirements for both articles.

For a detailed walkthrough of EU AI Act obligations by organization type, see our EU AI Act compliance guide.

NIST AI RMF

GOVERN 1.6: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." NIST defines an AI system inventory as an organized database covering: system documentation, incident response plans, data dictionaries, links to implementation software and source code, and names and contacts for relevant AI actors. This maps to Layers 1 through 6 of the AIBOM framework above.

GOVERN 6.1 and 6.2: Address third-party AI supply chain risk specifically: policies covering IP infringement from third-party AI components, and contingency processes for failures in third-party data or AI systems classified as high-risk. Layer 5 (third-party AI services) is the direct response to GOVERN 6 requirements.

OWASP LLM Top 10

LLM03:2025 (Supply Chain Vulnerabilities): This entry covers the full AI dependency chain, including pre-trained models with hidden backdoors or biases, fine-tuning attacks via LoRA and PEFT on Hugging Face, and third-party dataset contamination. The OWASP GenAI Security Project maintains an active AIBOM initiative and released an open-source AIBOM Generator at RSAC 2025. Our OWASP LLM Top 10 guide covers LLM03 and adjacent supply chain risks in detail.

For the full picture of AI supply chain attacks and mitigations, see our AI model supply chain security guide.

---

The AIBOM Tooling Landscape

No single commercial tool covers the full AIBOM lifecycle today. Building a complete program requires combining tools across discovery, scanning, attestation, and enforcement.

Discovery (Shadow AI):

• Cycode AI Inventory: SDLC-embedded discovery across 100+ dev tool integrations, tracking AI Infrastructures, Models, Code Assistants, MCPs, AI Packages, and AI Services. Best coverage for shadow AI in developer tooling.
• Wiz AI-SPM: Agentless cloud scanning that maps every AI service, SDK, and model running in cloud environments. Present in 70%+ of cloud environments per Wiz data. Best for cloud-native deployments.

Model Scanning (Pre-Deployment):

• Protect AI ModelScan: Open-source, scans H5, Pickle, and SavedModel formats for unsafe serialization payloads. Would have detected the nullifAI attack.
• OWASP AIBOM Generator: Open-source, generates CycloneDX AIBOMs from Hugging Face models with PURL-based component identification.
• JFrog Xray: Identified three Picklescan zero-day vulnerabilities in June 2025; provides commercial model artifact scanning.

Runtime Visibility:

• HiddenLayer AISec Platform 2.0: Model Genealogy and AIBOM export in industry-standard format. Strong adversarial ML detection alongside inventory capabilities.
• Sysdig: Runtime-focused AIBOM tracking GPUs, container images, and inference servers in production.

Attestation:

• AIBoMGen (arXiv:2601.05703): Research tool that generates cryptographically signed CycloneDX AIBOMs during model training using in-toto attestations and SHA-256 hashes, with negligible performance overhead (~0.4 second per training run).

The gap no single vendor fills: a complete, continuous AIBOM spanning training-time data provenance, SDLC-level shadow AI discovery, deployment runtime, prompt and MCP integration tracking, and cryptographic attestation in a single workflow. This integration gap is why many enterprises turn to a security assessment to scope and architect the right combination for their stack.

---

AIBOM in CI/CD: Blocking Untrusted Components

An AIBOM becomes an active security control when integrated into deployment pipelines:

Pre-commit hooks: Block model file additions that do not include a corresponding AIBOM entry with checksum and source provenance. Reject dependencies without approved version pins.

Pipeline gates: Before any model artifact reaches staging, verify its SHA-256 checksum against the AIBOM registry. Any new external AI API call added to application code requires a corresponding AIBOM entry with data processing terms documented.

Drift detection: Continuously compare the runtime AI component inventory (from tools like Wiz or Sysdig) against the AIBOM baseline. Alert on any model version, SDK version, or external API connection not present in the approved inventory.

MCP enforcement: As MCP server connections become standard in agentic AI deployments, each MCP integration requires an AIBOM entry covering: server URL, authentication method, data access scope, and operator identity. Cycode's AI Inventory includes MCP tracking. This is an emerging gap in most enterprise AIBOM programs today.

---

Five-Step AIBOM Implementation Roadmap

Step 1: Discover Shadow AI (Weeks 1-2) Integrate agentless scanning across cloud environments and developer tooling to build an initial catalog of AI services, models, and dependencies in use. Expect to find AI tools used without IT approval: Reco's 2025 State of Shadow AI Report found 75% of large enterprises have shadow AI usage.

Step 2: Document Training Artifacts (Weeks 2-4) For each AI system in production, interview model owners and collect: base model identity with checksum, fine-tuning dataset provenance, training framework version, and evaluation benchmark results. Use CycloneDX 1.6 or SPDX 3.0 format from the start to ensure regulatory compatibility.

Step 3: Capture Runtime Dependencies (Weeks 3-5) Map every SDK, vector store, external AI API, and MCP server connection for each AI system. Document data retention policies and geographic processing locations for all third-party AI services. This step typically reveals the most compliance exposure, as EU AI Act Article 53 downstream information obligations require this data.

Step 4: Apply Cryptographic Attestation (Weeks 4-6) Generate SHA-256 checksums for all model artifacts and record them in the AIBOM. For models trained internally, integrate AIBoMGen or equivalent tooling into training pipelines to generate in-toto attestations. For third-party models, verify published model cards and checksums against what is running in production.

Step 5: Enforce in CI/CD and Monitor for Drift (Month 2+) Integrate AIBOM checks into deployment pipelines as blocking gates. Configure drift detection to alert when runtime AI components diverge from the approved inventory. Establish a review workflow for AIBOM updates when model versions change, new dependencies are added, or third-party AI service terms are updated.

A BeyondScale AI security assessment covers Steps 1 through 3 as part of the initial engagement, delivering a baseline AIBOM and prioritized remediation roadmap.

---

AIBOM Maintenance: Versioning and Change Detection

An AIBOM is not a one-time document. Every model update, dataset refresh, dependency upgrade, or new third-party AI integration requires a corresponding AIBOM change with version history.

Key maintenance practices:

• Version-controlled AIBOM registry: Store AIBOM files in the same version control system as application code. Every deployment should reference the specific AIBOM commit hash that approved the AI components in that release.

• Model drift alerting: When a foundation model provider releases a new version, or when a fine-tuned model's behavioral outputs change materially on evaluation benchmarks, trigger an AIBOM review before the update is deployed.

• Third-party service auditing: Review external AI API data retention policies quarterly. EU AI Act Article 53 requires that downstream providers have sufficient information to maintain their own compliance, which means your AIBOM must reflect current processing terms, not terms from initial onboarding.

• Incident-triggered review: Any AI security incident, whether a model behaving unexpectedly or an API key exposure, should trigger an immediate AIBOM audit to identify whether unauthorized components contributed to the incident.

---

Conclusion: AIBOM as a Security Control, Not Just a Compliance Document

The AI Bill of Materials started as a compliance concept and is becoming a core security control. The incidents that defined 2024 and 2025 (ShadowRay, nullifAI, the 352,000 unsafe Hugging Face model issues found by Protect AI) all share a common root cause: AI components in production with no verified inventory, no provenance checks, and no alerting when unauthorized artifacts appeared.

EU AI Act Article 13 and Article 53 set the compliance floor, with enforcement beginning August 2026. NIST AI RMF GOVERN 1.6 sets the equivalent for US federal contexts. But the security case for an AIBOM does not depend on regulation. Every AI system running in production without a maintained component inventory is a blind spot that attackers will eventually find.

Building an AIBOM program means combining discovery tooling, pre-deployment scanning, runtime monitoring, and CI/CD enforcement into a continuous workflow. The standards (CycloneDX 1.6, SPDX 3.0) and open-source tools (OWASP AIBOM Generator, Protect AI ModelScan) exist today. The gap for most enterprises is the initial discovery and integration work.

BeyondScale performs AI asset discovery and baseline AIBOM generation as part of our AI security assessment engagement. If you are preparing for EU AI Act compliance or want to know what is actually running in your AI stack, book an AI security assessment or start with a free Securetom scan to surface your AI attack surface.