Authorization management platforms and the runtime access gap

At a glance

What this is: This is an independent analysis of authorization management platforms, with the key finding that enterprises need a dedicated runtime decision layer because IGA and access management do not cover fine-grained authorization.

Why it matters: It matters to IAM practitioners because the runtime allow-or-deny decision now affects human access, service accounts, and AI agents, and weak authorization turns every identity issue into a larger blast-radius problem.

By the numbers:

• 88% of basic web application attacks involved stolen credentials, and credential abuse has been the top initial access pattern five years in a row.
• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Cerbos' analysis of authorization management platforms and runtime access control

Context

Authorization management platforms exist because most enterprises still split policy across application code, identity providers, database grants, and workflow tickets. That leaves teams trying to answer a simple runtime question, can this principal do this thing on this resource right now, by stitching together systems that were never designed to produce one auditable answer.

For IAM programmes, the gap is structural: IGA handles provisioning and review, access management handles authentication and coarse session rules, PAM handles elevated access, but none of them fully governs the runtime decision. That makes authorization the missing control plane for NHI workloads, human users, and now AI agents that trigger actions across delegated tool chains.

Key questions

Q: How should security teams implement runtime authorization for critical applications?

A: Start by identifying the applications where embedded access logic creates the most risk, then move those decisions into a central policy layer. Keep enforcement close to the workload, test policy changes before release, and make every decision auditable. That approach reduces drift, shortens review cycles, and makes authorization changes safer to operate.

Q: Why do service accounts and AI agents make authorization harder to govern?

A: Service accounts and AI agents often act across multiple tools, resources, and delegation chains, which makes static role grants too coarse. Runtime authorization must decide based on context, not just identity labels. If the access layer cannot evaluate intent, resource state, and transaction conditions, policy quickly becomes either too permissive or unusable.

Q: What breaks when authorization stays embedded in application code?

A: Application-level checks create policy drift, inconsistent audit trails, and hidden exceptions that security teams cannot see centrally. Each service ends up with its own access language, which makes reviews slow and incident response harder. The result is a system where authentication works, but authorization is too fragmented to trust.

Q: How do IAM teams know whether an authorization platform is working?

A: Look for measurable reduction in policy exceptions, faster access changes, and complete decision logging across the highest-risk applications. If teams still need code changes for routine access updates, the control is not externalized enough. A working platform should improve auditability without adding noticeable latency to legitimate requests.

Technical breakdown

PAP, PDP, PEP, PIP and POP in runtime authorization

An authorization management platform is built from a policy administration point, policy decision point, policy enforcement point, policy information point, and sometimes a policy orchestration point. PAP is where policy is authored and versioned, PDP is the runtime decision engine, PEP enforces the answer in the calling system, and PIP supplies live context such as group membership, device state, or resource ownership. POP extends those decisions into existing systems that cannot call the PDP directly. The architectural point is separation of concerns: policy stays central, execution stays close to the workload, and every decision can be evaluated consistently across services.

Practical implication: Treat policy as a shared control plane and make every production decision traceable through structured logs.

Externalized authorization versus embedded access logic

The main architectural shift is moving authorization out of application code and into a dedicated runtime service. When access rules live in code, every team invents its own role checks, audit format, and exception handling. When they are externalized, services ask the same question in the same way and receive a uniform answer. That reduces drift across microservices, but it only works if the application enforces the decision cleanly and the policy layer is close enough to avoid latency penalties. The category is therefore as much about operating model as technology.

Practical implication: Refactor the highest-risk applications first so policy changes no longer require code rewrites.

Policy as code for fine-grained access control

AMPs work best when policies are treated as code. That means version control, peer review, test coverage, and controlled promotion, not ad hoc changes in a GUI. Fine-grained authorization usually combines role-based access control, attribute-based access control, and relationship-based rules so decisions can reflect context rather than static entitlements alone. This matters because the modern request is rarely simple. A service may need to know who the user is, which team owns the resource, whether the device is managed, and whether the action is inside an approved transaction boundary.

Practical implication: Move policy authoring into the same software delivery discipline you use for application code.

Threat narrative

Attacker objective: The objective is to turn a valid identity into broad downstream access by exploiting weak runtime authorization rather than breaking authentication itself.

1. Entry begins when authenticated access is already present, often through stolen credentials or an overprivileged service account that reaches the application boundary.
2. Escalation happens when coarse roles, embedded if logic, or stale claims allow the principal to invoke actions beyond the original intent of the login or token.
3. Impact follows when the attacker or mis-scoped workload can read, change, or exfiltrate protected resources because the runtime authorization layer never constrained the request tightly enough.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization sprawl is the hidden control-plane problem behind modern identity risk. IGA decides who gets granted access, access management decides who logs in, and PAM narrows the highest-risk sessions, but none of those layers reliably answer the runtime question of whether a specific action on a specific resource should proceed. When that decision remains scattered across code, claims, and database grants, governance becomes impossible to audit at scale. Practitioners should treat runtime authorization as its own discipline, not an implementation detail.

