Authorization controls are becoming a core IAM growth area

At a glance

What this is: This is a founder interview about Cerbos and the case for simplifying application authorization, with the key finding that fine-grained access control is still an underbuilt IAM capability.

Why it matters: It matters because application authorization decisions shape least privilege, delegated access, and entitlement governance across human, service, and agent identities.

👉 Read Cerbos' podcast summary on simplifying application authorization

Context

Authorization is the decision layer that determines what a user, service, or process can do after authentication. In modern software, that layer often gets rebuilt in every application, which creates inconsistency, policy drift, and hidden privilege growth across IAM programmes.

The article argues that this gap is large enough to justify a dedicated product category, but the deeper issue for practitioners is governance. When authorization logic lives in code, security teams lose visibility into entitlement design, review, and change control, which weakens both NHI oversight and human access governance.

Key questions

Q: How should security teams govern fine-grained authorization across applications?

A: Security teams should treat authorization as a governed policy layer, not an application-by-application coding choice. That means assigning ownership, versioning policy changes, reviewing exceptions, and tying entitlement design into access reviews and offboarding. If each app invents its own rules, least privilege becomes impossible to prove consistently.

Q: Why does homegrown authorization create governance risk?

A: Homegrown authorization creates governance risk because access logic gets duplicated, patched, and forgotten across teams and codebases. Over time, that produces role sprawl, inconsistent approvals, and exceptions that never expire. The technical problem becomes an audit and lifecycle problem once nobody can reliably explain or certify the effective policy.

Q: When does externalized authorization make sense for IAM programmes?

A: Externalized authorization makes sense when multiple applications need consistent access rules, when policy changes outpace release cycles, or when privilege decisions must be audited centrally. It is most useful when security teams need a reusable control layer rather than one-off code fixes. The key test is whether it improves governance visibility, not just developer convenience.

Q: What should teams look for before replacing in-app permission checks?

A: Teams should look for duplicated rules, unclear policy ownership, weak testing, and exceptions that have become permanent. If the application already has fragmented access logic, replacing it with a governed control layer can reduce drift and improve certification. If ownership stays vague, the same problems will simply move to a new place.

Technical breakdown

Fine-grained authorization as a policy layer

Fine-grained authorization separates access decisions from application logic by evaluating roles, permissions, and contextual rules at runtime. Instead of hardcoding checks throughout a codebase, teams centralise policy decisions so that access rules can be changed without rewriting business logic. This pattern matters because it reduces duplication, but it also creates a governance surface that must be versioned, reviewed, and tested like any other security control. In IAM terms, authorization becomes an operational control plane, not just a developer convenience.

Practical implication: treat authorization policy as governed security code with ownership, review, and change tracking.

Why delegation changes the access model

Delegation is the ability to assign access decisions or enforcement to another system, component, or team without losing policy consistency. In application environments, this often appears as centrally defined access rules that are consumed by many services. That architecture can improve scale, but it also introduces a control dependency: if delegation boundaries are unclear, over-permissioned services can spread privilege faster than access reviews can contain it. The security challenge is not only who can access data, but which layer is trusted to make that decision.

Practical implication: map delegated authorization paths so you know which services can amplify privilege.

Authorization debt in application development

Authorization debt is the accumulated risk created when teams postpone access-control design and fill gaps with ad hoc code, manual approvals, or inconsistent role definitions. It usually shows up as duplicated logic, broad default roles, and exceptions that are never retired. For IAM and security teams, that debt is hard to see because it hides inside application delivery cycles rather than central identity tooling. Over time, the result is a fragmented entitlement model that is difficult to certify, audit, or align with least privilege.

Practical implication: inventory applications with homegrown access checks and prioritise the highest-risk policy sprawl first.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Application authorization is becoming an identity governance problem, not just a developer problem. When roles and permissions are implemented separately in every app, the organisation loses a single governable view of who can do what. That fragmentation weakens recertification, exception handling, and least-privilege enforcement across the stack. The practitioner conclusion is simple: authorization design now belongs in the identity architecture conversation.

