# How CISOs Should Prep for Agentic-Ready AI Bills of Materials


As AI systems move from static models to autonomous agents capable of taking independent actions, security teams face a documentation crisis. Traditional AI bills of materials—the inventories of models, datasets, and dependencies that power AI systems—no longer capture the full risk picture. The new challenge isn't just *what's in* the AI; it's *what the AI can do*. And documenting that requires a fundamental rethinking of how organizations track and govern AI supply chain risk.


## The AI Bill of Materials Movement


Over the past two years, AI bills of materials (AI BOMs) have emerged as a critical security practice, mirroring the well-established software bill of materials (SBOM) approach. Like SBOMs, AI BOMs document the complete inventory of components that build a system: the foundation models, training datasets, frameworks, dependencies, and external tools. This transparency serves a straightforward purpose: when a vulnerability is discovered in a component, organizations need to know which systems are affected and how quickly they need to respond.


The concept gained momentum as supply chain risk became increasingly tangible. The compromise of a popular open-source ML library or the discovery of biased training data could ripple across dozens of organizations. Having a clear manifest of what goes into each system became not just good practice—it became necessary for risk management.


Standards bodies stepped up. CycloneDX and SPDX (Software Package Data Exchange) extended their frameworks to cover AI components. Regulators began asking organizations to inventory their AI systems. The OWASP AIBOM Generator provided tools for automated documentation.


But these approaches were built for a world of static AI—systems that run inference on inputs and produce outputs. Today's AI landscape is fundamentally different.


## The Agentic AI Problem: Execution Changes Everything


Agentic AI systems operate under different rules. These are AI agents that make autonomous decisions, take independent actions, and interact with external systems without human approval at each step. An AI agent might autonomously invoke APIs, access databases, send communications, or provision infrastructure—all based on its interpretation of natural language instructions and its available tools.


This creates a documentation problem that BOMs were never designed to solve.


"With delegated agency, the most security-relevant dependencies are not model plus data — instead they become action pathways," explains Kriti Tallam, VP of AI at Kamiwaza AI and contributor to NIST's AI Risk Management Framework. "What you're talking about is behavioral artifacts: tool skills, prompts, policies, and workflow definitions."


