Behavioral Bill of Materials (BBOM)

Traditional AI documentation was built for a simpler world. Model cards describe what a model was trained on, how it performs, and where it has known biases. Datasheets document data provenance and quality. These artifacts answer a specific question: what is this model?

Agents ask a different question entirely. An AI agent is not just a model. It is a model wired to tools, memory, orchestration logic, and decision authority that let it take autonomous action in the real world. Documenting what the model is tells you almost nothing about what the agent can do. And what the agent can do is the part that creates risk.

The Behavioral Bill of Materials (BBOM) is a proposed documentation standard that addresses this gap. It catalogs an agent's full behavioral surface: its tools, permissions, decision boundaries, memory architecture, orchestration patterns, security controls, and failure modes. Where a model card tells you what the engine is made of, a BBOM tells you where the vehicle can drive, how fast it can go, and what happens when the brakes fail.

An important caveat: the BBOM is not yet a formal standard from any standards body. It does not appear in NIST AI 100-1, NIST AI 600-1, ISO 42001, or the EU AI Act. It is an emerging best practice synthesized from governance principles across these frameworks, first articulated in enterprise governance documentation as a practical response to the agent documentation gap.

The Software Bill of Materials (SBOM) transformed software supply chain security by giving organizations a machine-readable inventory of every component inside a software product. When a vulnerability hits a widely-used library, an SBOM tells you which systems are affected. It answers the question: what is this software made of?

A BBOM extends this concept from components to capabilities. An SBOM lists the libraries in your software. A BBOM lists the behaviors your agent can execute. An agent's tool manifest functions as a behavioral extension of the SBOM concept: instead of documenting code dependencies, it documents action dependencies. Which APIs can the agent call? What data can it read, write, or delete? What is the blast radius if a tool is misused?

The extension matters because the risk surface of an agent is fundamentally behavioral. A vulnerability in a software component is a static risk. A vulnerability in an agent's tool access or decision logic is a dynamic risk that changes with context, evolves with memory, and compounds across multi-step workflows. No existing documentation standard captures this adequately.

Before building a new documentation standard, it is worth understanding what the existing ones cover and where they fall short for agentic systems. The tools and frameworks used to build agents determine much of the behavioral surface that a BBOM must capture. Each addresses a real need. None addresses the full behavioral surface of an agent.

Model cards (Mitchell et al., 2019) document model-level information: intended use, training data, performance metrics, and ethical considerations. A BBOM includes all of this but adds the agent-specific layers that create real governance risk: tool access, orchestration patterns, memory architecture, decision constraints, and runtime behavior. An AI datasheet captures data provenance and quality, but agents create new data flows at runtime through their tool interactions. The EU AI Act's Annex IV technical documentation requirement is the most comprehensive existing standard, covering everything from system architecture to risk management to post-market monitoring. A BBOM operationalizes and extends Annex IV specifically for the behavioral dimensions unique to agentic systems.

A complete BBOM synthesized from governance requirements across NIST AI RMF, ISO 42001, and the EU AI Act contains ten sections. Each documents a different dimension of the agent's behavioral surface. Click any component below to see what it includes.

The gap between an agent's theoretical capability and its governed capability represents residual risk of constraint bypass (CW-039). The BBOM makes this gap explicit. Without it, the organization knows what the agent is designed to do but has no systematic record of what it could do if constraints fail.

The tool manifest is the most operationally critical section of a BBOM. It defines the agent's capability surface: the full set of actions the agent can take in the world. Every other section depends on understanding this surface first.

For each tool in the manifest, the BBOM documents its permission scope (read, write, execute, delete), the data types it can access or modify, its rate limits, and critically, its blast radius — the worst-case outcome if the agent misuses this tool. Blast radius forces a specific and uncomfortable question: if every guardrail on this tool fails simultaneously, what is the maximum damage the agent can inflict? That answer shapes everything from trust boundary classification to the maximum autonomous operation window before mandatory human review.

Agent knowledge limits are harder to define than for traditional AI because agents can extend their knowledge at runtime by querying tools and external sources (CW-019). A model's knowledge is bounded by its training data. An agent's knowledge is bounded by its tool access, which means the capability surface also defines the knowledge surface. The BBOM must document both.

Fallback behavior matters as much as primary behavior. When a tool becomes unavailable, the agent does not simply stop. Depending on its orchestration logic, it may retry, substitute a different tool, degrade gracefully, or fail in unpredictable ways. The BBOM documents fallback behavior for each tool (CW-043) so that operations teams know what to expect during outages.

While the BBOM is not itself a formal standard, every one of its sections maps directly to requirements in the three dominant governance frameworks: NIST AI RMF, ISO/IEC 42001, and the EU AI Act. Building a BBOM does not add new compliance obligations. It operationalizes existing compliance obligations for the specific challenges of agentic systems.

Transparency is the governance principle that drives most of the BBOM's value. For traditional AI systems, transparency means explaining how the model makes predictions. For agents, the bar is significantly higher because agents initiate autonomous actions that affect the real world.

The EU AI Act Article 13 requires that high-risk AI systems "shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately." Article 50 goes further for human-facing systems, requiring that persons interacting with AI be informed they are interacting with a non-human system.

