Static authorization is very good at preserving yesterday's assumptions. It can tell you who had access to what a month ago, which roles were assigned at provisioning time, and which group memberships were signed off in the last access review. What it can't tell you is whether the request that just arrived at your API should actually be allowed, right now, given who the principal is, what resource they're touching, what context they're in, and whether any of that has changed since they logged in.
That question is the entire game for modern identity security. And the platform category that answers it is the Runtime Authorization Platform.
Gartner's own framing of the modern IAM stack places runtime authorization as a distinct layer above PAM and alongside IGA, not as a feature of either. It's the part of the stack that turns the identity fabric from a pile of provisioning data into an enforceable security boundary at the moment a request actually hits a service.
This post covers what runtime authorization actually means, why it's different from the admin-time controls most IAM programs over-invest in, what a Runtime Authorization Platform has to do well to be worth having, and how the category fits alongside IGA, PAM, AMPs, and the identity fabric most teams are now building toward.
What runtime authorization actually means
Authorization decisions fall into four time windows, and it's worth naming them because most of the industry still conflates them.
Admin-time authorization is the decision made when a user is provisioned, a role is assigned, or an entitlement is granted. IGA tools handle this. It produces durable state (you have this role until someone takes it away) and is evaluated in minutes or hours, not milliseconds.
Session/Login/Authentication-time authorization is the decision baked into an access token at login. "This user is in these groups and can do these things for the next eight hours." OIDC and OAuth token claims live here. This is better than admin-time because it captures session context, but it's still pre-computed. Once the token is issued, the decision is frozen until it expires.
Runtime authorization is the decision evaluated at the exact moment a request arrives at a service. Who is calling, what are they asking to do, on which resource, against what current state. Every request, every time, evaluated against the current policy and current context. This is the layer where zero trust actually lives.
Continuous authorization extends runtime into an always-on signal. Not just "was this allowed when the request arrived" but "has anything changed in the session since then that should revoke access." CAEP (Continuous Access Evaluation Profile) and the Shared Signals framework are how this gets wired up in practice.
A Runtime Authorization Platform covers the last two categories (runtime and continuous) and plugs into the first two so that admin-time and event-time data inform decisions without becoming the decision. Every request goes through the PDP. Every decision is made against live policy and live context. Every decision leaves an auditable trace.
Why runtime is where identity security actually lands
Most security investment still lands on the pre-attack surface, which is where admin-time and event-time controls live. Better authentication, MFA, passkeys, tighter provisioning, periodic access reviews. All of it is necessary. None of it is what stops the attacker at the moment they actually do damage.
The attack data is blunt on this point. The Verizon 2025 Data Breach Investigations Report found that 88% of basic web application attacks involved stolen credentials, and credential abuse is again the top initial access pattern. Once someone is authenticated as a legitimate user, the only thing that decides whether they reach the data is the authorization check at runtime. If that check is embedded in application code, it's subject to whatever bugs the last release shipped. If it's absent, the attacker gets what the authenticated user could have got. That's still the mechanic behind broken access control sitting as A01 on OWASP's 2025 Top 10, the same position it's held since 2021.
The same pattern applies inside the stack. Over 95% of cloud identities use less than 3% of their granted entitlements, according to Gartner research cited across the CIEM space. Those unused entitlements are standing runtime permission. They don't show up in admin-time reviews because nothing has actually changed. They only become visible when an attacker or a misconfigured workload exercises them.
Runtime authorization is the control that turns that standing surface area into something an attacker has to earn.
What a Runtime Authorization Platform has to do well
The runtime layer has a different job from the rest of the identity stack, which is why it's a different category of product. Three properties separate a real runtime authorization platform from something that just happens to make access decisions.
Decisions have to complete in sub-millisecond latency at scale. Authorization is on the hot path of every request. If the decision adds 20ms, the platform becomes a latency tax and teams route around it. A serious runtime platform delivers sub-millisecond decision times and scales horizontally to millions of requests per second without central coordination. Stateless PDPs running close to the workloads they govern is the architecture that makes this possible.
Decisions have to evaluate against live context, not just role claims. The modern version of a "yes or no" answer depends on the principal, the resource, the action, the time of day, the device, the session risk, the relationship between the principal and the resource, the transaction amount, and whatever else policy authors need to express. Pre-computing all of that into a role or a token claim is how teams end up with static authorization that drifts from reality. A runtime platform integrates with the identity provider, the data layer, and the application state at decision time, so policy evaluates against current reality.
Every decision has to produce a structured audit record. Runtime decisions are the single most valuable signal for ITDR and compliance. Who asked, what they asked for, what the decision was, which policy made it, what context was used. Audit logging is the difference between a runtime platform and a runtime black box. If you can't answer "why was this allowed at 3am" after the fact, the platform is not doing its job.
These are the properties that qualify something as a runtime authorization platform. Anything less is a library, a config layer, or a policy engine.
Where a Runtime Authorization Platform fits alongside AMPs, IGA, and PAM
The category confusion worth clearing up is the relationship between a Runtime Authorization Platform and an Authorization Management Platform. Industry analysts use both terms and they are not quite the same thing.
An AMP is the broader platform category. It covers policy authoring, versioning, testing, distribution, runtime decisions, enforcement integration, and audit, across the full PAP/PDP/PEP/PIP/POP architecture. A Runtime Authorization Platform is the runtime subset of that. The PDP, the PIP layer, the enforcement points, and the observability pipeline that together handle the decision at the moment of the request. In most serious deployments they are the same product, with the runtime layer being the part that actually touches production traffic.
Where runtime authorization sits relative to IGA and PAM is cleaner. IGA handles the admin-time grant (does this user have this entitlement). PAM handles the high-privilege accounts and pushes toward just-in-time access. Access management handles authentication and session rules. Runtime authorization takes inputs from all three (the roles IGA provisioned, the sessions AM authenticated, the elevated privileges PAM granted) and turns them into a decision on this specific request against this specific resource right now. It doesn't replace any of them. It closes the loop between all of them and the actual service.
Why runtime matters more than ever in 2026
Three shifts have pushed runtime from "nice to have" to "the thing identity security depends on."
The first is workload and machine identity. Service accounts, workloads, and non-human identities now outnumber humans by a wide margin inside most enterprises. Their access can't be pre-computed cleanly. They call each other in dynamic graphs, their permissions shift with deployments, and static role claims go stale as soon as infrastructure rotates. Managing non-human identities at runtime is the only approach that holds.
The second is AI agents. Gartner forecasts that 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% a year earlier. The same analyst firm also expects over 40% of agentic AI projects to be canceled by the end of 2027, largely because of unresolved identity and authorization problems. Agents act on behalf of humans, call tools that call other tools, and construct delegation chains that don't fit into a pre-issued token. Authorization for them has to be evaluated when they call the tool, not baked in when they were started. MCP authorization and agent governance both live at runtime.
The third is the attack clock. Gartner has also warned that AI agents will reduce the time it takes to exploit account exposures by 50% by 2027. When the window between initial access and lateral movement shrinks, every second of delay between a compromised credential and an active attack has to come from the runtime layer. Static controls can't move that fast.
All three converge on the same conclusion. Admin-time controls are necessary and insufficient. The decision that actually matters happens at runtime, in milliseconds, on every request.
Deployment shapes
Runtime authorization platforms show up in production in a handful of shapes, and serious ones support more than one.
An inline library call, where the PDP runs as part of the service itself, is the simplest and lowest-latency pattern. It's the right shape for most application-level authorization where policy and service live on the same host.
A sidecar PDP runs alongside the service, usually in the same pod or container group, and handles decisions over a local socket. Latency stays low, isolation improves, and the PDP can be updated independently of the service.
A centralized PDP service handles decisions over the network for the broader platform. Useful when you need a single point of observability for all authorization traffic, or when policy has to be consistent across a heterogeneous stack. The trade-off is network latency and a potential coordination point.
An edge or embedded PDP runs in the browser, the gateway, or the mesh filter. This pattern is increasingly common for client-side authorization, API gateway enforcement, and service mesh integration with Envoy and similar data planes.
A working runtime authorization platform supports all four, so teams can deploy each service with the shape that fits its latency and operational profile.
What open standards are doing to the category
For a long time runtime authorization was balkanised. Every vendor had its own API between enforcement points and decision engines, and every integration was bespoke. That has changed.
The AuthZEN Authorization API 1.0 was ratified by the OpenID Foundation in January 2026 as a final specification. It defines theAPI between a PEP and a PDP, so enforcement points from any vendor can talk to decision engines from any vendor using the same protocol. That's the foundation that makes runtime authorization a genuine platform layer rather than another place to get locked in.
Alongside AuthZEN, Shared Signals and CAEP formalise how runtime decisions react to mid-session events like credential revocation or risk-score changes. SPIFFE/SPIRE gives workloads portable identities that PDPs can evaluate. These standards don't replace the platform, but they make it possible to build an identity fabric where runtime authorization plugs in at every layer without adapter tax.
What to look for when evaluating a Runtime Authorization Platform
The category is crystallising but the differences between products are still large. A handful of criteria matter more than the rest.
Stateless, horizontally scalable PDPs, deployed close to the workloads they govern, with sub-millisecond decision latency even under load. If the platform requires a central service with state, it will cap your throughput.
Policies written as code, stored in Git, reviewed in pull requests, tested in CI, and distributed to every PDP instance without downtime. A GUI-only policy authoring experience could be a sign the platform was not built for engineering teams.
Open-standard enforcement. AuthZEN support at the PEP layer means the decision engine is portable and the enforcement points are interchangeable.
Live data integration at the PIP layer. The platform should pull attributes and relationships from identity providers (Okta, Entra ID, Auth0, Keycloak), databases, and application state at decision time. Anything less means policies evaluate against stale data.
Structured audit output for every decision. If the logs aren't queryable, compliance-ready, and streamable into SIEM or ITDR, the platform is closing half the loop.
Coverage for humans, workloads, and AI agents in a single policy model. Separate systems for each is how organisations end up with authorization sprawl at runtime.
Cerbos - a Runtime Authorization Platform
Cerbos is built as a runtime authorization platform. The architecture maps directly to the shape described above.
Cerbos PDP is an open-source, stateless, horizontally scalable decision engine that runs wherever your workloads run. Containers, Kubernetes, edge, on-prem. Decisions return in sub-millisecond latency, and the engine scales out linearly. Policies are written in YAML with CEL for conditions, treated as code, stored in Git, and tested in CI. When policies change, they distribute to every PDP instance without restarts.
Cerbos Hub is the control plane for authoring, testing, versioning, and governing policies at scale, with structured audit logs that meet SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR requirements. Every decision Cerbos makes produces a queryable, compliance-ready audit record that feeds ITDR, SIEM, or downstream analytics.
Cerbos Synapse handles the PIP layer and protocol translation for policy orchestration. It enriches decisions with live identity attributes and relationships from Okta, Entra ID, Auth0, Keycloak, AWS Cognito, LDAP, and custom databases at the moment of the request. It also translates native protocols for Envoy, Kafka, Trino, and Kubernetes into policy checks, which means the same runtime authorization platform can govern both application-level and infrastructure-level decisions.
For AI agents, Cerbos evaluates both the agent and the delegating human in a single policy call. A Claude Code hook handler intercepts agent tool calls before execution, runs them through the runtime PDP, and either allows or blocks them with a full audit trail. The same pattern works for MCP servers and any other non-human identity that needs governed access at runtime.
Every Cerbos PDP ships AuthZEN-compliant, so PEP integrations stay portable across the stack, and the runtime layer can slot into an existing identity fabric without ripping out whatever IGA, PAM, or access management you already run.
The takeaway
Identity security in 2026 is only as strong as the decision made at the moment a request arrives. Admin-time controls, event-time token claims, and session-level rules all matter, but none of them survive contact with a stolen credential, a lateral-moving agent, or an over-permissioned workload unless there's a runtime authorization layer deciding every request against live policy and live context.
Runtime Authorization Platforms are how that layer gets built. If you're architecting identity security this year, it's the control worth putting next to ITDR and ISPM on the roadmap, not below them.
Try Cerbos to see how runtime authorization works against your own policies in production-shaped deployments, or book a call to walk through how it fits into your identity stack.
Go deeper:
- How to adopt externalized authorization (eBook) for a step-by-step playbook on moving runtime decisions out of application code
- The IAM security checklist for 2026 (Checklist) for a pre-flight list of the controls most programs miss at runtime
FAQ
Tagged in
