To create an AI bill of materials (AI-BOM), first build an inventory of your AI systems, then record for each one the models, datasets, prompts, tools, MCP servers and software packages it depends on, with versions, hashes and provenance, and finally serialize that list in an open format, usually CycloneDX or SPDX 3.0. CycloneDX handles AI through its machine-learning BOM (ML-BOM) support with model cards; SPDX 3.0 handles it through dedicated AI and Dataset profiles. Choose the format your existing SBOM tooling already reads, generate the AI-BOM on every release and every material change, and store each version so you can diff it and prove what was running. For the short definition, see the AI-BOM glossary entry.
What goes into an AI-BOM
A software bill of materials lists packages. An AI system has more moving parts, and many of them are not packages at all. A useful AI-BOM covers:
| Component class | What to record | Why it matters |
|---|---|---|
| Models | Name, provider or publisher, version or commit, file hash, format (safetensors, pickle, GGUF), licence | Identifies exactly which weights ran; flags unsafe formats |
| Model endpoints | Hosted API, region, deployment name | A hosted model changes without a file you can hash |
| Datasets | Training, fine-tuning and retrieval sources, versions, licences | Data lineage and IP questions start here |
| Prompts and system instructions | Version or hash | A prompt change can change behaviour as much as a model change |
| Tools and MCP servers | Server identity, version, tools exposed, auth method | The agent's real action surface |
| Agent frameworks and packages | Library versions (classic SBOM content) | Known vulnerabilities in the runtime |
| Identities and credentials | Which service identity the agent uses (never the secret) | Blast radius if the agent is compromised |
| Policies | Guardrail and access policy versions | Shows which controls applied at the time |
Not every row applies to every system. A batch classifier needs models, datasets and packages. An agent that calls tools through MCP needs the tools and servers too, because that is where most of its risk lives. The MCP security guide covers how to vet third-party servers before they reach that list.
Step 1: find the systems
You cannot write a bill of materials for something you have not found. Start from an AI agent inventory: registered agents, agents seen in traces, code repositories that import AI SDKs or define MCP clients, and the LLM provider keys in use. Shadow deployments are the usual gap, so combine more than one discovery method.
Step 2: map dependencies per system
For each system, list what it calls. For a classic ML service this is a short list read from the deployment manifest. For agents it is a graph: agent to model endpoint, agent to MCP server to tool, agent to another agent. A topology map of agent dependencies is effectively the raw material of an AI-BOM, and it also shows shared dependencies, such as one MCP server used by twenty agents.
Record what you can verify, and mark what you cannot. "Model: unknown version, hosted endpoint" is honest and useful. A confident but wrong entry is worse than a gap, because it will be trusted later.
Step 3: capture versions, hashes and provenance
For each component, capture the strongest identifier available:
- Files you host (weights, adapters, datasets): a cryptographic hash, plus the source repository and commit.
- Hosted model APIs: the provider, model identifier and version string the API returns, and the date observed.
- MCP servers and tools: server name, version, the list of tools it exposed and, if the server is packaged, the package version and digest.
- Prompts: a hash of the system prompt and its version in your repository.
Where a publisher signs its artefacts, record the signature or attestation reference too. Model signing with Sigstore explains how to verify that.
Step 4: choose a format, CycloneDX or SPDX
Both are open standards with mature tooling. They differ in emphasis more than capability.
| CycloneDX (ML-BOM) | SPDX 3.0 (AI and Dataset profiles) | |
|---|---|---|
| Steward | OWASP / Ecma International (ECMA-424) | Linux Foundation (ISO/IEC 5962 for SPDX 2.2) |
| How AI is modelled | machine-learning-model and data component types; model card object for training, performance and considerations |
Dedicated AI package and Dataset package classes with fields for autonomy, safety risk, energy, data collection and more |
| Strengths | Security-oriented; same document can carry vulnerabilities (VEX), services and dependencies | Licensing and compliance heritage; rich relationship model |
| Typical fit | Teams already producing CycloneDX SBOMs in CI | Teams with SPDX licence-compliance pipelines |
| Agent-specific classes (MCP server, tool, prompt) | No dedicated type; use generic components plus properties | No dedicated type; use generic elements plus properties |
The CycloneDX ML-BOM documentation covers the model card fields in detail, and the SPDX 3.0 specification defines the AI and Dataset profiles.
Two practical notes. First, neither standard has a first-class type for an MCP server or an agent tool, so you will map those to generic components and add custom properties naming the true class. Do it consistently and document the property names. Second, pick one format as the source of truth. Converting between them is possible but lossy for AI fields.
Step 5: generate, store and diff
Agents change often: a new tool connection, a model upgrade, a prompt edit. A one-off spreadsheet is stale within weeks. Treat the AI-BOM like any build artefact:
- Generate it in CI on release, and on any change to model, tool or prompt configuration.
- Store every version with a hash, and sign it if your pipeline signs other artefacts.
- Diff consecutive versions and review additions: a new MCP server or a new model is a change worth a human look.
- Keep it next to the evidence for the system's audit trail, so an auditor can match "what was declared" with "what happened".
AI-BOM creation checklist
Why regulators and customers will ask for it
Software bills of materials are moving from good practice to requirement. The EU Cyber Resilience Act requires manufacturers of products with digital elements to identify and document components, including by drawing up an SBOM; we discuss what that means for agent products in the EU Cyber Resilience Act and AI agent products. The EU AI Act's technical documentation for high-risk systems asks for a description of the system's elements, data and development process, and an AI-BOM is a natural way to keep that current. The Digital Omnibus, adopted as Regulation (EU) 2026/1744, moved the high-risk application dates to 2 December 2027 (Annex III) and 2 August 2028 (Annex I), so use those rather than dates written before it was adopted. Enterprise customers ask the same question more directly in security questionnaires: which models and third-party services does your AI touch?
How Praesidia fits
Praesidia covers the part of the job an AI-BOM depends on most, which is knowing what your agents are and what they connect to:
- Discover. Agent discovery builds one inventory from the agents and MCP servers you register, the traces you send, and the GitHub and GitLab repositories you connect. It does not scan cloud accounts, data warehouses or endpoints, so those sources stay your job.
- Secure. Model and tool allow-lists on each governed connection keep the real dependency set close to the declared one, because unapproved models and tools are refused when a task is dispatched.
- Prove. Decisions are written to an append-only, hash-chained audit trail, signed under the default configuration and verifiable offline, so a declared component list can be checked against what agents actually did.