Safeguard
Tutorials

How to Create an AIBOM for Your AI Models

Build an AI Bill of Materials that inventories the models, datasets, adapters, and MCP tools your application depends on — using CycloneDX ML-BOM and commands you can run today.

Daniel Osei
DevSecOps Engineer
5 min read

If your application calls a language model, loads weights from a hub, fine-tunes an adapter, or wires an agent to external tools, you are shipping AI supply chain that a traditional SBOM never captures. An AI Bill of Materials (AIBOM) extends the SBOM idea to AI components: the base models, their versions and licenses, the datasets they were trained on, fine-tuning adapters, and the MCP tools an agent can reach. Regulators and enterprise buyers are starting to ask for it, and you cannot govern an AI estate you have not inventoried. This guide shows how to generate an AIBOM for a real project.

Prerequisites

  • A project that references AI models — for example a requirements.txt with model libraries, a model registry reference, or an MCP configuration.
  • The Safeguard CLI installed: curl -sSfL https://get.safeguard.sh/install.sh | sh.
  • Read access to any private model registry you want the AIBOM to include.

Step 1: Declare your AI components

The CLI discovers models from your code and manifests, but an explicit declaration makes the inventory reliable and reviewable. Create .safeguard/ai-components.yaml:

models:
  - name: llama-3.1-8b-instruct
    source: huggingface.co/meta-llama/Llama-3.1-8B-Instruct
    version: "main"
    license: llama-3.1-community
    usage: inference
  - name: text-embedding-3-large
    source: openai
    usage: embeddings
adapters:
  - name: support-tone-lora
    base: llama-3.1-8b-instruct
    dataset: internal/support-transcripts-v3
mcp_tools:
  - name: github
    source: docs.safeguard.sh/docs/mcp
    scopes: [repo:read]

Step 2: Generate the AIBOM

Produce a CycloneDX ML-BOM that merges your declared components with what the CLI discovers in code and lockfiles:

sg aibom generate --format cyclonedx-json --output aibom.cdx.json

The summary confirms what was captured:

AIBOM: checkout-assistant
  models:    2 (1 hosted, 1 API)
  adapters:  1
  datasets:  1
  mcp tools: 1
  supporting libraries: 214 (from requirements.txt)
Wrote aibom.cdx.json (CycloneDX 1.6 ML-BOM)

Note that the AIBOM includes both AI-specific components and the ordinary software dependencies that serve them — an inference stack is still Python packages under the hood.

Step 3: Validate the document

Check it against the ML-BOM schema so downstream consumers can parse it:

sg aibom validate aibom.cdx.json

A passing run confirms every model has a source and license, and that the component relationships (adapter-to-base, dataset-to-model) are well-formed.

Step 4: Assess risk across the AI components

An inventory is the input; risk assessment is the value. Evaluate the AIBOM for license conflicts, vulnerable serving libraries, and untrusted model sources:

sg aibom assess aibom.cdx.json --format table

This flags issues such as a model with a license that conflicts with commercial use, a serving library with a known CVE, or a model pulled from an unpinned main revision that could change under you.

Step 5: Attach and monitor

Upload the AIBOM so it is tied to the commit and re-evaluated as new advisories and model issues surface:

sg aibom generate --format cyclonedx-json --sbom-upload

Verify the result

Confirm the AIBOM is complete and valid:

# Schema is valid ML-BOM
sg aibom validate aibom.cdx.json

# Every declared model appears in the output
sg aibom stats aibom.cdx.json

If a model you declared is missing, check that its source is reachable and that the ai-components.yaml entry is spelled exactly as the registry expects.

How Safeguard streamlines this

Inventorying AI components by hand is hopeless — models get swapped, adapters proliferate, and agents gain new MCP tools every sprint. SBOM Studio generates and stores the AIBOM alongside your regular SBOM, diffs versions so you can see when a model or tool was added, and re-assesses stored AIBOMs when a new model vulnerability or license issue emerges. Because the CLI discovers the supporting libraries with the same engine as your dependency scans, the AIBOM captures the full stack — models and the Python packages that serve them — in one document. Griffin AI then reasons over that inventory to recommend a safer model revision or flag an MCP tool with excessive scopes, landing the change as a reviewable pull request. That is how an AIBOM becomes an operational governance tool rather than a one-off compliance PDF. See how it scales on the pricing page.

Ready to inventory your AI stack? Connect a project at app.safeguard.sh/register.

Frequently Asked Questions

What is an AIBOM? An AI Bill of Materials is a machine-readable inventory of the AI components an application depends on — base models, their versions and licenses, training datasets, fine-tuning adapters, and the tools an agent can call. It extends the SBOM concept to the parts of your system a traditional dependency scan cannot see.

How is an AIBOM different from a regular SBOM? An SBOM inventories software packages; an AIBOM additionally captures models, datasets, adapters, and agent tooling, along with AI-specific metadata like model provenance and training-data lineage. In practice a good AIBOM includes both, because a model is always served by ordinary software that also needs tracking.

Which format should an AIBOM use? CycloneDX provides an ML-BOM extension designed exactly for machine-learning components, expressing models, datasets, and their relationships in a standard schema. Generating in CycloneDX ML-BOM keeps the AIBOM interoperable with the same tooling that already consumes your CycloneDX SBOMs.

What risks does an AIBOM help me catch? It surfaces model-license conflicts that block commercial use, vulnerabilities in the libraries serving your models, models pulled from unpinned or untrusted sources, and agent tools with excessive permissions. You cannot assess or govern any of those without first knowing they exist, which is the inventory's job.

Do I need an AIBOM if I only call a hosted model API? Yes. Even an API-only integration is a dependency with a provider, a model version, terms of use, and data-handling implications worth recording. An AIBOM documents that relationship so you can answer which models your product relies on and reassess when a provider changes or deprecates one.


Explore SBOM Studio, Griffin AI, and the Safeguard CLI, or review plans on the pricing page. Full AIBOM documentation lives in the Safeguard docs.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.