AI Bill of Materials for Agentic AI Systems

What an AI Bill of Materials is

Gartner expects 40% of enterprise applications to include agentic AI by 2026, up from under 5% just a couple years back. IDC goes further out and gets more specific, projecting that 45% of IT product and service interactions will run through agents as the primary interface by 2028. Those are steep curves. But the number that actually matters sits inside McKinsey's "State of AI 2025" report: only about a third of organizations have scaled AI enterprise-wide, and just 23% have done the same with agentic AI specifically. Roughly 39% are still experimenting. Deployment is outrunning the governance work needed to run it safely. Deloitte's 2025 data shows the strain directly: worker access to AI jumped 50% that year, but only one in five companies had a mature governance model for autonomous agents.

A model gets fine-tuned or swapped out and the paperwork never catches up, and that mismatch is visible in plain, uncomfortable ways. A model gets fine-tuned or swapped out and the paperwork never catches up. An agent picks up a new tool connection, or a broader scope of authorization, and no one runs a risk review before it ships. Ask a security team at a company deploying AI at scale four basic questions: what's running, where it lives, what it's allowed to do, and who's accountable for it. The honest answer, at a lot of organizations right now, is "we're not fully sure."

An AI Bill of Materials works off the same idea as a Software Bill of Materials: a structured list of what's actually inside a system. But AI behavior doesn't come from code alone, it comes from data and model weights just as much, and a plain SBOM can't cover that. You can list every library and dependency a model imports and still know nothing about what the model was trained on or why it behaves the way it does.

Groups working on this problem, CycloneDX, SPDX, OWASP, IBM Research, and the Linux Foundation among them, have converged on roughly six areas a defensible AIBOM needs to cover:

• Models: architecture, version, provenance, base model lineage, weights identifiers, licenses.
• Datasets: sources, how the data was collected, preprocessing steps, licenses, known limitations.
• Code: frameworks, libraries, dependencies, version pins. This overlaps with a standard SBOM.
• Hardware: what compute trained the model, what compute it needs to run, accelerator types.
• Data processing pipelines: training pipelines, validation pipelines, retrieval pipelines for RAG setups, the orchestration layer tying it together.

Governance covers approval history, a change log, evaluation results, known failure modes, compliance attestations, and the level of human oversight the system requires.

A static SBOM gets written once and mostly sits still. An AIBOM can't work that way, because AI systems get retrained, fine-tuned, and fed new data on an ongoing basis. The change log is part of the artifact itself here. It's part of the artifact itself.

Terminology across the field is a bit of a mess: AIBOM, AI-BOM, AI SBOM, ML-BOM, MBOM. They all point to roughly the same thing with minor differences in scope, so don't get hung up on the label. On the schema side, CycloneDX and SPDX 3.x with its AI Profile are doing most of the work. A separate 2026 paper in Frontiers in Computer Science proposed extending CycloneDX further with cryptographic validation and agent-driven automation, so provenance claims could be checked by machine instead of taken on faith.

All of this is real progress, and none of what follows argues against it. An AIBOM turns "we think we know what's running" into something a person can review, update, query, and hand to an auditor. That's a legitimate artifact worth having. The argument here is about what it was never built to answer.

What Standard AI BOMs Omit About an Agent

Agentic systems aren't passive endpoints. They retrieve private context, call tools, write files, hit external services, coordinate with other agents, and in a lot of deployments now, act without a human checking first. That's a different animal from a model sitting behind an API waiting for a prompt.

A paper from WAI USA Research Labs, introducing something called AgentRiskBOM (arXiv:2606.21877), names the gap as capability opacity. Existing BOM artifacts do a solid job on software dependencies, model metadata, and training provenance. What they leave out entirely is a structured account of what a deployed agent can actually access, remember, change, hand off to another agent, and prove after the fact.

A researcher whose role centers on artificial intelligence at one company, who also contributed to a national framework for managing risk in these systems, said in a trade publication that once you delegate agency, the security-relevant dependencies stop being just model plus data. They become action pathways, behavioral artifacts, tool skills, prompts, policies, workflow definitions. That's a fundamentally different inventory than a component list gives you.

A standard BOM cannot answer these questions once an agent is live:

