Should AI agent governance sit in IAM, IGA or runtime authorization?

How the control layers actually divide

AI agent governance is not a single control point. IAM gives the agent a defined identity and a way to authenticate, IGA governs ownership, registration, approval, review and lifecycle, and runtime authorization decides whether a specific action is allowed in the moment. That last layer is decisive because it can stop an unsafe request even when the identity record and governance process are both correct.

Put differently, IAM answers who or what the agent is, IGA answers who is accountable for it and what it should be allowed to do in principle, and runtime authorization answers whether this exact call, with this context, should proceed now. That separation matters because AI agents make high-frequency, context-sensitive requests that cannot be safely governed by periodic documentation alone.

For the identity side of that split, NHI guidance on Identity Governance for AI Agents Guide is useful because it treats agent ownership, lifecycle and offboarding as operational controls rather than paperwork. The same logic underpins AI Agent Identity Security Buyer's Guide, which helps teams separate identity creation from the decision to let an agent act.

Why runtime authorization is the decisive layer

Runtime authorization is where policy meets actual behaviour. It can evaluate the requesting agent, the tool or resource being targeted, the action being attempted, the data sensitivity involved and the current context such as environment, time, workflow state or human approval status. That is what makes it the preventive control, rather than a registry or review step that only describes how the agent should behave.

This is especially important when an agent has broad standing access or can compose multiple tool calls. The governance record may say the agent exists for a narrow purpose, but the runtime layer still has to reject requests that exceed that purpose. Without per-request policy enforcement, an agent can drift from approved scope without any change to the underlying identity record.

NHIMG’s AI Agent Authorisation Guide is the clearest match for this control layer because it focuses on least privilege, task-scoped access and per-action policy decisions. For teams building policy engines, Zero Trust for AI Agents is the practical companion: verify the principal, the request and the intended action every time, not just at enrolment.

How to avoid an all-document, no-enforcement programme

A common failure mode is to treat IAM and IGA as if they were sufficient because the agent is inventoried, approved and assigned an owner. That leaves a gap between intent and execution. If runtime policy is weak, a compliant-looking agent can still overreach, misuse tools, or escalate from a benign task into a damaging one through chained actions.

Another trap is to rely on coarse allowlists or one-time approval for a class of agent activity. That may work for stable service identities, but it is too blunt for agentic systems that vary by prompt, context and downstream tool selection. The governance model needs a runtime choke point that can enforce context-aware decisions and make those decisions auditable.

For teams that need to see how real failures emerge, AI Agent Observability, Audit and Incident Response Guide helps connect authorization failures to logs, attribution and kill-switch design. When agents can act in production, detection and revocation are part of the same control story as authorization.

Practitioner Guidance

What to prioritise: Place runtime authorization closest to the action path, then use IAM to establish a distinct agent identity and IGA to define ownership, purpose and review cadence. If you only improve the directory or approval workflow, you will still miss unsafe per-request behaviour.

What to verify: Confirm that the policy engine can distinguish the requesting agent, the target resource, the tool being invoked and the current context. If it cannot evaluate all four, it is probably too weak to be the decisive control for agent governance.

Decision rule: If an agent can cause material impact by a single request, treat runtime authorization as mandatory rather than optional, and use IAM and IGA as enabling layers that feed it with trustworthy identity and lifecycle data.

Practitioner takeaway: The governance programme should be built so that IAM names the agent, IGA owns the agent, and runtime authorization constrains the agent; only the last layer prevents harmful action in real time.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• What is the difference between human IAM controls and NHI governance?