A traditional SBOM tells you what libraries a system uses. But if that system is an autonomous agent, knowing the libraries isn't enough. You need to know:


  • What tools can the agent invoke? (API integrations, database connections, file system access)
  • What are the constraints on agent behavior? (policies, guardrails, decision boundaries)
  • What prompts guide agent decisions? (jailbreak-susceptible instructions, decision frameworks)
  • What workflows can the agent execute? (approved action sequences, escalation rules)

    • The risk shifts from *supply chain compromise* (someone poisoning a dataset or library) to *behavioral compromise* (an agent being manipulated into actions it shouldn't take, or having its capabilities abused).


    ## The Artifact vs. Authority Problem


    Current AI BOM standards excel at documenting artifact lineage: the complete genealogy of every component that went into building the system. But they're largely blind to authority lineage: the runtime policies, permissions, and behavioral constraints that govern what an agent actually *does* with those components.


    Helen Oakley, one of the leaders of the OWASP AIBOM Generator initiative, identifies this as the critical gap: "Documentation now covers two main areas, artifact lineage and authority lineage. The first asks what went into building the system; the second asks what authority that system has been granted and what constraints limit that authority."


    Consider a practical example: Two organizations both deploy Claude 3.5 Sonnet as the foundation for an autonomous customer service agent. Their artifact lineage is identical—same model, same frameworks, same dependencies. But one organization:


  • Grants the agent access to customer refund APIs
  • Allows it to modify account settings without human approval
  • Provides instructions that prioritize customer satisfaction over policy compliance

    • The other:


  • Limits the agent to read-only database access
  • Requires human approval for any action over $50
  • Uses explicit policies that prohibit policy override

    • The artifacts are the same. The risk profiles are entirely different. Without documenting authority lineage—the tools, policies, and constraints—a BOM provides false equivalence.


    ## What Needs to Be Documented


    Organizations preparing for agentic-ready AI BOMs should be prepared to document:


    | Category | Examples | Security Relevance |

    |----------|----------|-------------------|

    | Tool Capabilities | APIs, databases, file systems, email, APIs | Defines what actions the agent can take |

    | Prompt Artifacts | System prompts, user-facing instructions, decision frameworks | Can be manipulated; subject to injection attacks |

    | Policy Definitions | Approval workflows, escalation rules, spending limits | Governs when and how agent can act autonomously |

    | Access Controls | Credentials, API keys, role-based permissions | Determines scope of agent authority |

    | Monitoring & Logging | What behaviors are logged, alerting rules, audit trails | Critical for detecting compromise or misuse |

    | Failure Modes | What the agent does if uncertain, error handling behavior | Can be exploited; needs explicit documentation |


    ## Current Standards and the Gap


    CycloneDX and SPDX provide excellent frameworks for documenting models, datasets, and software dependencies. NIST's AI Risk Management Framework offers governance structures. But none of these were designed to capture the behavioral dimension that agentic systems introduce.


    The emerging consensus: standards need to evolve to document not just *what went into* the system, but *what the system is authorized to do* and *what guardrails constrain that authority*. This requires:


  • Extension of existing standards to include behavioral artifacts
  • New metadata schemas for policies, permissions, and tool definitions
  • Execution-time logging that captures agent behavior and decisions
  • Authority auditing that tracks changes to agent capabilities and constraints

    • ## What CISOs Should Do Now


    The agentic AI rollout is still in early stages, but the security landscape is hardening. Organizations should begin:


    ### 1. Establish Baseline Documentation

    Start documenting AI BOMs for existing systems using CycloneDX or SPDX. This creates a foundation and builds organizational muscle memory for the practice.


    ### 2. Map Agent Capabilities and Constraints

    For any autonomous AI system already in production, immediately catalog:

  • What external systems can it access?
  • What decisions does it make autonomously vs. with human approval?
  • What policies and guardrails are in place?
  • How are agent actions logged and monitored?

    • ### 3. Participate in Standards Evolution

    Engage with OWASP, NIST, and standards bodies as they extend frameworks for agentic systems. The standards that stick will be shaped by early input from security practitioners.


    ### 4. Design for Authority Auditability

    When deploying new agentic systems, build in explicit logging and visibility into:

  • What tools the agent invoked and when
  • What decisions it made and why (prompt context, reasoning)
  • What guardrails prevented it from acting in certain ways
  • How its authorized capabilities changed over time

    • ### 5. Plan for Behavioral Drift Detection

    Establish monitoring that can detect when agent behavior changes unexpectedly—not just crashing or errors, but subtle shifts in decision patterns that might indicate compromise or manipulation.


    ## Implications for the Broader Security Landscape


    The rise of agentic AI BOMs signals a maturation of AI governance. It moves beyond *"tell us what models you're using"* to *"prove to us that you can control what your systems do."* This is significantly harder, which is why the challenge matters.


    It also reveals a structural gap in current AI governance: the difference between *component safety* (is the model trustworthy?) and *behavioral safety* (is the system authorized and constrained appropriately?). The former has received most of the attention; the latter is where real security risks lie.


    ---


    ## HackWire Analysis


    The focus on AI BOMs reflects an implicit shift in where security teams think the risk lives. For the past two years, the conversation centered on model poisoning, data poisoning, and supply chain attacks on training infrastructure. Those threats remain real. But the practical risk of deployed agentic systems is more mundane and more dangerous: an AI agent doing exactly what it was authorized to do, but under abnormal conditions—manipulated by a prompt injection, operating under a typo in its policy definition, or granted capabilities that were reasonable in isolation but dangerous in combination.


    This is where authority lineage matters. A detailed record of what an agent can do and why becomes the evidence trail both for audit purposes and for incident response. When an agent causes unexpected damage, the first question is always: "What was it authorized to do?" If that answer isn't documented in binding terms, you've already lost.


    The practical urgency is also underestimated. Standards bodies move slowly. But agentic AI deployments are moving fast. Organizations shouldn't wait for perfect standards—they should start documenting authority lineage now, in whatever format works for their risk model, knowing that standards will eventually catch up. The organizations that build documentation discipline early will be the ones that can demonstrate control when regulators or customers demand proof.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Tools](https://www.hackwire.news/category/tools) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)