AI Bill of Materials (AI BOM): What It Is and How to Build One

An AI bill of materials (AI BOM) is an inventory of every AI component a piece of software depends on: the models it calls, the providers that host them, the frameworks and agent tools around them, and the data that shaped them. It is the AI equivalent of a software bill of materials (SBOM), and it answers a question most companies cannot answer today: which AI is actually running in our code, and where does our data go?

Why an AI bill of materials matters

AI arrived in most codebases one pull request at a time. A developer adds an SDK to summarize tickets, another wires a model into search, someone commits an MCP server config so the team's coding agent can query the database. None of it goes through procurement, and nobody has the full picture. An AI BOM fixes that, and it pays off in four places:

• Data protection. Every AI provider is a data processor. Prompts routinely carry customer data, source code and credentials. You need to know which providers receive them and under which jurisdiction they process it.
• Security. Models, packages and agent tools are supply chain components (LLM03 in the OWASP LLM Top 10). You cannot patch or review what you have not inventoried. An unpinned MCP server is a good example, covered in our MCP security guide.
• Compliance. The EU AI Act, ISO/IEC 42001 and customer questionnaires all assume you can list the AI systems you use. An AI BOM is the evidence. See SOC 2 and GDPR evidence for how inventories feed audits.
• Cost and vendor risk. When a provider changes pricing, deprecates a model or has an outage, an AI BOM tells you in minutes which services are affected.

AI BOM vs SBOM

A software bill of materials lists packages and versions, and software composition analysis checks them for known vulnerabilities. An AI BOM goes further because AI components have properties packages do not:

What to include in an AI bill of materials

A useful AI BOM does not need to be exhaustive on day one. Start with what you can detect in code, then add the governance fields:

1. Providers. Every hosted AI API the code calls (OpenAI, Anthropic, Google, Mistral, DeepSeek, AWS Bedrock, Azure OpenAI and so on), how it is reached (SDK, HTTP host, environment variable), and the jurisdiction it processes data in.
2. Models. Each model identifier in use, with the files that reference it. Pin exact versions where the provider allows it.
3. Self-hosted models. Weights loaded from a hub, their source, format (safetensors versus pickle) and license.
4. Frameworks and agent tooling. LangChain, LlamaIndex, agent SDKs, vector stores, and the agents developers use on the repo.
5. MCP servers. Every MCP server configured or implemented, its transport, launch command and version.
6. Agent configuration files. Rules files and settings (CLAUDE.md, AGENTS.md, .cursorrules, editor agent settings) that change how AI behaves on the codebase.
7. Datasets. For anything you train or fine-tune: data sources, licenses and provenance.
8. Owner and approval status. Who owns each component and whether it is approved, blocked or unreviewed.

AI BOM formats: CycloneDX and SPDX

Two open standards cover AI components. CycloneDX added a machine learning BOM (ML-BOM) in version 1.5, with component types for models and datasets and a model card structure. SPDX 3.0 added AI and Dataset profiles. Use one of these if a customer or regulator asks for a machine-readable AI BOM. Here is a minimal CycloneDX-style entry for one hosted model:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "machine-learning-model",
      "name": "claude-sonnet-4-5",
      "publisher": "Anthropic",
      "properties": [
        { "name": "ai:hosting", "value": "third-party-api" },
        { "name": "ai:jurisdiction", "value": "US" },
        { "name": "ai:usedIn", "value": "src/services/support/summarize.ts" }
      ]
    }
  ]
}

How to build an AI bill of materials

Manual spreadsheets go stale within a sprint. The reliable approach is to generate the AI BOM from the code itself, on every scan:

1. Detect providers from SDK imports, API hostnames and provider environment variables.
2. Extract model identifiers from string literals and configuration.
3. Parse agent and MCP configs committed to the repo.
4. Record where each component is used, file by file, so owners can be assigned.
5. Apply a policy that marks each component approved, blocked or unreviewed, so new AI shows up for review instead of slipping in.
6. Re-run in CI so the AI BOM stays current and changes show up in pull requests.

An allowlist policy can live in the repo itself. For example:

{
  "providers":  { "allow": ["openai", "anthropic"], "block": ["deepseek"] },
  "models":     { "allow": ["gpt-4o*", "claude-*"] },
  "mcpServers": { "allow": ["github", "@modelcontextprotocol/server-filesystem"] }
}

How Scanverra builds an AI inventory

The Scanverra Repo Scanner generates an AI inventory, the core of an AI bill of materials, every time it scans a repository. It detects AI providers (through SDK imports, API hosts, environment variables and model names) and records each provider's processing jurisdiction, lists the model identifiers in use with the files that reference them, and finds AI frameworks, agent tooling, vector stores, configured and implemented MCP servers (with transport and launch command, secrets redacted) and the agent instruction and settings files in the repo. It recognizes more than 40 AI providers.

If you add a .scanverra/ai-policy.json, each component is marked approved, blocked or unreviewed, and anything blocked or off the allowlist becomes a finding. It also flags data sent to providers that process it in China, and it can draft a starting policy from what it found. The inventory appears in the AI Security tab of the scan report.

What it does not do yet: Scanverra does not export the inventory as a CycloneDX or SPDX file, and it does not catalog training datasets or model cards. If you need a formal machine-readable AI BOM for a customer, use the inventory as your source list and fill in a CycloneDX ML-BOM from it.

Getting started

Run a scan to see the AI already in your code, decide which providers and models you approve, commit the policy, and keep the scan in CI. That gives you a living AI bill of materials in an afternoon instead of a spreadsheet nobody updates.