Fine-grained access control has become a governance requirement, not a developer convenience. Once identity systems handle humans, workloads, and delegated AI actions, static role grants are too blunt to express intent. The more distributed the application stack becomes, the more the security model needs policy-based and relationship-based decisions that can be evaluated at runtime. IAM teams should stop assuming that provisioning and login cover the access problem.

Standing authorization is now part of the blast radius, not just standing privilege. Even when authentication is strong, a principal with persistent broad entitlements can still move laterally through a system if the decision layer is weak. That means modern access governance must examine not only who is entitled, but how much of that entitlement is actually reachable at runtime. Practitioners should measure exposure by decision scope, not by role count alone.

Runtime authorization is becoming the common language across human IAM, NHI governance, and agent controls. The same control plane that prevents an overprivileged service account from reading customer data can also constrain a human session or a delegated AI action. That convergence matters because identity programmes are already too fragmented. Teams that align policy evaluation across actor types will reduce duplication, improve auditability, and make future control changes far easier to govern.

Policy-as-code is the named concept that separates AMP maturity from shelfware. Policies that live in Git, move through pull requests, and deploy through controlled pipelines behave like governed security controls. Policies that live in a GUI and drift from application logic become another hidden dependency. Practitioners should judge AMP maturity by whether policy changes are reviewable, testable, and portable across systems.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• That remediation gap is why teams should also review the NHI Lifecycle Management Guide for offboarding and revocation discipline.

What this signals

Policy-based authorization will become the default control plane for identity programmes that span humans, workloads, and AI-driven delegation. As more access decisions move to runtime, the programme challenge shifts from provisioning entitlements to governing decision quality. Teams that still treat authorization as an application concern will struggle to produce audit evidence, enforce least privilege, or scale controls across modern architectures.

The practical signal for IAM leaders is that authorization telemetry now deserves the same operational attention as authentication logs. If every decision is structured and reviewable, incident response becomes faster and entitlement creep becomes visible earlier. That also creates a cleaner foundation for Zero Trust work, especially where the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both point toward tighter access governance.

For practitioners

• Map runtime decision ownership first Inventory which teams currently own application-level access checks, database permissions, IdP claims, and gateway rules. Then assign a single decision authority for each critical resource class so policy no longer fragments across microservices and tickets.
• Externalize high-risk authorization paths Start with customer data, admin functions, and service-to-service calls that currently depend on embedded code checks. Move those decisions into a policy engine so changes can be reviewed, tested, and audited without redeploying the application.
• Instrument every decision for audit and detection Require structured logs for allow, deny, and policy-change events, and feed them into SIEM and ITDR workflows. The goal is to make authorization decisions searchable enough to answer who could do what, when, and under which conditions.
• Align NHI and agent access with the same policy layer Use the same runtime decision model for service accounts and delegated AI actions that you use for humans. That avoids separate exception paths for non-human access and makes privilege review possible across all actor types.

Key takeaways

• Authorization management platforms exist because runtime access decisions are still too fragmented to govern through IGA, PAM, or access management alone.
• The operational risk is not just excessive privilege, but inconsistent decision logic spread across code, claims, and infrastructure.
• Teams that move policy into a reviewable, auditable control plane can govern humans, NHIs, and delegated AI actions with far less drift.

Key terms

• Authorization Management Platform: A platform that centralises how access decisions are written, evaluated, and enforced at runtime. It separates policy authoring from application code so services can ask one decision engine the same question and receive a consistent, auditable answer across human, workload, and delegated access flows.
• Policy Decision Point: The runtime component that evaluates a request against policy and context, then returns allow or deny. In modern identity architecture, it is the control that turns authorization from scattered logic into a measurable decision service that can scale across applications and infrastructure.
• Policy as Code: The practice of treating access policy like software, with version control, review, testing, and controlled release. For authorization programmes, this makes access rules auditable and repeatable instead of hiding them in application code, ad hoc scripts, or manual admin changes.
• Policy Information Point: The source of live context used during an authorization decision, such as identity attributes, ownership data, device posture, or resource state. Without a reliable PIP, runtime authorization reverts to static role checks and loses the context needed for fine-grained access control.

Deepen your knowledge

Authorization management and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for service accounts, agents, or fine-grained application access, it is worth exploring.

This post draws on content published by Cerbos: authorization management platforms and the runtime access gap. Read the original.