What Is an AI-BOM, Really?

One AI-BOM might tell you which model an agent uses. Another might list the MCP server it runs. Neither necessarily tells you that a vulnerable package is sitting under a plugin that can read and send your iMessages.

That’s the trouble with the question what is an AI-BOM? — there’s no single answer. An AI-BOM is a machine-readable inventory of an AI system’s components. Which components depends entirely on who you ask — and the definitions fall into two camps:

Layer	Who defines it this way	What it covers
Model	OWASP	the model: license, training data, hyperparameters, evaluation
System	Palo Alto, JFrog, Trusera, Checkmarx, Cisco	the running stack: LLMs, agents, MCP servers, tools, skills

Two camps, one gap between them — and even within the system camp, no two tools agree on the exact list (the links and subsets are in the sections below). The term names two layers; the interesting part is what sits between.

Layer 1: the model AI-BOM

The first lineage comes out of model transparency. The clearest reference implementation is the OWASP GenAI AIBOM Generator, which reads metadata from a model and emits an AI-BOM in CycloneDX; its field-mapping docs align those fields to CycloneDX 1.7 (modelCard) and the SPDX 3.0.1 AI Profile. The fields are precise: model name and version, license, hyperparameters, performance metrics, training and test datasets, lineage, known limitations.

This is the layer the standardized BOM formats already cover. It answers “what model is this, who made it, what was it trained on, and can I safely use it?” — for governance, compliance, and transparency. By design, it stops at the model’s edge.

Layer 2: the system AI-BOM

The second lineage comes out of security. Here an AI-BOM inventories every AI asset in a deployed system. Palo Alto Networks defines an AI-BOM as covering the software components used to build and operate the AI system — models, data pipelines, serving infrastructure. JFrog covers models, runtime configurations, and dependencies. Checkmarx discovers LLMs, AI SDKs, orchestration frameworks, MCP clients and servers, and agents. Trusera finds LLM providers, agent frameworks, model files, MCP configuration, and Agent-to-Agent endpoints. Cisco’s open-source AI BOM is the broadest — models, agents, tools, MCP servers and clients, skills, prompts, guardrails, datasets, secrets — and does dependency analysis, cross-reference resolution, and OSV.dev vulnerability lookups on what it finds.

This layer answers “what AI is actually running in my environment?” — for security and supply-chain risk. Two things are worth naming. The subsets vary widely; there’s no agreement on what belongs in the list. And there’s no shared profile for the agent layer the way CycloneDX and SPDX define one for models — tools here serialize to CycloneDX, but their taxonomies for agents, MCP servers, and skills are each their own.

The gap in the middle

The stronger system tools do real work: dependency analysis, cross-reference resolution, OSV lookups. But two things hold consistently.

First, the common subsets stop before the surface growing fastest in coding agents — plugins, skills, hooks, and slash commands (the broadest list has skill, but not the rest).

Second, and more important, none of them make agent-composition lineage the portable contract. Portable contract means the BOM carries the parent-child path, not just a list: a downstream tool can tell that path-to-regexp arrived via imessage → MCP server → bun.lock, not merely that it exists somewhere in the tree.

That’s the missing object. It isn’t another inventory — it’s lineage: how the parts are wired together. Put plainly: AI-BOMs list the parts; Agent BOMs explain the wiring.

Make it concrete. The imessage plugin in the official Claude Code marketplace bolts a local MCP server — one that reads your message history and can send messages as you — to a pair of skills, on top of ninety-one npm packages, with known advisories in packages like hono and path-to-regexp recorded in bun.lock. Here is the same plugin, seen three ways:

The same imessage plugin, three ways of seeing it:

  model AI-BOM    (nothing — there's no model in the chain)

  system AI-BOM   imessage-mcp · hono · path-to-regexp · + many more
                  — a flat list of assets

  Agent BOM       imessage  (plugin)
                  ├─ configure              (skill)
                  ├─ access                 (skill)
                  └─ imessage-mcp           (MCP server — reads chat.db, sends as you)
                     ├─ hono              ⚠ advisory
                     └─ path-to-regexp    ⚠ advisory

Only the third view connects the advisory to the capability: the vulnerable package is wired, through that MCP server, under that plugin, into an agent that reads your private messages. That correlation is the risk — and it’s the one a component list alone can’t express. We scanned the whole marketplace to show how often it hides.

How OpenACA approaches it

The agent-composition layer is what OpenACA makes the contract. It builds a composition graph: plugins, MCP servers, skills, hooks, and commands as nodes; declaration, containment, and dependency as edges. Scope is derived from that lineage, so a package pulled in a few hops below a plugin’s MCP server is attributed as an agent dependency, not lost in the repo’s general dependency tree.

On top of that graph, OpenACA matches components against upstream advisory records — GHSA, CVE, OSV, and OSSF malicious-package records — with agent-specific context layered on as overlays. We call the practice Agent Composition Analysis, and the artifact it produces an Agent BOM.

FAQ

Is an AI-BOM the same as an SBOM? No. An SBOM inventories software dependencies. An AI-BOM extends that to AI-specific components — at the model layer (training data, weights, license) or the system layer (agents, MCP servers, tools). Neither, on its own, captures how agent components are wired together.

Is an AI-BOM the same as an Agent BOM? Not quite. Most AI-BOMs list components; an Agent BOM adds the lineage — which plugin declares which MCP server, which package it runs, and which advisory reaches which agent context. AI-BOMs list the parts; Agent BOMs explain the wiring.

Do CycloneDX or SPDX support AI-BOMs? At the model layer, yes — CycloneDX 1.7’s modelCard and the SPDX 3.0.1 AI Profile describe models, datasets, and provenance. The agent-composition layer (plugins, skills, hooks, MCP launch paths) isn’t yet covered by a shared profile.

The layers stack

A model AI-BOM tells you what’s inside the model. A system AI-BOM tells you what AI is running. An Agent BOM tells you what your agent is actually composed of, and where that composition is exposed. Use all three.

If your AI-BOM can’t tell you which plugin introduced a vulnerable package, which MCP server launches it, and which agent context can call it, it isn’t wrong — it’s answering a different question. The agent-composition layer is the one still missing a shared answer.

Try it

OpenACA is open source. Point it at your own setup and read the composition back:

uvx openaca scan endpoint --include-posture

It resolves the plugins, MCP servers, skills, hooks, and commands wired into your agent, builds the Agent BOM, and matches each component against known advisories. If the output looks different from your SBOM, that’s the point — the missing object is the agent composition. Source and docs: github.com/open-agent-security/openaca.