Runtime authorization for AI agents needs two control planes

At a glance

What this is: NHI Mgmt Group's analysis, drawing on EnforceAuth's research: AI agent control is converging on two separate planes, one for access retention and one for per-action authorization.

Why it matters: IAM, PAM, and NHI teams need to treat agent access revocation and transaction permissioning as different governance problems, or they will leave a policy gap at runtime.

Context

AI agent authorization now needs a plain distinction between access control and transaction control. One decides whether an identity keeps access at all, while the other decides whether a specific action is allowed inside the application or workflow.

The problem for identity programmes is that these controls are often described with the same runtime language, yet they answer different questions. For NHI governance, agentic AI identity, and broader IAM architecture, the design choice is whether risk signals, policy rules, or both govern the action path.

Key questions

Q: How should teams design AI agent controls when access retention and action approval are different problems?

A: Treat access retention and action approval as separate controls. Use detection and risk signals to decide whether an identity should keep access, but use policy at the resource boundary to decide whether a specific action is allowed. If you collapse the two, clean-risk agents can still execute unauthorized business actions.

Q: Why do AI agents need policy-based authorization even when detection is in place?

A: Detection can identify suspicious behaviour, but it cannot decide whether a specific business action is allowed under tenant rules, delegated authority, or segregation of duties. When the action itself is the control point, only deterministic policy evaluation can prevent a permitted-looking but forbidden transaction.

Q: What breaks when runtime authorization is handled only through access revocation?

A: You can shorten the lifetime of a compromised or risky session, but you still cannot stop the first unauthorized action if the identity is currently clean-risk. That leaves a gap between compromise detection and business-rule enforcement, especially for agentic workflows that act at machine speed.

Q: How should teams govern delegated AI agent actions without losing attribution?

A: Use a separate runtime identity for the agent and tie it to the sponsoring human in the audit trail. That lets teams answer who authorised the action, which agent executed it, and which system was touched without collapsing everything into one user session.

Technical breakdown

Access retention versus transaction authorization

Access retention is an identity-level decision: should the agent retain a session, token, or entitlement after new risk appears? Transaction authorization is an action-level decision: is this exact invocation, with these parameters and this application state, permitted? Those two decisions use different inputs, different timing, and different evidence. A risk engine can revoke or step up access based on telemetry, but it does not inspect the business meaning of the action itself. A policy engine evaluates the action against rules and context at commit time, which is a different control plane rather than a stronger version of the first.

Practical implication: separate revocation logic from action authorization logic in your agent governance model.

Why runtime enforcement needs a resource-side decision point

Where the enforcement point sits determines what context the system can actually see. Interaction-layer controls see prompts, responses, and traffic patterns, which is useful for detection and session risk. Resource-side authorization sees the application state, tenant boundaries, segregation of duties constraints, delegated authority, and the target record at decision time. That is why policy-as-code at the resource can make a deterministic allow or deny call, while a detector cannot. In agentic systems, placement is not an implementation detail; it defines the decision boundary.

Practical implication: place policy decisions close to the resource when the rule depends on application state or delegated authority.

Delegation chains and evidence artifacts in AI agent systems

Agent-to-sub-agent delegation introduces a governance problem that telemetry alone cannot solve. A provenance-aware system can show who owned or invoked the chain, but it still cannot enforce attenuation, depth limits, or forbidden capability combinations without evaluating policy at each hop. The other major difference is evidence. Detection systems produce signals and risk scores, while deterministic authorization produces a decision record tied to a specific policy version and action. That record is what audit and control validation can actually use.

Practical implication: require per-hop policy evaluation and immutable decision records for delegated agent actions.

NHI Mgmt Group analysis

Two runtime control planes are now the right model for agentic governance: one governs whether an identity retains access, and the other governs whether a specific action is permitted. Those are not interchangeable decisions, even when they are delivered through similar control-plane language. For practitioners, the architectural mistake is collapsing risk-adaptive access management and transaction authorization into one layer.

Identity review cadences do not solve action-level authority in agentic systems: revocation can shorten the lifetime of a bad session, but it cannot prevent the first unauthorized action of a clean-risk agent. That is a control-plane mismatch, not a tuning problem. The implication is that runtime policy must move into the execution path whenever business context matters.

Resource-side authorization is the only credible answer to business context at commit time: delegation, segregation of duties, tenant boundaries, and application state are not telemetry attributes. They are authorization facts. This is why policy evaluation at the resource is the governance anchor for agentic workloads, especially when the same identity can chain actions across systems.

Decision records matter as much as decision logic: a runtime control that cannot prove which policy version approved or denied an action cannot support audit, forensics, or control validation. In agentic architectures, evidence needs to be action-specific rather than session-specific. Practitioners should treat immutable authorization records as a first-class governance output, not a side effect.

Agentic AI identity creates an authorization gap when teams only instrument detection: continuous risk signals are necessary, but they do not answer whether the business rule allowed the action. The named concept here is the authorization gap, where a system can detect danger without being able to decide permission. Closing that gap is now an architecture problem, not a dashboard problem.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Authorization gap: AI agent programmes that rely on continuous detection but stop short of deterministic policy enforcement will keep finding risk after the fact. The governance problem is not visibility alone; it is whether the runtime can decide permission before the write lands, especially when delegated authority crosses tenant or application boundaries.

Risk-adaptive access and transaction authorization should be tracked as separate control objectives in your operating model. If a programme cannot explain who can revoke access, who can deny a specific action, and what evidence proves the decision, it does not yet have a complete agentic control plane.

For agentic AI governance, the practical signal is simple: if your controls can describe session risk but not commit-time authority, you still have an unclosed authorization boundary.

For practitioners

• Separate access retention from action permissioning Define one control path for revoking or retaining agent sessions and a different one for evaluating whether each business action is allowed. Do not let risk scoring substitute for policy decisions at commit time.
• Move business-rule decisions to the resource boundary Evaluate tenant scope, segregation of duties, delegated authority, and application state where the write or mutation happens, not only where the prompt is observed.
• Treat delegation as a policy problem per hop Check whether each delegated step narrows authority, preserves provenance, and blocks forbidden combinations of capabilities across sub-agents.
• Require immutable decision records Capture the policy version, input context, and allow or deny result for each action so audit and incident review can reconstruct the exact runtime decision.
• Test fail-closed behavior for privileged writes Validate that the system denies high-risk writes when policy evaluation or context resolution is unavailable, instead of silently falling back to detection-only controls.

Key takeaways

• AI agent governance now splits into two runtime questions, whether access should continue and whether a specific action should be allowed.
• Detection can reduce exposure, but it cannot replace policy when the decision depends on business context, delegation, or application state.
• A complete agentic control model needs both revocation and deterministic authorization, plus evidence that proves each decision.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Access retention: Access retention is the decision about whether an identity should keep a session, token, credential, or entitlement after new risk information appears. It is an identity-level control, distinct from deciding whether one transaction or write is permitted.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Delegation Provenance: Delegation provenance is the evidence chain that shows who authorised an action, what authority was granted, and what the agent actually did. It is essential when the acting identity and the accountable identity are not the same. Without it, audit and fraud review become opinion rather than proof.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.