Notifications
Clear all
Topic starter
10/06/2026 11:08 pm
TL;DR: Authorization logic is increasingly split across application code, IdPs, database grants, and token claims, leaving runtime decisions hard to govern and audit, according to Cerbos. Authorization management platforms centralise policy and evaluation so IAM teams can control fine-grained access without hand-rolled code, but only if they treat policy as code and keep the decision layer observable.
NHIMG editorial — based on content published by Cerbos: authorization management platforms and the runtime access gap
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map runtime decision ownership first Inventory which teams currently own application-level access checks, database permissions, IdP claims, and gateway rules.
- Externalize high-risk authorization paths Start with customer data, admin functions, and service-to-service calls that currently depend on embedded code checks.
- 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.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of PAP, PDP, PEP, PIP, and POP interactions across real deployment patterns
- Practical integration guidance for externalized authorization, policy orchestration, and token-facilitated authorization
- Discussion of build versus buy trade-offs for teams replacing homegrown authorization code
- Examples of how AMP policies fit into AI agent and workload access decisions
👉 Read Cerbos' analysis of authorization management platforms and runtime access control →
Authorization management platforms: what IAM teams need to know?
Explore further
12/06/2026 4:58 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authorization management platforms and the runtime access gap
