Start by registering AI assets at the point of deployment, not in a quarterly spreadsheet review. Capture owner, risk tier, data access, lifecycle stage and framework dependencies from the same code and release artefacts that create the system. Then reconcile the inventory against live discovery so shadow AI and orphaned agents surface as exceptions, not assumptions.
Why This Matters for Security Teams
An AI model or agent inventory is only useful if it reflects what is actually running, what data it can touch, and which identities can act on its behalf. For AI systems, that means inventory is not a documentation exercise. It is the control plane for exposure management, privilege review, incident response, and change governance. The The State of Non-Human Identity Security research shows how weak visibility and over-privilege remain common failure points across NHIs, which maps directly to AI systems that inherit secrets, tokens, and service accounts.
Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 treats inventory as a prerequisite for governance because teams cannot secure what they cannot enumerate. That is especially true for shadow AI, experimental copilots, and orphaned agents that outlive the pipeline that created them. In practice, many security teams discover these systems only after a secret leaks, a workflow fails, or an unexpected agent starts using production data.
How It Works in Practice
Security teams should build the inventory from deployment and runtime sources, not from periodic manual review. The most reliable starting point is the system of record that creates the asset: CI/CD pipelines, model registries, agent orchestration configs, infrastructure-as-code, and identity issuance logs. Each record should capture the minimum operational fields needed for governance: owner, business purpose, model or agent type, deployment environment, data classification, permission scope, lifecycle stage, and dependency chain. That includes the identities and secrets used by the system, because model risk and NHI risk usually travel together.
For agentic systems, the inventory should also capture tool access and execution authority. An agent that can call APIs, invoke code, or chain tasks is not just a model artifact. It is an active workload with runtime privilege, and the inventory should show that clearly. Pair the static registry with live discovery from cloud logs, API gateways, identity providers, secret scanners, and workload telemetry so the team can reconcile what was approved against what is actually in use. NHIMG has documented how compromised NHIs enable rapid abuse, including the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research, which makes a strong case for treating inventory drift as a security event, not an admin task.
- Register the asset at deployment time, then update it automatically as the pipeline changes.
- Link each model or agent to its workload identity, secret source, and token TTL.
- Tag the data sources and tools it can access, including third-party connectors and service accounts.
- Reconcile the registry against live discovery to surface shadow AI and orphaned agents as exceptions.
Where possible, tie inventory entries to the same release artefacts that define policy, so changes in code, prompts, tools, or credentials trigger review. These controls tend to break down in highly dynamic environments with ephemeral environments, unmanaged SaaS copilots, or decentralized experimentation because the asset is created faster than ownership and telemetry can be assigned.
Common Variations and Edge Cases
Tighter inventory controls often increase release friction, requiring organisations to balance operational speed against governance fidelity. That tradeoff becomes most visible in research labs, prompt-driven prototyping, and multi-team platform environments where model versions and agent tools change daily. Current guidance suggests using progressive enrichment: start with a minimal record at deployment, then add runtime context as telemetry and approvals become available. There is no universal standard for this yet, so teams should be explicit about which fields are mandatory versus optional.
Edge cases matter. A single agent may inherit multiple identities, such as a cloud role, an API key, and a user-delegated OAuth token. A model may be deployed once but consumed through several wrappers, each with different data access and risk. External visibility is also often incomplete; NHIMG research on The State of Non-Human Identity Security highlights major visibility gaps around connected systems, which is why inventories should include third-party integrations and delegated access paths. For implementation detail, teams can align the inventory with the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework so the inventory supports both risk review and control assignment.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Inventory accuracy depends on knowing every non-human identity tied to models and agents. |
| OWASP Agentic AI Top 10 | Agent inventories must track tool access, autonomy, and runtime authority, not just model names. | |
| NIST AI RMF | AI RMF governance requires traceable inventory inputs to assign accountability and monitor risk. |
Maintain an authoritative NHI register and reconcile it continuously against live identity and secret sources.
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
