Why do AI-BOMs matter when organisations already have software inventories?

Why This Matters for Security Teams

Software inventories tell teams what is installed. AI-BOMs tell teams what an AI system can actually touch at runtime, including models, datasets, prompts, connectors, tool permissions, and downstream services. That distinction matters because governance failures in AI rarely begin with a missing package name. They begin when an approved system can reach sensitive data, invoke external tools, or chain actions beyond the original design boundary.

This is why current guidance increasingly treats AI supply chain visibility as a control problem, not a documentation exercise. A conventional inventory may satisfy asset tracking, but it does not reveal whether a model is connected to customer records, a ticketing API, or a secrets store. The Top 10 NHI Issues research consistently shows that unmanaged identity relationships create the conditions for misuse, and AI systems amplify that risk because their reach changes with configuration.

The NIST Cybersecurity Framework 2.0 helps frame the issue: know what exists, know how it is used, and manage exposure continuously. In practice, many security teams discover AI reachability only after a model has already been connected to sensitive workflows, rather than through intentional design review.

How It Works in Practice

An AI-BOM extends the idea of a software bill of materials into the runtime realities of AI systems. For practitioners, that means tracking more than code and library versions. A usable AI-BOM typically records model provenance, training or fine-tuning data sources, system prompts, embedded policies, connectors, agent tools, service accounts, secrets dependencies, and the permissions those components inherit. That inventory should also reflect whether the system operates as a static chatbot or as an autonomous NHI Lifecycle Management Guide lifecycle-managed workload with changing access paths.

The operational value comes from linking inventory to governance decisions. If a model can call an internal API, the AI-BOM should show which identity authenticates that call, what scope it has, and whether the access is persistent or just-in-time. If a dataset contains regulated or sensitive material, the AI-BOM should make that relationship visible before deployment, not after incident response. This is also where AI-BOMs differ from traditional asset registers: they are meant to support control verification, impact analysis, and change review.

• Use the AI-BOM to map every model, dataset, connector, and tool to an accountable owner.
• Record runtime permissions, not just build-time dependencies, especially for agentic systems.
• Update the AI-BOM when prompts, tools, or data sources change, because those changes alter exposure.
• Cross-check the AI-BOM against secrets, access reviews, and deployment pipelines to catch hidden reachability.

This approach aligns with broader supply chain and risk management thinking in NIST Cybersecurity Framework 2.0, but current guidance suggests there is no universal standard for exactly how detailed an AI-BOM must be. The practical goal is to answer one question reliably: what can this AI system reach, with what authority, and through which dependencies? These controls tend to break down when teams treat agent tools and service identities as implementation details because that hides the actual blast radius.

Common Variations and Edge Cases

Tighter AI-BOM requirements often increase operational overhead, requiring organisations to balance visibility against delivery speed. That tradeoff is most visible in fast-moving AI teams that reuse models, swap connectors frequently, or rely on managed services where underlying components are abstracted away.

For simple, non-autonomous AI features, a lighter AI-BOM may be enough if the system has no meaningful data access or external action capability. For agentic workflows, best practice is evolving toward deeper runtime mapping because the same model may behave safely in one environment and dangerously in another once tool access changes. The Ultimate Guide to NHIs is useful here because the same identity governance gaps that affect service accounts also affect AI workloads that act on behalf of the organisation.

Another edge case is third-party AI services. When the provider does not expose enough detail for a full AI-BOM, teams should document the known boundaries, the contractual assurances, and the remaining unknowns. That is not perfect governance, but it is better than assuming the vendor abstraction removes risk. In highly regulated environments, the DeepSeek breach example shows why hidden data and dependency paths matter. These controls tend to break down when organisations cannot verify provider-side runtime relationships because the AI-BOM becomes incomplete exactly where assurance is most needed.

Related resources from NHI Mgmt Group

• Why does identity strategy matter more as organisations scale cloud and AI adoption?
• How can organisations reduce risk from shadow AI agents already inside the enterprise?
• Should organisations change procurement criteria for AI-native software?
• Should organisations treat AI coding agents like privileged software identities?