An inventory of the models, tools, adapters, and components that actually loaded and ran in an AI workload. Unlike a declared bill of materials, it reflects live system state, which is essential when components appear only at runtime or are pulled dynamically from external sources.
Expanded Definition
Runtime-Derived AI-BOM describes the evidence-backed inventory of AI assets that were actually present in execution, not just those declared in design documents. For NHI Management Group, the distinction matters because modern AI workloads can load models, adapters, tools, and other dependencies dynamically, sometimes from registries, package stores, or remote services after deployment. A runtime-derived view therefore captures the live system state that security teams need for accountability, trust, and incident response.
The concept is closely related to software and AI supply chain visibility, but it is narrower than a static bill of materials because it prioritises what executed in the active workload. Definitions vary across vendors on whether the inventory includes only directly invoked artifacts or also transitive components that were fetched and initialised during execution. There is no single standard governing this yet, so organisations should document scope explicitly and preserve evidence of collection timing. The most relevant governance anchor is the NIST Cybersecurity Framework 2.0, especially where asset visibility and risk management depend on knowing what is actually running.
The most common misapplication is treating a declared AI-BOM as runtime truth, which occurs when teams assume build-time manifests still match a workload after dynamic loading, hot-swaps, or remote tool calls.
Examples and Use Cases
Implementing Runtime-Derived AI-BOM rigorously often introduces telemetry, storage, and correlation overhead, requiring organisations to weigh visibility gains against operational complexity.
- A generative AI service pulls a third-party embedding model at startup; the runtime inventory records the exact model version, source, and checksum that actually executed.
- An agentic workflow loads tools only when a task is triggered; the AI-BOM captures the activated tools and adapters, which helps security teams confirm whether sensitive actions were reachable.
- A platform uses retrieval and routing components that change by request path; runtime evidence shows which retriever, prompt layer, or guardrail component was active for a specific incident.
- An organisation compares declared dependencies with observed runtime state to identify drift, unapproved components, or unexpected external calls during continuous monitoring.
- During a breach review, investigators reconstruct the live AI stack from logs, attestations, and workload metadata to determine whether the exposed system used a compromised adapter or model artifact.
Why It Matters for Security Teams
Security teams need Runtime-Derived AI-BOM because AI systems often fail at the boundary between declared architecture and live execution. If a model, plugin, or tool is loaded at runtime without being visible to defenders, then patching, vulnerability assessment, and trust decisions are built on incomplete data. This is especially important in agentic AI environments, where tool access can create new execution paths, secret exposure risks, and authorisation gaps. A runtime-derived inventory also supports stronger alignment with security governance expectations in the NIST Cybersecurity Framework 2.0 by making asset identification and risk response more accurate.
For identity and access teams, the term matters when non-human identities, service tokens, or tool credentials are used to fetch live components. That makes Runtime-Derived AI-BOM a practical bridge between AI security and NHI governance, because the system cannot be secured properly if the identities enabling runtime loading are unknown. Organisations typically encounter the real cost only after an incident or compliance review reveals that the AI workload was running components nobody believed were present, at which point runtime-derived inventory becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset management requires knowing what components are actually operating in the environment. |
| NIST AI RMF | The AI RMF emphasises governance and measurement of AI system risk across lifecycle states. | |
| OWASP Non-Human Identity Top 10 | Runtime-loaded tools and secrets-bearing identities create NHI governance exposure. | |
| OWASP Agentic AI Top 10 | Agentic systems can invoke tools dynamically, making live inventories essential. |
Tie runtime component discovery to the identities and credentials that enabled loading.
Related resources from NHI Mgmt Group
- When should organisations use runtime authorization for AI agents?
- What is the difference between AI agent posture management and runtime authorization?
- How should security teams govern AI agents that can take runtime response actions?
- How should security teams govern AI and workload identities at runtime?
