Exclusion claims become weak, ownership becomes unclear, and validation gaps stay hidden until an examiner or incident exposes them. Teams then cannot prove whether the system was in scope, who approved it, or whether it was monitored at all. A missing inventory entry is therefore a governance failure, not just an administrative miss.
Why This Matters for Security Teams
When model inventories stop at classic applications and ignore LLMs plus agentic workflows, the organisation loses the basic evidence needed for governance. That gap affects risk acceptance, change approval, incident response, and audit readiness. It also makes it difficult to show whether a system was evaluated for prompt injection, tool abuse, training data exposure, or unsafe autonomous actions. Guidance from the NIST AI Risk Management Framework makes clear that trustworthy AI starts with visibility into what is being built and operated, not after deployment.
The operational issue is broader than documentation. If an LLM is embedded in a customer workflow, a knowledge assistant, or an internal automation chain, it can inherit business impact without being treated like a managed system. Agentic workflows add another layer because they can call tools, move data, and take actions across boundaries that traditional asset registers were never designed to capture. That leaves security, legal, and operations teams arguing over ownership instead of testing controls. In practice, many security teams encounter the absence of AI scope only after an incident, a regulator question, or a failed control review has already exposed it.
How It Works in Practice
A useful inventory for AI systems has to record more than model name and environment. It should identify the LLM, the workflow that wraps it, the tools it can use, the data sources it can reach, and the approvals tied to those capabilities. The same record should show whether the system is prompted directly by users, orchestrated through a workflow engine, or operating with delegated execution authority. This is where the OWASP Top 10 for Agentic Applications 2026 is especially useful, because it highlights the kinds of failures that appear when autonomy, memory, and tool access are not clearly bounded.
In practice, security teams should make the inventory answer four questions:
- What model or service is in use, and who owns it?
- What workflow or agent layer invokes it, and with what permissions?
- What data enters the prompt, retrieval layer, or tool chain?
- What controls validate output, log actions, and block unsafe execution?
That inventory should also support threat modelling and control testing. The MITRE ATLAS adversarial AI threat matrix helps teams map attack paths such as poisoning, evasion, and exploitation of model-driven decisions, while the CSA MAESTRO agentic AI threat modeling framework is useful where autonomous workflows need clearer control boundaries. The inventory should feed change management so new tools, prompts, and integrations cannot bypass review. These controls tend to break down when AI capabilities are embedded inside business automation platforms because the model layer is treated as a feature, not a managed system.
Common Variations and Edge Cases
Tighter inventory controls often increase operational overhead, requiring organisations to balance governance value against delivery speed. That tradeoff is real, especially where teams are experimenting with multiple models, retrieval sources, and vendor-managed agents. Best practice is evolving, but the current guidance suggests that a minimal entry is not enough when the system can access production data or initiate actions.
There are also edge cases where the boundary is disputed. A simple chat interface may look harmless until it is connected to internal documents, ticketing systems, or SaaS admin tools. Likewise, a workflow may not be branded as an “agent” but still exhibits agentic behaviour if it can plan, call tools, and persist state. In those cases, the inventory should follow capability, not marketing labels. The NIST AI 600-1 Generative AI Profile is useful for aligning documentation, testing, and monitoring around generative AI-specific risk, while the NIST AI Risk Management Framework remains the better anchor for governance structure overall. Current guidance suggests the inventory should include AI systems even when procurement, development, or operations teams disagree on whether the tool is “really” a model or an agent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI governance depends on knowing which systems exist and who is accountable for them. | |
| OWASP Agentic AI Top 10 | Agentic workflows create tool, memory, and autonomy risks that inventories must capture. | |
| MITRE ATLAS | Threat modelling AI systems requires visibility into model and workflow attack surfaces. | |
| CSA MAESTRO | MAESTRO helps define controls for autonomous AI workflows and their dependencies. | |
| NIST AI 600-1 | GenAI systems need specific documentation and monitoring beyond generic application records. |
Apply the GenAI profile to track prompts, retrieval sources, outputs, and monitoring controls.