Authorization debt: the cumulative risk created when access rules are embedded inconsistently across applications and never normalised. This debt builds when teams solve each authorization request locally instead of applying a shared policy model. The result is not just technical inconsistency, but a governance gap that makes audit, offboarding, and privilege cleanup slower and less reliable. Practitioners should treat this as a measurable control-plane problem.

Delegated access control only works when policy ownership is explicit. If one team writes the policy, another enforces it, and a third certifies it, gaps appear quickly unless ownership and review cadence are tightly defined. That is true for human access and for service or workload identities. The implication for IAM leads is that delegation without lifecycle control becomes a privilege amplification mechanism.

Fine-grained access control is where NHI and human IAM start to converge. The same governance question repeats across users, service accounts, and future AI agents: who defines the boundary, who approves exceptions, and who can prove enforcement happened. Cerbos’ framing reflects a broader market shift toward externalised authorization, but the real test is whether identity teams can govern it as part of one access model. Practitioners need to align application authorization with the same controls used for identity lifecycle and privilege management.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• That mismatch between confidence and execution is why the NHI Lifecycle Management Guide is the right next resource for teams trying to tighten ownership and removal processes.

What this signals

Authorization policy sprawl will increasingly be treated as identity risk, not application technical debt. As enterprises distribute more logic into services and platforms, the ability to certify access will depend on whether policy is centralised enough to audit but local enough to be enforced. Teams that cannot explain authorization ownership across applications will struggle to defend their least-privilege posture.

The next maturity step is not simply more policy tooling. It is clearer control boundaries between identity lifecycle, application authorization, and exception governance, especially where service accounts and delegated access create hidden privilege paths. Teams that align these layers early will have a cleaner path to auditability and fewer surprises during recertification.

Authorization debt: this is the point at which access logic becomes too distributed to govern cleanly. The practical signal to watch is not the number of permissions alone, but whether policy changes, approvals, and reviews can still be traced back to a named control owner. If they cannot, the programme is already carrying hidden privilege risk.

For practitioners

• Map authorization ownership across applications Document which teams define, approve, and enforce access rules in each application. Flag any system where policy is embedded in code without an explicit control owner or review process.
• Inventory homegrown permission logic Identify applications with duplicated roles, hardcoded checks, or manual access exceptions. Rank them by privilege sensitivity, external exposure, and business criticality before standardising policy.
• Bring authorization into access review Include application permission design in recertification and offboarding workflows so that dormant roles, unused exceptions, and stale delegation paths are removed instead of inherited.
• Separate policy definition from enforcement Use a controlled policy layer so access rules can be updated consistently across services without changing each application individually. This reduces drift and makes reviews easier to evidence.

Key takeaways

• Application authorization is becoming a core identity governance issue because fragmented policy makes least privilege harder to prove and maintain.
• The main risk is authorization debt, where duplicated rules, stale exceptions, and unclear ownership create hidden privilege growth.
• Practitioners should centralise policy ownership, connect authorization to lifecycle reviews, and inventory applications that still rely on homegrown permission logic.

Key terms

• Authorization debt: Authorization debt is the accumulation of inconsistent access rules, duplicated logic, and temporary exceptions that become permanent. It grows when teams solve permission problems locally instead of through a controlled policy model, making certification, audit, and offboarding harder over time.
• Fine-grained authorization: Fine-grained authorization is the practice of deciding access at a detailed level, such as action, resource, or context, rather than using broad coarse roles alone. It usually improves precision, but it also creates a governance requirement for policy ownership, testing, and change control.
• Delegated access control: Delegated access control is a model where one layer defines or enforces access decisions on behalf of another layer. It can scale authorization across many applications, but only if policy ownership, exception handling, and review responsibility remain explicit and auditable.

Deepen your knowledge

Authorization governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to unify application policy with identity lifecycle controls, it is worth exploring.

This post draws on content published by Cerbos: From the Ground Up podcast summary with Emre Baran on application authorization. Read the original.