AI Bill of Materials for Agentic AI Systems

An AI Bill of Materials for agentic systems has to track what an agent is allowed to do as well as what it's built from. This piece makes that case, and you need to walk through why existing formats fall short, because the gap they leave open is already being exploited.

Why existing BOMs leave a critical gap when AI systems become agents

An SBOM lists software dependencies such as libraries, packages, versions, and licenses. An SBOM is useful for catching a vulnerable package like Log4Shell. That's a genuine achievement, and the AI world borrowed the idea with good reason.

The AIBOM extended this logic to machine learning. As described in the Radanliev et al. 2026 paper and in Kognitos's 2026 procurement guide, an AIBOM tracks model artifacts, training provenance, dataset lineage, and governance metadata. ML-BOM adds fields specific to machine learning models on top of that same foundation. Both formats answer a question that mattered enormously for a world of models that sit still: what is this system made of?

But once a system starts acting, that question stops being the right one. Existing BOM formats, SBOM, AIBOM, and ML-BOM, were built for passive model endpoints that take an input and return an output. Agentic systems don't work that way. They retrieve private context, call tools, write files, reach out to external services, coordinate with other agents, and in many deployments, act without a human approving each step. Existing BOM formats were built for a world of passive model endpoints, not autonomous actors, so they answer the wrong question for deployed agents, leaving unasked whether a system can send an email on its own, write to a code repository, hand a task off to another agent, or hold onto sensitive information across sessions.

Worse, an agent's capabilities aren't fixed once it's deployed. Each agent action may invoke different models, data sources, or external APIs mid-workflow; the system's effective capabilities are not fixed at deployment time. If a bill of materials lists dependencies at deployment time, it can't capture authority that shifts mid-workflow.

Capability Opacity: The Distinct Governance Gap

The gap has a name: capability opacity. It means a deployed agent's ability to access data, remember information, make changes, hand off work, and leave a record afterward has no structured account anywhere in the organization. The term comes from the AgentRiskBOM paper by Dutta and Moharir, published in June 2026 and accepted at IEEE Cyber-AI 2026. Capability opacity is the property that decides whether an agentic system can be governed at all, because a security team can't set a policy for something it can't see.

The paper breaks capability opacity into five axes, and each one maps to a question a security team or auditor would need answered before signing off on a deployment.

Access asks what data stores, APIs, and file systems an agent can actually reach while it's running, not just which dependencies show up in its code. A declared dependency and a runtime-reachable surface are two different things, and most of the risk lives in that gap⁵¹.

Memory asks what an agent holds onto, and shares, across sessions. Vector stores and long-lived context windows can carry a piece of compromised state forward into tasks that have nothing to do with where that state came from.

Change asks what an agent can write, delete, run, or set in motion inside external systems. This is the write-side blast radius: the actual damage an agent could do if its judgment or its instructions go wrong.

Delegation asks whether an agent can pass work to another agent, spawn a new one, or inherit someone else's permissions when it does. An agent that quietly inherits a service account's full access is a different animal from one scoped to a single task.

Proof asks whether anyone can reconstruct what an agent did after the fact. Without that forensic trail, an incident response team is stuck guessing at what happened instead of reading a record of it.

These five questions expose how stark the gap is next to a dependency inventory. An inventory might show you that an agent imports a browser automation library. It will not show whether that agent can send an external email without approval, run a shell command, write to a repository, keep sensitive memory around longer than it should, or delegate a fix to another agent. The AgentRiskBOM paper measured this directly: AIBOM-style views only cover about 20.9% of the risk categories that actually apply to a deployed agent. The Radanliev et al. 2026 paper on exploitability assessment makes the same point from a different angle. An exploitability score built from a static list of components can't account for the conditions under which code actually runs, the policies enforced at execution time, or the channels agents use to talk to each other.

How MCP became the surface where capability opacity turns into exploitable risk

Capability opacity stopped being a theoretical concern the moment agents started connecting to the outside world through a shared protocol, and that protocol is the Model Context Protocol, or MCP. Anthropic released MCP as an open standard in late 2024 so AI agents could connect to external tools and data sources, and it caught on fast. Microsoft, OpenAI, Google, Amazon, GitHub Copilot, VS Code, and Cursor all support it now. The protocol was built to make connecting agents to tools easy. Authentication, authorization, and sandboxing were left for each implementer to handle, and most skipped all three.

The scale of that oversight became clear in April 2026, when OX Security disclosed a systemic architectural flaw later documented in a CSA Research Note in May 2026. The disclosure pointed to roughly 200,000 vulnerable MCP instances sitting inside a supply chain that has seen hundreds of millions of package downloads. In practice, that meant MCP servers running with no authentication at all, credentials sitting in plaintext configuration files, and default network settings that exposed internal servers to the open internet.

A threat taxonomy published in 2026, known as MCP-38, catalogs four attack classes that exploit exactly this condition. Tool description poisoning alters a tool's description, not its code, so the model misreads what the tool actually does. Indirect prompt injection hides instructions inside data a tool returns, so it hijacks whatever the agent does next. Parasitic tool chaining lets a compromised tool redirect an agent toward other tools outside its approved workflow. Dynamic trust manipulation exploits the fact that one agent's output often gets treated as valid by another agent with no verification in between. Each of these attack classes lines up with one of the five axes of capability opacity: poisoning and injection exploit gaps in access and change, chaining and trust manipulation exploit gaps in delegation and proof.

