What is an AI-BOM? A practical guide to AI bills of materials

What is an AI-BOM?

An AI bill of materials (AI-BOM) is a structured inventory of the AI components a piece of software depends on. Where a software bill of materials (SBOM) lists the libraries and packages you ship, an AI-BOM lists the things that make the software behave as an AI system: the model providers it calls, the specific models, the orchestration frameworks, the prompts, the agents and the tools they can use, the MCP servers it connects to, the vector stores and data sources behind retrieval, and the guardrails in front of all of it.

A useful AI-BOM records three things for each component: what it is (identity and version), where the evidence is (the file and line that shows the dependency), and how it relates to everything else (this agent uses this model through this framework and can call these tools). The relationships matter as much as the list, because most AI risk lives in the connections: untrusted input reaching a prompt, a model's output reaching a tool, a tool reaching your data.

Why teams need an AI-BOM now

Two years ago most codebases had one AI integration, added deliberately. Today AI arrives through many doors: an engineer adds a provider SDK to prototype a feature, a framework pulls in a model by default, a coding assistant writes an agent loop, a teammate commits an MCP configuration for their editor. The result is shadow AI: AI components in production that nobody reviewed or recorded.

An AI-BOM gives you answers to questions that otherwise take days of searching:

• Incident response. A provider deprecates a model, or an advisory lands for an AI framework version. Which repositories are affected, and where exactly?
• Security review. Which agents can execute code or call tools that change state? Which MCP servers are configured, and are their versions pinned?
• Data governance. Which services send data to which external providers? Which retrieval pipelines read from which data sources?
• Customer and audit questions. Security questionnaires increasingly ask which AI services a vendor uses and where data goes. Frameworks such as the NIST AI Risk Management Framework and regulations such as the EU AI Act emphasise documenting the AI components in a system.
• Change control. What changed in the AI stack between the last release and this one?

AI-BOM vs SBOM

An AI-BOM extends the SBOM idea rather than replacing it. You want both, and many teams export them side by side.

What goes into an AI-BOM

There is no single required field list, but these are the component types worth recording, and the details that make each entry useful:

Two kinds of metadata deserve special care:

• Evidence. Every entry should point to the file and line that proves it. An inventory without evidence cannot be verified or kept current.
• Declared facts. Supplier, release date, download location, license and provenance often cannot be inferred from code. They have to be declared by someone who checked the source. Mark which facts were detected and which were declared, and never fill a gap with a guess (for example, a scan date standing in for a model release date).

AI-BOM formats: CycloneDX and SPDX

You do not need a new format. Both major SBOM standards now model AI components:

• CycloneDX added machine learning support (often called ML-BOM) in version 1.5. Models are components of type machine-learning-model, datasets and similar assets are components of type data, and model details can be described with a model card. Relationships use the normal dependency graph.
• SPDX 3.0 added an AI profile and a Dataset profile. They are stricter about provenance: the AI profile expects facts such as the supplier, release time, download location and version of each model, which is why they usually need human declaration.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:pypi/example-agent-framework@0.9.2",
      "name": "example-agent-framework",
      "version": "0.9.2",
      "purl": "pkg:pypi/example-agent-framework@0.9.2"
    },
    {
      "type": "machine-learning-model",
      "bom-ref": "model:example-provider/example-model-2025-06",
      "name": "example-model-2025-06",
      "supplier": { "name": "Example Provider" }
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:pypi/example-agent-framework@0.9.2",
      "dependsOn": ["model:example-provider/example-model-2025-06"]
    }
  ]
}

Pick the format your consumers ask for. CycloneDX is common in security tooling and can be produced from detection alone; SPDX AI profile output is a good fit when you need declared provenance for audit or procurement.

How to build an AI-BOM

By hand, for a first look

For a single repository you can get a rough inventory in an afternoon:

1. Search dependency manifests and lockfiles for AI provider SDKs, orchestration frameworks, vector store clients and MCP SDKs.
2. Search code for model identifiers (model names passed to SDK calls) and for prompt templates.
3. Find agent definitions and every tool or function registered with them.
4. Collect MCP client configuration files: .mcp.json, claude_desktop_config.json, .vscode/mcp.json, .cursor/mcp.json and the MCP sections of other editors' settings.
5. Record the file and line for each item, the version where there is one, and how the items connect.

# AI SDKs and frameworks in manifests
git ls-files | grep -E '(package\.json|requirements.*\.txt|pyproject\.toml|go\.mod|pom\.xml)$' \
  | xargs grep -nEi 'openai|anthropic|gemini|bedrock|mistral|cohere|langchain|llama.?index|mcp'

# MCP client configuration files
git ls-files | grep -E '(^|/)(\.mcp\.json|claude_desktop_config\.json|mcp\.json)$'

The manual approach breaks down quickly. It misses components that are configured rather than imported, it has no evidence trail once code moves, and it is stale the day after you finish. Most importantly, it cannot tell you what changed.

Automatically, on every scan

The reliable approach is to generate the AI-BOM from static analysis of each repository, at an exact commit, every time the default branch is scanned. That gives you an inventory with evidence for every entry, a version history you can compare, and alerts when something new appears.

This is how CodeStax's AI security scanning works. Each complete scan of a repository's default branch produces a new, immutable generation of the AI-BOM for that commit, covering providers, models, frameworks, prompts, agents, tools, MCP servers, vector stores, guardrails and AI-facing routes, each with its source evidence. Generations export as CycloneDX 1.7 or SPDX 3.0.1 AI profile JSON, and repeated exports of the same generation are byte-identical, so a digest means something. Facts that code cannot prove, such as a model's supplier, release time and download location, are added as verified declarations by an admin, recorded in the audit log, and never filled in with guesses.

Keep the AI-BOM current: versions and drift

An AI-BOM is a snapshot, so its value comes from comparing snapshots. Build it from the default branch, keep every version, and watch for these changes between versions:

• A new AI provider or model appears (often the first sign of shadow AI).
• A model identifier loses its revision pin.
• A new MCP server is declared, or a server's version changes.
• An AI framework or SDK version gains a known vulnerability.
• An agent gains a tool that can execute code or change state.

Route high-severity changes to the people who own them (a webhook or an email to the security owner works), and review the rest weekly. CodeStax records added and removed assets, providers and models, models that lose their pin, version changes, new MCP servers and newly vulnerable AI dependencies on the AI attack surface Changes tab (Growth plan and above), and delivers high and critical changes to your webhooks and organization admins automatically.

AI-BOM checklist

If you are also securing the MCP servers your AI-BOM turns up, our MCP server security guide covers the threat model and a checklist for each server.