Method · Dependency record

AI Bill of Materials for agentic systems

An AI Bill of Materials makes hidden dependencies visible so security, architecture, procurement, evaluation, and incident teams can understand what changed and what is affected.

Enterprise

Published August 1, 2026Updated August 1, 2026Reviewed August 1, 2026By LongTermIntelligence.com

Direct answer

What belongs in an AI Bill of Materials for an agentic system?

An AI Bill of Materials should list the models, prompts, system instructions, datasets, retrieval sources, tools, connectors, libraries, runtimes, policies, identities, memory stores, external services, vendors, versions, owners, licenses, data flows, and integrity evidence used by the system.

An inventory is not proof that every component is safe or compliant.
Include dynamic tools and remotely hosted dependencies, not only packaged software.
Connect every row to change, evaluation, and incident processes.

Source basis: reviewed synthesis of the strategy corpus. Report-derived claims remain subject to the verification boundary in the source library.

Decision table

Recommended component classes

The record should be queryable by system, version, supplier, owner, data boundary, and risk.

Class	Examples	Key evidence
Model	Foundation, embedding, reranker, classifier, judge.	Provider, version, deployment, evaluation, data handling.
Instruction	System prompt, agent charter, rubric, tool description.	Version, owner, integrity hash, approval.
Data and retrieval	Corpus, index, knowledge graph, feature store, live API.	Source, lineage, sensitivity, retention, access.
Tool and connector	MCP server, API, database action, code runner.	Identity, permissions, side effects, sandbox, owner.
State and memory	Checkpoint, conversation state, durable memory, cache.	Schema, isolation, retention, deletion, provenance.
Policy and control	Authorization, routing, budget, evaluation, approval.	Version, enforcement point, exception process.
Runtime and library	Orchestrator, SDK, container, package, microservice.	Version, integrity, vulnerabilities, support.
Supplier and service	Cloud, platform, model provider, data vendor.	Contract, region, SLA, exit, incident contact.

Method

Operate the AIBOM as a living record

A static spreadsheet becomes stale as soon as a provider or tool changes.

Establish system identity
Assign a stable system ID and version so each component has a clear context.
Capture direct and transitive dependencies
Record hosted services, dynamic tools, libraries, and upstream data sources.
Add ownership and boundaries
Name the accountable team, data class, permissions, region, and expected side effects.
Automate what can be automated
Generate package, model, configuration, and deployment metadata where practical.
Trigger review on change
Use component changes to rerun targeted evaluation, risk, and access checks.

Editable resources

Download the editable AIBOM

The CSV is intentionally portable and can be imported into a GRC, CMDB, asset, procurement, or data-governance system.

CSV worksheet