They should do both, but AI-BOM comes first when the organisation cannot reliably inventory its AI footprint. Runtime blocking is essential for containment, yet inventory and provenance tell teams what they are actually governing, which is critical for release assurance and accountability.
Why AI-BOM Comes First When You Cannot Trust the Inventory
An AI-BOM is the control point that tells you what models, datasets, packages, tools, and connected services are actually in use. If you cannot reliably inventory the footprint, runtime blocking risks becoming a blunt control applied to an incomplete picture. That makes AI-BOM work the better first move for release assurance and accountability, while blocking remains the containment layer.
A useful way to think about the sequencing is that inventory and provenance answer “what are we governing?”, while runtime blocking answers “what do we stop now?”. Those are complementary questions. The first supports change control, ownership, and evidence; the second reduces exposure when something untrusted, unapproved, or excessive is already present.
An AI-BOM also creates the basis for deciding which runtime controls are proportionate. If an organisation does not know which models, dependencies, or agents are in scope, it cannot reliably distinguish approved components from shadow usage, stale artefacts, or unsafe integrations. For that reason, AI Supply Chain Security and AI-BOM Guide is the natural place to start when the question is about sequencing rather than about a single technical safeguard.
Why Runtime Blocking Still Matters for Containment
Runtime blocking is the control that limits immediate blast radius. It can stop a risky model, deny an unapproved tool call, block a suspicious dependency, or prevent a sensitive action from being executed in production. That matters because inventory alone does not contain active misuse, and provenance alone does not stop a bad request that is already in flight.
The practical limitation is that runtime blocking works best when the allowlist, policy, or decision logic is grounded in accurate asset knowledge. If the organisation blocks first without knowing what must continue to operate, it can break legitimate services, hide exceptions inside ad hoc workarounds, or create a false sense of safety while unmanaged AI components remain active elsewhere.
That is why runtime blocking should be treated as an operational containment layer, not a substitute for asset governance. In practice, blocking is strongest when the team can tie each blocked action back to a known model, known integration, or known policy boundary. For runtime exposure in containerised or orchestrated deployments, NIST SP 800-190 Container Security is a useful companion reference because it frames how image, registry, orchestrator, and runtime controls work together.
What a Sensible Sequence Looks Like in Practice
The best order is usually inventory first, then blocking, with the two running in parallel once the baseline is good enough. Start by identifying the AI systems that matter, the inputs they consume, the tools they can reach, and the packages or services they depend on. Then use that baseline to decide what should be blocked immediately, what should be quarantined, and what should be monitored until confidence improves.
This sequence avoids a common failure mode: teams invest heavily in enforcement before they have the evidence needed to govern exceptions. It also lets security and platform teams prioritise by actual exposure rather than by assumptions about where AI is used. Where organisations already have strong asset visibility, runtime blocking can move faster; where visibility is weak, the BOM effort should lead.
For broader operational prioritisation, a control baseline such as CIS Controls v8 aligns well with the need to know what exists before trying to constrain it, especially where inventory, access control, logging, and malware defence need to work together.
Risk and Threat Considerations
The main risk in choosing only one of these approaches is asymmetry: blocking without inventory can miss shadow AI and create unmanaged exceptions, while inventory without blocking can leave active exposure in place. Attackers and careless users both benefit from that gap because untracked components are harder to govern, harder to audit, and easier to misuse.
Failure mechanism: The organisation either blocks too broadly because it lacks a trustworthy inventory, or it inventories too slowly while risky model calls, tools, or dependencies remain reachable in production.
Impact: Governance breaks down, release assurance weakens, and containment becomes incomplete. In the worst case, unapproved AI components continue to handle sensitive data or execute actions before the team can prove what was deployed and why.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-BOMs expose secret and dependency provenance needed to govern AI components safely. |
| NHI-06 — Insecure Cloud Deployment Configurations | Runtime blocking and AI-BOM sequencing depend on knowing deployed AI and platform configurations. | |
| Recommendation — Track and rotate secrets discovered through AI-BOM inventory before enforcing runtime blocks. Inventory AI deployment configurations before applying runtime deny controls. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | The question turns on whether teams can inventory AI components before enforcing runtime controls. |
| SI-4 — System Monitoring | Runtime blocking is a containment and monitoring decision for active AI use. | |
| Recommendation — Maintain a current inventory of AI components before tightening execution controls. Use monitoring to trigger blocking when AI activity exceeds approved bounds. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | AI-BOM is fundamentally an inventory-first control problem for AI assets and dependencies. |
| CIS-2 — Inventory and Control of Software Assets | AI-BOM must capture software and model dependencies before runtime restrictions are trustworthy. | |
| Recommendation — Inventory AI assets and dependencies before relying on enforcement rules. Track AI-related software assets so runtime controls target the right components. | ||
Practitioner Guidance
What to prioritise: If AI inventory is incomplete, make AI-BOM the first workstream and use runtime blocking as an immediate containment measure for clearly unsafe or unapproved paths. If inventory is already reliable, tighten blocking around the highest-risk actions first.
What to verify: Confirm that the AI-BOM covers the assets that actually create risk, including models, packages, tools, APIs, and external services, and that each blocking rule maps to a known business or technical dependency rather than a guess.
Practitioner takeaway: The right question is not whether inventory or blocking is more important in the abstract, but whether you can govern the environment confidently enough to block without breaking essential work.
Related resources from NHI Mgmt Group
- Should organisations prioritise AI inventory before blocking access to tools?
- When should organisations prioritise AI fuzzing before runtime guardrails?
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations prioritise identity governance before expanding agentic AI?