For agents, this creates an elevated obligation. Agentic AI transparency obligations are significantly elevated because agents can autonomously initiate interactions with humans, sending emails, making calls, or participating in chats. Every agent-initiated communication must identify the agent as non-human (CW-027).

Decision trace logging is where the BBOM connects to operational reality. For agentic systems, transparency must include why the agent chose action A over action B, the rationale behind each tool invocation, and chain-of-thought visibility into the planning process (CW-013). The BBOM's monitoring and observability section documents how this logging is implemented, while the decision authority section documents what the traces should reveal.

The EU AI Act Article 12 specifically requires that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." For agents, this means capturing the complete execution trace: every LLM call (prompt and response), every tool invocation (request and response), every memory read and write, every external API call, and every decision point. Critically, logs must be immutable and tamper-evident: agents must not be able to modify their own logs (CW-030). For multi-agent systems, distributed tracing with correlation IDs that link actions across agent boundaries is required (CW-030).

NIST AI 600-1 (the Generative AI Risk Profile) identifies 12 risks unique to or exacerbated by generative AI. Five are directly relevant to what a BBOM should document. Each risk maps to a specific BBOM section that forces the organization to confront and record how it manages the exposure.

NIST AI 600-1 Risk 12 is particularly relevant: "Non-transparent or untraceable integration of upstream third-party components." Agents by nature compose multiple third-party services at runtime. The tool manifest section of a BBOM directly addresses this by documenting every external dependency, its provider, its trust boundary, and its fallback behavior. Without this, the organization cannot assess its exposure to upstream failures or compromises.

A BBOM that is accurate on deployment day and wrong six weeks later is worse than useless. It creates false confidence. The EU AI Act Article 11(1) requires that technical documentation "shall be kept up to date." ISO 42001 Clause 7.5 requires documented information to be "updated as necessary." These are not suggestions. They are enforceable requirements.

The BBOM must be treated as a living document with specific update triggers:

The following template synthesizes the 10 BBOM components into a practical structure that can be adopted for enterprise agent documentation. It is designed to be framework-agnostic while covering the requirements of NIST AI RMF, ISO 42001, and the EU AI Act. Adapt the depth of each section to your agent's risk classification and autonomy tier.

From an auditor's perspective, the BBOM serves three distinct functions. First, it is the primary input for impact assessments. ISO 42001 control A.5.2 requires an impact assessment process, and A.5.3 requires documenting those assessments. The BBOM provides the factual basis for both: an auditor cannot assess the impact of an agent without understanding its capability surface, decision authority, and data access.

Second, the BBOM's residual risk register is where the difficult governance conversations are documented. The register must explicitly enumerate the agent's remaining attack surface, known bypass scenarios for guardrails, edge cases where the agent may exceed its declared scope, and failure modes that cannot be fully mitigated (CW-039). This is the section that auditors and regulators care about most because it represents the honest assessment of what can go wrong after every control is in place.

Third, the BBOM enables deployer-level transparency. ISO 42001 control A.8.2 requires providing deployers and users with documentation of system capabilities, limitations, intended use, performance characteristics, and known failure modes. A deployer-facing summary extracted from the BBOM satisfies this requirement while keeping security-sensitive details like full system prompts and red-team bypass methods in the restricted full version.

The compliance mapping section (Section 10 of the template) is where the BBOM pays for itself. Rather than maintaining separate compliance documentation for NIST, ISO, and the EU AI Act, the organization maintains one BBOM per agent and maps it against each framework. When an auditor asks about Article 11 compliance, you point to the BBOM. When they ask about ISO A.6.2.7, same document. The BBOM becomes the single source of truth for agent governance, and the compliance mapping section serves as the index.

Implementing a BBOM across an enterprise agent fleet does not require waiting for a formal standard. The governance frameworks already mandate the documentation; the BBOM is simply a coherent structure for delivering it. Start with the highest-risk agents and work down.

Step one: inventory the capability surface. Before you can document what an agent does, you need to know what tools it has access to. Most organizations discover during this exercise that their agents have more permissions than anyone realized. The tool manifest forces an explicit reckoning with the actual blast radius of each agent.

Step two: document decision authority. Map out the hard constraints, escalation triggers, and the maximum autonomous operation window. This is where organizations most often find the gap between what they believe is governed and what is actually governed. If the agent has no maximum autonomous operation window, that means there is no mandatory human review cadence, and that is itself a finding worth documenting.

Step three: build the residual risk register. This is the hardest step because it requires honesty about what cannot be mitigated. Every agent has residual risks. The question is whether they are acknowledged, accepted with justification, and tracked over time, or whether they are simply unknown. The BBOM makes the unknown known.

Step four: establish update triggers. Assign ownership for BBOM maintenance and define the events that require updates: configuration changes, model upgrades, red-team exercises, and production incidents. Without update triggers, the BBOM becomes stale documentation and its value collapses.

The BBOM is an emerging concept with no formal standard body endorsement yet. That is both its limitation and its advantage. Organizations that build BBOM practices now are establishing documentation discipline that will map directly to whatever formal standard eventually arrives. The governance requirements are already here in NIST, ISO, and the EU AI Act. The BBOM is simply the most coherent way to meet them for agents. For broader enterprise AI governance strategy beyond the artifact layer, the AI Governance Hub provides the organizational and policy context that frames where BBOMs sit within a mature governance program.