• Which tools, MCP servers, and APIs can it call, and at what permission level? What does it remember, and for how long? What credentials does it hold, or could it pick up at runtime?
• What approval gate stands between it and an action with real external consequences?
• Which other agents can it delegate to, and does that delegation carry its own authority with it?
• What audit trail does it leave, and can that trail be tampered with after the fact?

The gap here is structural. It's structural. A component inventory answers what's in the system. An agent forces a different question: what is the system allowed to do. No amount of refining the first question gets you an answer to the second, and treating them as the same problem is exactly where most current AIBOM practice goes wrong.

OWASP's 2026 update to its LLM risk list ranked excessive agency third, behind prompt injection and sensitive information disclosure. The field already knows what happens when this question goes unanswered.

Even the basics, models and data lineage, remain hard for a lot of organizations to document consistently. Dark Reading reported that early drafts of BOM standards which tried to capture every conceivable detail of an AI system ran into pushback from practitioners, because most organizations simply don't keep records at that level of granularity. A standard that demands more than organizations can realistically maintain becomes a standard nobody follows. That's scope discipline, not a reason to ignore capability opacity. Both things are true at once.

What AgentRiskBOM adds

AgentRiskBOM is built as an additive layer. It points back to SBOMs, AIBOMs, and ML-BOMs where those artifacts are already authoritative, and adds the fields agents specifically need on top of them: agent identity and model or prompt metadata, tool descriptors paired with tool-risk tiers, an autonomy level, memory scope and data sources, approval gates, audit signals, inter-agent communication, credential scope, control mappings, and references back to the external BOMs it complements.

The paper's evaluation ran across 13 documented open-source agents spanning coding assistants, RAG systems, and multi-agent setups, tested against 52 risk scenarios across 14 categories. The schema validated against all 13 corpus artifacts.

The coverage numbers are where the argument lands. A prior-art coverage analysis scored AgentRiskBOM at 14 out of 16 native-equivalent capability dimensions. SBOM scored 1.0. AI-BOM scored 1.5. ML-BOM scored 2.0. That gap places AgentRiskBOM in a different category of artifact than SBOM, AI-BOM, and ML-BOM, not just ahead of them by degree.

Risk visibility tells the same story from another angle. Across the modeled risk categories, AgentRiskBOM gave 100% risk-category visibility. SBOM-like views gave 10.5%. AIBOM-like views gave 20.9%. Existing tooling was catching roughly one risk category in five, at best. Four out of five categories were simply invisible to the people supposedly documenting risk.

The researchers also tested how the artifact held up over time, injecting 33 structured deployment mutations to simulate authority drift, the slow creep where an agent's permissions or reach change after it's already live. The diff detector correctly identified the change type for all 33. A Spearman rank correlation of 0.73 between the paper's primary and secondary scorers backs up rank-level consistency, though the authors are upfront that categorical scoring thresholds still need human calibration. This is a tool built to support judgment, not replace it. It is a structured schema artifact with a reproducible corpus, a risk-scenario library, a rule-based scorer, a diff detector, a control mapper, and rendered reports, meant to run alongside a human reviewer rather than instead of one.

Where MCP and Tool-Calling Concentrate Risk That Static BOMs Cannot Track

Anthropic introduced the Model Context Protocol in November 2024, and it's since become the default way LLM-based agents connect to outside tools and data. MCP standardizes tool invocation through JSON-RPC 2.0 messaging. An agent can call a file system, a database, a web service, or another agent through one uniform interface instead of a dozen custom integrations.

Adoption moved fast. MCP server adoption has grown rapidly across major AI platforms, with first-class client support baked into most of them. Security maturity did not move at the same pace, and the vulnerability count backs that up. Between January and February 2026 alone, researchers filed more than 30 CVEs against MCP servers, clients, and the infrastructure around them. By May 2026, at least seven confirmed high- or critical-severity CVEs spanned major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf. Tool poisoning, prompt injection carried through a tool's response, intent drift, credential exfiltration: these are threat categories a properly built tool-permission record would catch before deployment, not after.

The disconnect is simple to state. A conventional AIBOM records which frameworks and libraries an agent imports. It says nothing about which MCP servers that agent can reach, under what permission tier, using whose credentials, or behind what approval gate. Those are exactly the fields AgentRiskBOM was built to add, and their absence from standard AIBOMs is the whole reason the gap exists.

