Notifications
Clear all
Topic starter
10/06/2026 11:02 pm
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.
NHIMG editorial — based on content published by Cerbos: Runtime Authorization Platform analysis and IAM stack positioning
By the numbers:
- 95% of cloud identities use less than 3%, an 3% of their granted entitlements, according to Gartner research cited across the CIEM space.
- 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% a year earlier, according to Gartner.
Questions worth separating out
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.
Q: Why do service accounts and AI agents increase the need for runtime authorization?
A: Service accounts and AI agents act in dynamic request paths, often across tools, services, and delegated chains that change faster than provisioning records.
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.
Practitioner guidance
- Map request-time enforcement gaps Inventory where applications still rely on token claims, code-level checks, or provisioning-time entitlements instead of live policy evaluation at the service boundary.
- Separate policy decision from policy enforcement Use a PDP and PEP pattern so services can call a central decision layer without embedding access logic in application code.
- Validate runtime latency before rollout Measure sub-millisecond decision performance under peak traffic, then confirm that the control remains in path when workloads scale horizontally.
What's in the full article
Cerbos' full post covers the operational detail this analysis intentionally leaves for the source:
- Sub-millisecond decision architecture and deployment patterns for inline, sidecar, centralized, and edge PDPs
- AuthZEN, Shared Signals, and CAEP implementation details for interoperable runtime decisions
- Policy-as-code workflows, versioning, and testing practices for engineering teams
- Cerbos Synapse and protocol translation for Envoy, Kafka, Trino, Kubernetes, and workload identity sources
👉 Read Cerbos' full analysis of runtime authorization as the identity control plane →
Runtime authorization and IAM: are your controls still deciding too early?
Explore further
12/06/2026 4:50 am
Runtime authorization is the control layer that stops identity programmes from confusing granted access with safe access. Provisioning records, access reviews, and token claims all describe what was true earlier in the lifecycle. They do not answer the only question that matters when a request arrives at a service: should this action be allowed right now? For NHI, workload, and human access alike, that gap is where policy has to become executable. The practitioner implication is that request-time decisioning must be treated as a first-class identity control, not a convenience layer.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why request-time enforcement cannot depend on historical entitlement records alone.
A question worth separating out:
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.
👉 Read our full editorial: Runtime authorization is becoming the control plane for identity security