These aren't hypothetical categories. Researcher Yarden Porat published an exploit chain against Anthropic's own official Git MCP server, using three CVEs, a path traversal flaw, an argument injection flaw, and a path validation bypass, to achieve remote code execution through prompt injection alone. In February 2026, Antiy CERT confirmed thousands of malicious skills circulating in the ClawHub agent-skill ecosystem, and an audit called ToxicSkills found that a meaningful share of a large sample carried at least one critical flaw, with more than a third carrying a security flaw of some severity and the associated CVE scoring 8.8 on the CVSS scale. That same month, a campaign called Sandworm_Mode combined npm typosquatting, including packages posing as Claude Code, with MCP server injection to target coding assistants such as Claude Code, Cursor, Continue, and Windsurf, installing rogue MCP servers that collected SSH keys, AWS credentials, npm tokens, and LLM API keys for later exfiltration.

Not every incident in this category runs through MCP. In August 2025, an attacker tracked as UNC6395 exploited compromised OAuth tokens from the Salesloft Drift integration with Salesforce to gain unauthorized access to customer Salesforce instances and exfiltrate data between August 8 and August 18, 2025, with no MCP server or AI agent involved, exposing support case text, contact information, and embedded credentials like AWS keys and passwords across hundreds of victim organizations. The lesson carries across both cases regardless of protocol: once a credential or a connection sits outside anyone's authority inventory, it becomes a door nobody's watching.

Why enterprise deployments are structurally unprepared for this

None of this is a niche problem limited to companies experimenting at the edges. Enterprises are rolling out agents quickly while the visibility and policy tools needed to govern what those agents can do lag well behind. So this mismatch makes capability opacity a liability across the whole organization, not a risk confined to one team's pilot project.

Part of the reason is structural. Agent identities don't follow that path. They get created by infrastructure automation, by deployment pipelines, or by application teams working on a deadline, and they skip the governance checkpoints built to catch unusual human access.

These gaps appear in a handful of recurring patterns. Static API keys and tokens often stay valid indefinitely, and no rotation schedule ties them to when the agent that used them gets retired. Agents frequently inherit the full permissions of a user or a service account instead of getting access scoped to the one task they're meant to perform. New agents get spawned by other workloads and never register with the identity provider that's supposed to track every identity in the system. Access granted for a three-week pilot stays active long after the pilot wraps, because nothing was set to expire it.

None of these conditions appear in an SBOM or an AIBOM because they aren't components anyone declared, but runtime states that exist only in production, invisible to any inventory built to describe what software is made of rather than what it's doing.

What an AI BOM for Agents Must Inventory

Closing the capability opacity gap means building a bill of materials that records runtime authority: not just which components are present, but what an agent is permitted to do with them, under what limits, and with what evidence to back it up. That record has to be machine-readable and it has to track changes over time, because an agent's authority shifts as its workflow runs.

The AgentRiskBOM schema from Dutta and Moharir lays out the fields a document like this needs, and together they cover ground no prior BOM format was built to hold. Every production agent needs its own identity record: a unique identifier, a named owner, an approved purpose, a defined trust level, a documented lifecycle state, and details on its credentials and when they expire. The schema also calls for a record of tool permissions, listing which tools an agent can call, how risky each one is rated, and whether a human has to sign off before the call goes through. It tracks autonomy level, meaning how much an agent can do without a person stepping in, and the conditions under which that changes. It covers memory and data sources, including the vector stores and retrieval pipelines an agent draws on and what it keeps across sessions. It specifies credential scope, so each agent's access narrows down to the exact resources a task requires rather than assuming broader access is harmless, and that scoping decision alone can limit potential damage more than almost any other control. It records approval gates, the explicit points where a human has to review before the agent moves forward, and audit signals, meaning what the agent logs, in what format, and whether those logs can be tampered with after the fact. It accounts for inter-agent communication, tracking whether an agent delegates work to others or takes instructions from them, and external action capability, covering what the agent can actually trigger outside itself, sending an email, writing a file, calling an API, or running code. It maps declared authority to the security controls that enforce it, and it references the SBOM, AIBOM, and ML-BOM artifacts already in place instead of duplicating fields those formats already own.

A companion paper on Agentic Configuration Management, published by Audrey Quessada-Vial of PwC in August 2026, arrives at a similar list from a different discipline. It argues that agentic systems need configuration items that can't be silently altered, explicit baselines to measure against, formal lifecycle management, and the ability to trace how a change in one part of a system ripples into dependent parts, none of which current LLMOps or AgentOps platforms provide on their own, across frameworks. The Radanliev et al. Frontiers AI paper adds one more requirement on the vulnerability side: the BOM has to bind declared components to what's actually observed at runtime and to the execution policies actually enforced, so that an exploitability assessment reflects real conditions instead of a static snapshot taken at deployment.

Taken together, these three research efforts converge on the same conclusion from three different angles: security, configuration management, and vulnerability assessment. An inventory of what a system is built from was never going to answer the question that matters once that system can act on its own. Until what it's allowed to do has a structured answer, capability opacity will keep being the gap attackers find first.