Shadow MCP usage makes it worse. An agent quietly connecting to an MCP server nobody approved or registered is the same category of risk as shadow IT always was, except the action surface here runs wider: file systems, databases, other agents, external services, all reachable through one uniform call. The right BOM artifact documents that connection before it becomes an incident report. Right now, for a lot of organizations, it doesn't get documented until after.

Regulatory and Standards Requirements So Far, and the Remaining Gap

CISA, working with G7 partners including Germany, Canada, France, Italy, Japan, the United Kingdom, and the European Union, published "Software Bill of Materials for AI, Minimum Elements" on May 12, 2026. It extends traditional SBOM thinking into AI, requiring documentation of models, datasets, software components, providers, licenses, and dependencies. The guidance is voluntary, but it reflects consensus across G7 technical experts, and that carries real weight even without teeth behind it. CISA's own framing acknowledges that AI risk comes from more than code: model provenance, training and validation data, performance characteristics, infrastructure dependencies, and security properties all factor in.

The guidance left out an autonomy level field, the one field that matters most for agents, leaving that dimension unaddressed in the core standard.

CISA followed up in July 2026 with updated Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA guidance that had stood for five years. That update holds off on adding agent-specific fields to the core SBOM standard, and instead points back to the separate May 2026 guidance for anything falling under that domain.

The EU AI Act adds sharper teeth. Transparency obligations took effect August 2, 2026, and high-risk AI systems now face requirements under Article 11 and Annex IV that map closely onto AIBOM fields. Fines for non-compliance reach €35 million or 7% of global annual turnover, whichever is larger. Member states have until August 2027 to stand up AI regulatory sandboxes. A separate provision, Article 53(1d), already required general-purpose AI model providers to publish a Training Data Summary starting August 2, 2025.

Texas has enforced its TRAIGA law since January 2026. Singapore's IMDA published a "Model AI Governance Framework for Agentic AI" in January 2026, extending its existing guidelines to address delegation chains and multi-agent coordination directly, one of the few frameworks to name agent-specific risk in its title. An industry group focused on cloud security released its Controls Matrix for that domain in July 2025: 243 control objectives spanning 18 security domains.

None of this covers the scenario that's becoming routine: an agent deployed in one country, reaching into an EU system, triggering an action in Singapore, pulling data stored in Japan. No framework on that list adequately addresses that chain, and none was built to. Before anyone can reason about which jurisdiction's rules apply, someone needs a record of the agent's actual reach: its credential scope, what external actions it can take, who it can delegate to. That record is a prerequisite for determining jurisdiction, not a substitute for it.

The pattern is clear once you line these up. Regulators have moved on static component documentation. They have not moved on runtime authority documentation, and the one field that would have forced the issue, autonomy level, was explicitly set aside. Compliance mandates alone won't close the agentic gap. Something else has to.

What a complete AI BOM for an agentic system must contain

Layer the two things on top of each other. Don't treat one as a replacement for the other, and don't stop at the static layer just because it's the one regulators have already blessed. Existing AIBOM standards handle the static foundation well. Agents need an authority record built on top of it, and treating the static layer as sufficient on its own is the mistake most organizations are currently making.

The static foundation, already well-covered by existing AIBOM standards, includes:

• Model identity, version, provenance, weights identifiers, and base model lineage.
• Training and retrieval datasets, preprocessing steps, and documented known limitations.
• Software dependencies, frameworks, libraries, and version pins.
• Hardware and compute environment, both for training and for inference.
• Governance metadata: approval history, evaluation results, compliance attestations.

The authority layer, drawn from the field set AgentRiskBOM introduces, has to sit on top of that foundation:

• Tool descriptors and risk tiers for every MCP server, API, and integration the agent can reach.
• Autonomy level: does the agent need a human sign-off before it takes an external action, or does it act on its own?
• Memory scope: what it retains, across which sessions, for how long.
• Credential scope: which identities and credentials it holds, or can acquire, once it's running.

An organization that produces both layers together, the static inventory and the authority record, can finally answer the four questions that matter: what's running, where it lives, what it can do, and who's accountable when it does something wrong. Most organizations deploying agents at scale can already answer the first two. The second two are where the real exposure sits, and a component inventory was never built to track them.