How should security and IAM teams divide responsibility for AI inventory governance?

How to split AI inventory governance between security and IAM

ai inventory governance works best when security owns the control plane and IAM owns the identity plane. Security should decide what counts as an AI surface, where it is discovered, how it is classified, and what evidence proves it is approved. IAM should trace who or what can use it, which keys or delegated grants exist, and where project-level permissions create actual reach.

That division matters because an AI system can look “known” in an asset list while still being operationally reachable through forgotten OAuth grants, service principals, API keys, or overly broad project permissions. For teams building discovery and ownership rules, the Identity Security Programme Guide is useful for framing a shared operating model across governance, ownership, and evidence.

What security teams should own in the inventory process

Security teams should own the inventory boundary, meaning the rules for discovery, scoping, classification, and approval. They are the team that can answer whether a model, copilot, agent, AI feature, or third-party AI app belongs on the inventory at all, whether it is sanctioned, and whether it introduces a new control surface for monitoring, logging, or incident response.

This also means security should define the minimum evidence required for an item to be considered managed. For example, an AI surface should not be treated as governed just because someone named it in a spreadsheet; there should be a source signal, an owner, a business purpose, and a reviewable control state. The Shadow AI and AI Agent Discovery Guide maps well to this discovery-and-classification responsibility.

Security also owns the exception logic. If an AI capability is approved but not fully integrated into the standard platform stack, security should decide what compensating controls are acceptable, whether the item is time-limited, and what condition would force removal from the approved inventory. That is the control boundary IAM should not be asked to invent on its own.

What IAM teams should own in the inventory process

IAM teams should own the access boundary, not the full AI inventory. Their job is to map the identities, secrets, delegated grants, and permission paths that make an AI surface usable. In practice, that means identifying service accounts, OAuth applications, API keys, workload identities, project roles, and admin grants that let the AI system call data, tools, or downstream services.

IAM should also normalize how access is described so the inventory can answer practical questions such as who owns the credential, whether the credential can be rotated, whether the permission is inherited, and whether the access path is human-initiated or delegated. Without this layer, an inventory may capture the AI application name but miss the real mechanism that gives it reach.

For teams dealing with service accounts, workload identities, and delegated access, the Ultimate Guide to NHIs, What are Non-Human Identities is a direct reference point for the kinds of identities that often sit behind AI systems.

IAM should also own lifecycle linkage. If an AI project is retired, paused, or moved between environments, the associated access paths need to be reviewed, not just the application record. That is the difference between a static inventory and an operational one.

Where the shared evidence model has to connect the two

The shared evidence model is the bridge between “we know it exists” and “we know how it can act.” Security evidence should show what the AI surface is, why it is approved, and what business process it supports. IAM evidence should show which principals, tokens, keys, or delegated grants are attached to it, what they can reach, and whether that access is still justified.

That shared model is especially important when a team wants one view of all AI systems but different control owners are collecting different facts. Security usually sees the service, product, or use case first. IAM usually sees the permission and credential trail first. The inventory is only trustworthy when both views are joined at the same object and can be reconciled during review.

Where teams need a concrete operating reference for governance and lifecycle, the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs, Regulatory and Audit Perspectives help anchor the lifecycle and audit questions that inventory governance must answer.

Risk and Threat Considerations

The main failure mode is a split-brain inventory: security believes the AI surface is governed, while IAM still shows active credentials, delegated consent, or privileged project access. That gap creates hidden reach, weak auditability, and a path for untracked use, especially when AI tools are added through SaaS integrations or self-service experimentation.

Failure mechanism: discovery without identity context leaves the team blind to how an AI surface actually authenticates, inherits privilege, or persists after a project change, so access remains active even after the business owner believes the system is contained.

Impact: unmanaged reach can lead to data exposure, unauthorized tool use, excessive privilege, delayed offboarding, and poor incident response because responders cannot quickly tell which identities or grants need to be revoked.

Practitioner Guidance

What to prioritise: define one inventory record per AI surface, then attach the identity evidence to it. If an item cannot show owner, purpose, and access path, it is not ready to be treated as governed inventory.

What to verify: confirm that every approved AI entry has a mapped principal, a listed credential or delegated grant, and a revocation path. If IAM cannot prove how access is removed, the inventory is only descriptive, not operational.

Practitioner takeaway: security should govern the object, IAM should govern the reach, and both teams should be measured on whether their combined evidence can answer “what is it, who can use it, and how do we turn that off?”

Related resources from NHI Mgmt Group

• How should IAM and AI governance teams divide responsibility for derived content?
• How should security teams use IAST and RASP in NHI governance?
• Why is single-provider AI agent governance not enough for enterprise security?
• How should security teams handle risks from AI browser extensions?