Why does Software Bill of Materials (SBOM) fail as a complete inventory model…

Research Question

Why do traditional Software Bill of Materials (SBOM) concepts fail to adequately describe the dependency, provenance, and runtime composition of agentic Artificial Intelligence (AI) systems, and what fundamentally new abstractions, graph structures, mutable dependency types, and non-deterministic component representations, are required in an Artificial Intelligence Bill of Materials (AIBOM) to close those gaps?

Findings

Executive Summary

Traditional Software Bill of Materials (SBOM) is not a complete inventory model for agentic Artificial Intelligence (AI) because it is optimized for declared software artifacts and component relationships, while agentic execution depends materially on mutable context, delegated authority, and stochastic model behavior that appear only during runtime.

Current AI-oriented extensions such as CycloneDX AI and machine-learning bill-of-materials, SPDX AIPackage and DatasetPackage, and the OWASP AIBOM Generator widen coverage to models, datasets, hyperparameters, and training metadata, but they still inherit package-style inventory semantics rather than full execution-provenance semantics.

A complete AIBOM therefore needs a typed graph model that links software artifacts, models, datasets, prompts, retrieval corpora, tools, memory state, and identity or permission objects through explicit derivation, invocation, delegation, and retrieval edges, then pairs that declared graph with runtime-observed provenance.

The decisive conceptual shift is from a bill of packaged parts to a bill of governed capability plus realized execution path, because only that combined abstraction can explain what the system was allowed to do, what context it actually used, and why a given output or action occurred.

Key Findings

1. NTIA SBOM and the reviewed SPDX AI extensions remain package-centered inventory models, because even the AI-specific classes are defined as metadata added to software-package objects rather than as first-class runtime activities or provenance graphs.
2. CycloneDX AI and machine-learning bill-of-materials, SPDX AI classes, and the OWASP AIBOM Generator materially extend software transparency to models, datasets, hyperparameters, preprocessing, and training metadata, but they still do not by themselves represent prompts, decisions, retrieval results, or executed authority paths as the core inventory object.
3. Agentic AI introduces semantically active and mutable dependencies, including prompts, system instructions, retrieved context, tool outputs, memory state, and delegated permission scope, that are governance-relevant even when they are not versioned artifacts in the traditional software sense.
4. Foundation-model inheritance, lifecycle trustworthiness requirements, and context-dependent execution mean that a static package inventory cannot fully explain AI system behavior, because risk also depends on model lineage, data provenance, evaluation context, and downstream runtime conditions.
5. A provenance-oriented graph is the best-supported core abstraction currently available for complete agentic AIBOMs, because the central audit questions concern entities, activities, actors, derivations, and causal processing steps rather than package membership alone.
6. A conceptually complete AIBOM needs new node types, relationship types, and property classes, specifically runtime events, prompt artifacts, memory objects, authority objects, retrieval edges, delegation edges, mutability labels, determinism labels, trust domains, and variability envelopes, because package version identifiers cannot represent those semantics.
7. The best-supported architecture in this evidence set is a layered model in which classical SBOM remains one sublayer for software artifacts, the declared AIBOM captures approved graph structure and semantics, and runtime-observed AIBOM instances capture what actually executed in a specific run.

Assumptions

• Assumption: Prompts, system instructions, memory state, and delegated permission objects should be treated as inventory-relevant components even when current BOM standards do not yet define canonical classes for all of them. Justification: they materially affect agent behaviour, provenance, and auditability in agentic workflows.
• Assumption: Declared AIBOM identifiers can be linked to runtime provenance strongly enough to support approved-versus-executed comparison in practice. Justification: that linkage is required for governance, but no reviewed universal identifier scheme covers every agentic surface.

Analysis

The strongest rival interpretation is that AIBOM only needs more fields inside existing SPDX and CycloneDX objects. The evidence rejects that narrow view, because the reviewed AI classes and current OWASP generator still model the core unit as a package or repository artifact, while the provenance sources show that agentic audit questions are about events, decisions, and actors.

The second rival interpretation is that static AIBOM plus generic logs is sufficient. That view was rejected because W3C PROV and PROV-AGENT both center explicit causal relationships among entities, activities, and actors, and the adjacent runtime-divergence item shows that retrieval, memory, authority, and topology diverge across runs in ways that simple logging does not normalize into one auditable object.

The correct synthesis is therefore additive rather than replacement-oriented. Classical SBOM remains useful for software libraries, frameworks, and conventional dependencies inside an AI system, but it becomes only one layer inside a broader AIBOM whose central object is governed capability plus realized execution path.

Risks, Gaps, and Uncertainties

• A reviewed standard or toolset still does not provide a canonical agentic AIBOM schema covering prompts, tools, memory, delegated authority, and runtime state in one stable specification.
• Dedicated academic literature on agentic provenance is still thin relative to the maturity of software-provenance standards, so the graph recommendation relies on one recent agentic paper plus broader provenance standards.
• The conceptual treatment of non-determinism is still incomplete, especially around how to version prompt semantics, preserve enough runtime context for audit, and express acceptable variance across repeated runs.

Open Questions

• How should prompts and system instructions be versioned so that semantic changes, not only text edits, become auditable?
• What minimum runtime snapshot is sufficient for retrieval results, memory state, and tool outputs without over-collecting sensitive data?
• Should stochastic behavior in AIBOM be represented as a variability envelope, a replay record, or a policy-bound set of acceptable outcomes?

sources

• [x] National Telecommunications and Information Administration (2021) The Minimum Elements for a Software Bill of Materials (SBOM) - foundational SBOM definition and minimum-elements framing
• [x] CycloneDX Machine Learning Bill of Materials (AI/ML-BOM) - official CycloneDX description of AI and machine-learning bill-of-materials coverage
• [x] SPDX Specification 3.0.1 AIPackage - official SPDX class for Artificial Intelligence packages and trained models
• [x] SPDX Specification 3.0.1 DatasetPackage - official SPDX class for datasets used in software or to train and test AI packages
• [x] OWASP AIBOM - OWASP initiative describing AIBOM as an auditability and traceability layer for AI systems
• [x] GenAI Security Project AIBOM Generator - official repository showing current AIBOM tooling scope, output format, and standards alignment
• [x] Suriyawongkul et al. (2025) Implementing AI Bill of Materials (AI BOM) with SPDX 3.0 - academic report arguing that AI projects require a broader bill of materials than software alone
• [x] Bommasani et al. (2021) On the Opportunities and Risks of Foundation Models - foundation-model properties, downstream inheritance, and emergent capability framing
• [x] National Institute of Standards and Technology (NIST) AI Risk Management Framework - official lifecycle and trustworthiness framing for Artificial Intelligence systems
• [x] World Wide Web Consortium (W3C) PROV Overview - provenance model for entities, activities, agents, derivation, reproducibility, and versioning
• [x] Souza et al. (2025) PROV-AGENT: Unified Provenance for Tracking AI Agent Interactions in Agentic Workflows - provenance model for prompts, responses, decisions, and workflow context in agentic systems
• [x] David Mitchell (2026) AI security threat model for prompt injection, Retrieval-Augmented Generation (RAG), supply chain, and exfiltration - prior repository item on structural retrieval and tool-path risk
• [x] David Mitchell (2026) Runtime-observed AIBOM and declared-versus-observed divergence theory - adjacent repository item on runtime provenance and divergence
• [x] David Mitchell (2026) AIBOM identity, delegation, and trust theory - adjacent repository item on authority, delegation, and permission objects