By Yann Lechelle, Executive President & Chairman of Probabl
& Daniel Whitenack, CEO of Prediction Guard
The transition from traditional software engineering to agentic AI has introduced a fundamental crisis of operational authority for enterprises.
In the classical software development lifecycle, the concept of ownership was binary: source code was either proprietary or open source, and dependencies were tracked through relatively static manifests generated as part of the release process.
Somewhere in the early 2010s, software began eating the world in various forms of subscription services – from Infrastructure-as-a-Service to Platform-as-a-Service via APIs, all the way to Software-as-a-Service – obfuscating every bit of software dependencies formerly processed by the owners of older licensing models.
Today, as enterprises increasingly adopt AI through usage-based APIs, managed cloud services, and third-party model integrations, the infrastructure of intelligence has become dangerously opaque. To make matters worse, more and more enterprises today operate in a state of shadow AI – the unsanctioned use of AI tools by employees without formal oversight by IT or InfoSec teams. As a report by IBM highlights: over a third of employees acknowledge sharing sensitive work information with AI tools without their employers' permission, and the risks compound at every layer of the stack, including the model lifecycles, data lineage and flow, connected tools like MCP servers and the runtime behaviors.
The results are concerning: Enterprise leaders struggle to know the full extent of their ownership of data science or AI in their organization.
For enterprise leaders navigating this challenge, the AI Bill of Materials (AIBOM) is a concept worth understanding. Analogous to the Software Bill of Materials (SBOM) that is increasingly used by enterprises to understand and secure their software supply chains, the AIBOM is a standardized, machine-readable inventory of every model artifact, tool connection, dataset, and infrastructure component involved in building and operating an AI system. The AIBOM gives enterprise leaders answers to questions like what models are we running, their degree of openness, and who controls them? What data flows through them? What third-party dependencies and tool connections are active? Where are our compliance exposures?
In this article, we argue that AIBOMs are a promising governance tool for enterprise leaders to understand, strategize, and take action on their ownership and control of AI or the lack thereof.
The rapid adoption and development of agents has led to a fragmented AI stack that extends far beyond single models towards distributed harnesses supporting agentic workflows and automation. Enterprises may stitch together third-party APIs like Azure OpenAI or AWS Bedrock, various vector databases, and agentic frameworks, creating a web of integrations where true control and ownership is absent. In these environments, security policies are often enforced externally by vendors, and the handshakes between models and internal tools are opaque. While traditional models presented risks like bias and data leakage, agents introduce a new level of risk. They don't just provide outputs; they take actions. This shift dramatically compounds risks like unauthorized actions and privilege escalation
True AI ownership starts with control and capability. One cannot govern what one does not own, audit, and actively manage. However, the current paradigm of AI consumption, characterized by a reliance on external vendors for security boundaries, update cycles, and alignment decisions, leaves enterprises with limited agency over their own intelligence assets.
There is a trend in industry to prioritize the magic and speed of frontier AI agents over verifiable control and management of the underpinning supply chain, pushing enterprises toward all-in cloud-only or AI-only strategies. This creates a pay-as-you-go trap, where on-demand pricing for compute and tokens leads to uncontrollable OPEX expansion, benefiting the supplier’s profits rather than the enterprise's long-term value. When an organization gives a supplier open-ended access to its bank account while losing the ability to understand or reuse its own experiments, it loses its freedom of movement.
Separately, when such systems are managed by US providers – as is often the case given their prevalence – they fall under powerful US extra-territorial laws such as the Cloud Act or FISA (particularly Section 702), giving the US administration the ability to tap into potentially sensitive data that belongs to individuals and corporations, regardless of their citizenship or place of incorporation. By default, AI systems handle lots of potentially sensitive data.
Ownership is not just a legal status but an operational capability. It means owning the lifecycle, versioning, governance enforcement, and runtime behavior of every asset in the AI system. It is about operational agency and the ability to control the connective tissue of the stack. This ensures the organization can audit (and own) every interaction between a model and its data sources, regardless of whether they reside in a private cloud or a hybrid environment. This requires a move from AI consumption (vendor-dictated) to AI operation (enterprise-owned).
The historical origins of the Bill of Materials (BOM) lie in manufacturing, where it served as the definitive list of raw materials and sub-assemblies required to manufacture a product. In the digital realm, this concept first evolved into the Software Bill of Materials (SBOM) to address the complexity of modern software supply chains, where open source components often comprise the majority of a code base. Initially concerned primarily with licensing, the SBOM eventually became a regulatory and security cornerstone, notably codified in the United States through Executive Order 14028, which mandated SBOMs for software purchased by the federal government. The Cyber Resilience Act in the EU additionally introduces attestation programs recommending the production of SPDX 3.0 SBOMs.
However, SBOMs are inadequate to capture the nuances of machine learning (ML) and AI systems, exposing a critical documentation gap. Traditional SBOMs were designed for static logic (code that remains constant between versions). AI systems, conversely, are typically non-deterministic entities; their behavior is determined not just by code, but by the distribution of training data, the stochastic nature of inference, and the continuous evolution of model weights through retraining or fine tuning. The actual AI model often constitutes only a small fraction of a production system’s code, yet it introduces the most significant uncertainty. This complexity necessitated the development of the AIBOM as an extension of the SBOM, treating artifacts like datasets and model architectures as first-class citizens in the supply chain.
|
Era |
Primary Standard |
Core Artifacts Tracked |
Primary Security Focus |
|
Manufacturing |
Traditional BOM |
Raw materials, physical parts |
Physical defects, shortages |
|
Software |
SBOM |
Libraries, binaries, licenses |
Known vulnerabilities (CVEs) |
|
AI Systems |
AIBOM |
Datasets, weights, tool connections, hyperparameters, model origin, etc. |
Bias, poisoning, drift, agency, use restrictions, etc. |
Table 1: Taxonomy of BOMs
The shift to AIBOMs began in earnest around 2021, when working groups within the SPDX and CycloneDX communities realized that existing standards could not meaningfully capture AI-specific artifacts like fine-tuned checkpoints and data pipelines. The motivation was clear: transparency and explainability are essential for trust, and without a machine-readable record of model origins, organizations could not verify the security, provenance, or governance enforcement of the AI systems they deployed.
While the AIBOM remains the major parent umbrella term used to describe the broad requirement for transparency in AI systems, a more specialized concept, the Agentic Bill of Materials, has emerged to capture the complexities of agentic systems. Because agents tend to be active rather than passive and backed by a distributed agent harness, evolving AIBOM specifications may need to track the specific risks of autonomous action, such as unauthorized actions and privilege escalation, invocation of an inventory of tools, operational independence, required human-in-the-loop approvals, and connections to MCP servers. But the reality is that the AI industry is evolving faster than the development of standards and governance frameworks like AIBOMs. Closing the gap will require open, cross-industry collaboration on tooling and specifications that no single vendor or organization can deliver alone.
A functional AIBOM must provide a structured inventory across multiple layers of the AI ecosystem to enable effective security operations. The complexity of modern AI means that a simple list of models is insufficient; the AIBOM must include key layers making it actionable and comprehensive.
The success of an AI model is inextricably linked to its training data. The data layer of an AIBOM captures the provenance, licensing, and processing history of all data assets. This includes:
This layer tracks the models themselves and their iterative evolution. In an AI system, the model layer ensures that teams maintain control over versions and avoid stealth updates from providers that can introduce regressions.
AI systems and agents are rarely standalone; they exist atop complex, and often distributed, software stacks. The dependency layer identifies vulnerabilities in the ML/AI frameworks (e.g., PyTorch, scikit-learn), SDKs (e.g., LangChain), and other runtime dependencies necessary for training and serving. Additionally for agentic systems, this layer may identify an inventory of tools, functions, and/or MCP servers available to one or more agents.
Tracking the hardware and resources supporting AI workloads is crucial for both cost optimization and sovereignty. This pillar includes details on GPUs/TPUs used, network paths between components, and the specific cloud regions or on-premises boundaries where workloads execute.
Unique to the AIBOM is the need to document the controls applied to the system. This includes things like NIST and OWASP-aligned policies enforced by a governance control plane, such as prompt injection filters and sandboxed execution environments. Critically for agents, this layer may define autonomy tiers (i.e., does the agent need human-in-the-loop approval to perform certain actions like spending money or deleting files).
A dynamic AIBOM must evolve alongside the system. This layer includes information on how model drift, performance metrics over time, and identified risks such as bias or sensitive information disclosure flow to an audit log.
Especially for regulated industries, the AIBOM must include fields for human oversight design, fairness assessments, and evidence of compliance with frameworks like NIST 600-1, AIUC-1 or the EU AI Act.
For an AIBOM to be useful in an enterprise context, it must be machine-readable and interoperable across different tools. Two dominant standards have emerged: SPDX (ISO/IEC recognized) and CycloneDX (OWASP-managed). Application of these standards to AI systems and agents is being actively explored by, e.g., the OWASP AIBOM project.
The System Package Data Exchange (SPDX) 3.0 specification represents a major re-architecture, introducing Profiles to simplify the documentation of specific use cases.26 The AI Profile and Dataset Profile were separated to clarify the distinct provenance requirements of models and data.
The primary class in the AI Profile is the AIPackage, which inherits from the Software Package class but adds 36 specialized fields, including:
|
Field Name |
Type |
Purpose |
|
autonomyType |
PresenceType |
Describes the system’s level of operational independence. |
|
hyperparameter |
DictionaryEntry |
Captures parameters like learning rate and batch size. |
|
modelExplainability |
String |
Links to documentation on how the model makes decisions. |
|
energyConsumption |
EnergyConsumption |
Tracks the environmental footprint of training and inference. |
|
safetyRiskAssessment |
RiskAssessmentType |
Categorizes risk (High, Medium, Low) per internal or external standards. |
Table 2: Key Classes in SPDX 3.0 AI Profile
The DatasetPackage in the Dataset Profile includes mandatory fields for datasetType and optional fields for anonymizationMethodUsed, confidentialityLevel, and dataPreprocessing. This allows for a granular view of the ingredients used in training, ensuring that licensing and privacy obligations are met.
CycloneDX focuses on integration with security workflows and DevSecOps tools. It introduced ML-BOM support in version 1.5, allowing for the embedding of model cards and extensive property taxonomies.
The CycloneDX approach uses the machine-learning-model component type and provides specific objects for:
Engineering teams often find CycloneDX more agile for rapid vulnerability matching, while legal teams prefer SPDX for its extensive license expression language.
Transitioning to an AI strategy that you fully own requires a methodical approach to AIBOM management. Engineering leaders should view the AIBOM as infrastructure, not paperwork.
Not every notebook or prototype requires a full AIBOM, but production systems and externally sourced models do. Ownership should be clearly assigned: MLOps teams manage the automation pipeline, data scientists provide model lineage, and compliance teams maintain oversight.
Map every entry point for AI in the organization, including SaaS tools with embedded AI and internal prototypes. Gaps usually appear at integration points, so a comprehensive inventory of internal, cloud, and third-party models is essential.
Manual documentation does not scale. Metadata collection should be embedded into training and deployment pipelines.
Once data is collected, it must be validated against SPDX or CycloneDX schemas. This prevents mismatches that compromise audit readiness. Crucially, the AIBOM should be digitally signed and versioned alongside the AI system it describes. This enforces integrity and ensures that the version history is tamper-proof.
Integrate the AIBOM with a control plane to enforce real-time policies. This allows the AI system to:
The transition from AI consumption to AI operation is not merely a technical shift but a fundamental requirement for the modern enterprise. As AI becomes the central nervous system of enterprises in regulated industries, the illusion of control provided by vendor-defined security boundaries is no longer sufficient. Operational resiliency and control is defined by the ability to own, audit, and actively manage the entire lifecycle of intelligence.
The AI Bill of Materials stands at the center of this transformation. It is a technical solution that promises benefits for transparency, security, and regulatory compliance, and provides enterprise leaders with the agency to own and control their AI.
AIBOMs are, of course, not a silver bullet. The reliability of AIBOMs will initially be constrained by supplier compliance, requiring time and internal validation efforts. The lesson from SBOMs is that they become reliable only through demand for quality and standardization, meaning that the organizations that start requiring AIBOMs and hold suppliers accountable for quality today will be the ones who shape what good looks like tomorrow. Crucially, tracking AIBOMs is the first step toward moving from symbolic governance to active authority, ensuring that the enterprise has the ultimate authority over how its intelligence operates.
In 2026 and beyond, the most successful enterprises will not necessarily be those with the most advanced frontier models, but those that understand their AI context best and maintain full operational ownership over their assets. Reclaiming ownership is a design principle, not a checkbox, and the AIBOM is an essential tool to help enterprises be resilient going forward.
Yann Lechelle is the Executive President and Chairman of Probabl, the company by the creators of scikit-learn.
Daniel Whitenack is CEO of Prediction Guard, a company providing an enterprise AI control plane that enforces AI governance within a company’s infrastructure (including the ability to track and export AIBOMs).
We thank Arnaud Le Hors and Cailean Osborne for their input on earlier drafts.