An SBOM for Agents: What Belongs in an AI Bill of Materials

Discovery tells you an agent exists. It does not tell you what the agent is made of. You can have an agent in your inventory, with an owner and a risk tier, and still not know which model it runs on, which prompt version governs its behavior, which tools it can call, or which data it can reach. The inventory record confirms the agent is there. It says almost nothing about what it is.

Security teams already solved a version of this problem for software. The software bill of materials became the standard way to answer "what is this built from" without re-auditing the whole system every time a question comes up. Agents need the same thing, and the term is forming right now: the AI bill of materials. An agent bill of materials is a declared, structured record of everything an agent is composed of. It is a different artifact from an inventory record, and it does different work.

The SBOM on-ramp

The software bill of materials established a machine-readable list of every component and dependency in a piece of software. When Log4Shell landed, the teams that could answer "are we running a vulnerable version of Log4j" in minutes were the ones with an SBOM. Everyone else re-audited from scratch under pressure. Supply-chain risk was the forcing function, and regulation followed.

The analogy carries, and it also bends in a way worth naming. An agent's dependencies are not just libraries. They are a model, a prompt, a set of tools, live data sources, and often other agents. A software component is static once it ships. An agent's composition includes things that change underneath it: a model provider pushes an update, a prompt gets a new version, a tool definition changes. So an agent bill of materials has to capture more than a dependency tree, and it has to reflect what the agent actually runs, not what someone wrote down about it once.

What belongs in an agent bill of materials

Seven components. Each one records something a reviewer needs to assess the agent's risk surface.

Model. The provider, model family, version, and configuration. A model swap changes behavior and risk, so the bill of materials has to name which one is in use, not just "an LLM."

Prompt and version. The system prompt and its version identifier. Prompts govern behavior, so the record points to the exact version running. "A prompt" is not enough when the difference between two versions is the difference between a passing and a failing agent.

Tools. Every tool and function the agent can call, with what each one is able to do. This is the agent's action surface, and it is the first thing a security reviewer wants to see.

Data sources. The RAG corpora, databases, and APIs the agent retrieves from. This is where sensitivity and jurisdiction questions attach, and where a reviewer decides whether the agent can reach data it should not.

Policies and guardrails. The controls in force: which guardrails run, which policies apply. A record that lists composition without controls is only half the picture.

Evals. Which evaluations run against the agent and what they check. This is the evidence that behavior is measured rather than assumed.

Dependent agents. Any subagents or agents this one delegates to. Composition is recursive. A bill of materials that stops at the first agent misses the blast radius of everything it calls.

A bill of materials is not an inventory record

The two get conflated, and the distinction is the point. Inventory answers "does this agent exist and who owns it." A bill of materials answers "what is this agent made of."

Inventory is a row. A bill of materials is a structured document, and it supports two things the row cannot. The first is auditability: a reviewer can assess the full risk surface without interrogating the running system, because the composition is declared in one place. The second is reproducibility: when behavior changes, you can tell what changed, because you have a record of what the agent was built from before and after.

The two are complementary. Inventory is the index. The bill of materials is the contents behind each entry.

Why signing and export matter

A bill of materials that lives only inside the platform that generated it is a report. A signed, exportable one is an artifact.

Signing gives provenance and tamper-evidence. A reviewer can trust that the bill of materials reflects the agent as it actually ran, not a description someone edited afterward to look cleaner than reality.

Export makes it portable. You can hand it to a compliance function, to an enterprise buyer evaluating your agent, or to an auditor, without giving any of them access to your systems. A signed, exportable statement of composition is a verifiable, transferable object, which is what separates a security artifact from documentation.

Where discovery makes the bill of materials cheaper to produce

Hand-authoring a bill of materials is the failure mode. It drifts from reality the moment the agent changes, and nobody remembers to update it.

A traced agent emits most of its own bill of materials. Telemetry already carries the model, the tool calls, and the data sources the agent touched. If you are instrumenting agents to emit traces from day one, the bill of materials can be generated from what the agent actually did rather than from what someone wrote down about it. That closes the gap between the declared composition and the observed behavior, which is exactly where hand-maintained records fail.

What to instrument

• A defined bill of materials per agent covering model, prompt version, tools, data sources, policies, evals, and dependent agents.
• Components populated from telemetry where possible, not hand-maintained.
• A signed, exportable artifact rather than an internal-only view.
• The bill of materials attached to the agent record, so a reviewer sees composition alongside ownership and the governance controls that make a discovered agent auditable.

Arthur discovers the agents running in your environment and models what each one is composed of, so composition travels with the agent record instead of living in a spreadsheet. Book a demo to see it, or explore the Agent Development Toolkit.

‍