TL;DR: Static authorization preserves yesterday’s assumptions, while runtime authorization decides each request against live policy and context, a distinction Cerbos uses to frame the modern IAM stack. The control matters because stolen credentials, over-permissioned workloads, and AI agents all move faster than admin-time reviews can react, so the broken assumption is that access can still be safely judged long after it is requested.
At a glance
What this is: This is an analysis of runtime authorization as the control plane for identity security, with the core finding that request-time policy decisions matter more than provisioning-time grants.
Why it matters: IAM, PAM, and NHI programmes all need controls that can judge access at the moment of use, because static entitlements, tokens, and reviews age faster than modern workloads and agents.
By the numbers:
- Over 95% of cloud identities use less than 3% of their granted entitlements, according to Gartner research cited across the CIEM space.
Context
Runtime authorization is the practice of deciding access at the exact moment a request arrives, using live policy and current context rather than assumptions captured at provisioning or login. In IAM terms, it is the control point where authorization stops being historical record and becomes an active security boundary.
The governance gap is that most identity programmes still over-invest in admin-time grants, session tokens, and periodic reviews, even though those controls do not answer the question that matters under attack: should this specific request be allowed right now? That gap affects human IAM, NHI governance, and the growing class of AI-driven requesters alike.
Cerbos frames this as the layer that sits between IGA, PAM, and application enforcement, but the broader point is architectural: if policy is not evaluated at request time, the programme is relying on yesterday's access picture to defend today's activity.
Key questions
Q: What breaks when authorization is decided only at login or provisioning time?
A: The control breaks when the live request differs from the conditions assumed at login or provisioning. Tokens, roles, and approvals may all be correct in history but wrong for the current resource, context, or session state. That is how identity programmes end up with access that looks governed on paper but remains executable in production.
Q: Why do AI platforms need runtime authorization instead of static application controls?
A: AI platforms combine users, agents, APIs, prompts, and backend data in ways that static code checks cannot govern consistently. Runtime authorization evaluates each action at the moment it occurs, so policy can reflect context, object ownership, and intended behaviour. Without that layer, one exposed interface can cascade into data access and system manipulation.
Q: How can organisations tell whether runtime authorization is actually working?
A: Look for three signs: decisions happen fast enough to stay inline, policies use live context instead of stale claims, and every allow or deny produces an auditable record. If teams cannot explain a specific decision after the fact, or if applications bypass the control because it is too slow, the runtime layer is not functioning as intended.
Q: How should security teams implement runtime authorization alongside IGA and PAM?
A: Treat IGA as the source of granted entitlement, PAM as the control for elevated access, and runtime authorization as the request-time decision layer. The practical goal is to ensure that a live request is evaluated against current policy and context before any application or API action proceeds. That keeps access reviews useful without assuming they are sufficient.
Technical breakdown
Admin-time, token-time, and runtime authorization are not the same control
Authorization happens in distinct time windows. Admin-time authorization is the grant recorded in IGA when a role or entitlement is assigned. Token-time authorization is the set of claims frozen into an OIDC or OAuth token at login. Runtime authorization is different because it evaluates who is calling, what they want, which resource is involved, and what the live context looks like at the instant of the request. That distinction matters because the risk changes after login. A token can remain valid while the underlying context has shifted. A runtime decision can still deny the action even when the caller is authenticated and holding a valid session.
Practical implication: Treat runtime authorization as the control that closes the gap between identity state and actual service access.
Why policy at request time matters for NHI and AI agents
Non-human identities and AI agents tend to operate in dynamic, delegated, and fast-moving request paths. Service accounts, workloads, and agent tool calls do not behave like static human sessions, so access decisions hard-coded at provisioning time age quickly. Runtime policy lets the decision use live attributes, relationships, and current resource state instead of assuming that yesterday's role assignment still describes today's need. For autonomous behaviour, that request-time decision becomes even more important because the actor can chain tool calls, shift scope mid-session, and reach beyond the original intent of the grant.
Practical implication: Use request-time policy for workloads and agents whose access scope changes faster than review cycles can track.
What makes a runtime authorization platform actually work
A real runtime authorization platform must keep decision latency low, evaluate against live context, and emit a structured audit record for every decision. If latency is too high, teams bypass it. If the policy engine cannot read current identity, data, or relationship state, it falls back to stale assumptions. If the audit trail is not queryable, the control cannot support investigation or compliance. This is why runtime authorization is more than an SDK or a rules engine. It is a decision layer that sits on the hot path of production traffic and must scale without becoming a bottleneck.
Practical implication: Evaluate runtime products on decision latency, live context integration, and auditability, not just on policy syntax.
Threat narrative
Attacker objective: The objective is to turn valid identity into overbroad access at the moment of use and reach resources that static controls would have allowed by history rather than by current need.
- Entry occurs when a legitimate user, workload, or agent presents valid credentials and reaches an application that still relies on stale or precomputed authorization state.
- Escalation happens when the request lands on a permission path that was granted earlier but never re-evaluated against current resource, context, or delegation state.
- Impact follows when the service accepts the request without a fresh authorization decision, allowing the actor to reach data or actions that no longer match current policy intent.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime authorization is becoming the control plane because identity security now fails at request time, not just grant time. IAM programmes that stop at provisioning, login, or periodic review are still describing access history, not governing access decisions. The field needs to treat the decision that arrives with the request as the control boundary, because that is where abuse either succeeds or fails.
Standing entitlements have become a hidden attack surface because most granted access is never exercised under normal conditions. When over 95% of cloud identities use less than 3% of their entitlements, the real security problem is not whether the permission exists on paper but whether a live request can still activate it. Practitioners should interpret unused access as dormant blast radius, not harmless inventory.
Static authorization preserves yesterday's assumptions about who or what is entitled to act. That assumption was designed for a world in which access could be judged from roles and sessions alone. It fails when workloads, service accounts, and agents change state faster than review cycles can observe, so the implication is that identity governance must move from entitlement recording to decision enforcement.
Runtime authorization collapses the gap between IGA, PAM, and application enforcement into one governance question. IGA defines who was granted access, PAM governs elevated access, and runtime policy determines whether the request should proceed now. That convergence is where modern identity security is heading, and teams that keep those layers disconnected will keep finding control gaps at the point of use.
Identity programmes now need a named concept: request-time control plane. This is the point where policy, context, and enforcement meet at the exact instant a service is asked to act. The practitioner takeaway is simple: if your control plane cannot decide at request time, it cannot be the last word on authorization.
From our research library:
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
- Read next: Access Reviews and Certification Guide
What this signals
Runtime authorization is the practical answer to a governance problem that identity teams have been trying to solve with static state. When the decision moves to the request moment, policy can finally evaluate live context instead of inheriting stale entitlement assumptions.
Request-time control plane: the control point where policy, context, and enforcement converge at the instant a service is asked to act. For NHI and AI agent programmes, that shift matters because access reviews cannot certify behaviour that only exists for milliseconds; the decision has to happen before action completes.
For practitioners
- Define runtime decision boundaries Map which services, APIs, and agent flows must be governed by request-time authorization rather than role assignment or token claims.
- Separate grant from decision Keep IGA, PAM, and authentication as inputs to policy, but stop treating those systems as the final authorization verdict for live requests.
- Enforce live-context evaluation Require the policy engine to read current resource state, principal attributes, and relationship data at decision time before allowing access.
- Instrument every authorization decision Log who asked, what was requested, which policy answered, and what context was used so investigations can explain allow and deny outcomes.
Key takeaways
- Static authorization can document access history, but it cannot safely judge a live request against current context.
- Runtime authorization becomes decisive when workloads, service accounts, and agents move faster than provisioning and review cycles.
- Identity teams should separate grant, session, and request decisions so the live policy check becomes the last word.
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Runtime authorization addresses excess standing permission in non-human identities. |
| NHI-09 — NHI Reuse | The article discusses the reuse of static entitlements across different request contexts. | |
| Recommendation — Use live policy checks to reduce overprivileged NHI access at request time. Stop reusing provisioning-era access decisions as if they were valid at runtime. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime authorization strengthens how permissions are enforced at the point of use. |
| Recommendation — Apply PR.AA-05 to ensure entitlements are checked against current context before access is granted. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article ties runtime control to how credentials and session state are used in practice. |
| Recommendation — Use IA-5 to govern authenticator lifecycle so runtime decisions are not built on stale credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article links runtime authorization to containing stolen credentials and post-auth movement. |
| Recommendation — Map runtime authorization gaps to credential access and lateral movement opportunities in threat detection. | ||
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.
- Authorization Management Platform: A control layer that evaluates policy, identity data, and context to decide whether access should be allowed. In practice, it sits between identity sources and applications so teams can apply consistent authorization rules across different systems and non-human identities.
- Continuous Access Evaluation: Continuous access evaluation is the practice of rechecking whether a principal should still have access after the session begins. In NHI environments, it matters because tokens and service accounts can remain valid while the surrounding risk changes, so enforcement has to follow the request, not just the login.
- Request-Time Policy Check: An access decision made at the moment a secret is requested, rather than when it is stored or provisioned. For workloads and AI agents, this is a key control because it ties disclosure to identity, context, and policy instead of static possession.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org