Authorization is still failing because teams defer it too long

At a glance

What this is: Cerbos’ podcast discussion says authorization is still too often deferred until late in development, where it becomes much harder to scale and govern.

Why it matters: IAM and software teams need to treat authorization, not just authentication, as core architecture because delayed access design creates brittle controls and weak privilege boundaries.

Context

Authorization is the policy layer that decides what an authenticated subject may do after login. In modern software, that layer often starts as a simple role check and then accumulates exceptions as products, customers, and compliance requirements grow.

The episode’s central governance gap is not identity proofing but access decision design. For IAM, PAM, and NHI programmes alike, the lesson is that privilege boundaries need to be defined early enough to survive scale, delegation, and changing business logic.

Key questions

Q: What breaks when teams defer authorization until after launch?

A: Deferring authorization usually leaves teams with coarse roles, embedded exceptions, and scattered permission checks that are hard to audit or change. As the product grows, those shortcuts turn into design debt, because access decisions are no longer centralized, explainable, or aligned to resource ownership and business context.

Q: Why does weak authentication create risk even when authorization policies are strict?

A: Weak authentication undermines the trust foundation that authorization depends on. If an attacker can impersonate a user, even well designed access rules may grant the wrong person valid privileges. This is especially risky in IAM environments where access to finance, data, APIs, or administrative functions depends on identity assurance before the system applies policy.

Q: How do security teams know if agent authorization is actually working?

A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.

Q: Should organisations use zero standing privilege for agentic access?

A: Yes, when the agent only needs access for a specific action or session. Zero standing privilege reduces persistent exposure and limits what a compromised or misused agent can touch. It works best when paired with approval, logging, and immediate revocation after the task completes.

Technical breakdown

Why deferred authorization turns into design debt

Authorization becomes difficult when product teams postpone it until after the first release. A coarse role model may work for a narrow use case, but it collapses once business logic, tenancy, delegation, and compliance requirements multiply. The result is not just technical sprawl, but governance debt: access rules get embedded in application code, scattered across services, and become expensive to reason about. In practice, teams then stop distinguishing between what the application does and what the subject is allowed to do. That is where fine-grained access control becomes an architecture problem, not a post-build fix.

Practical implication: define access decision boundaries before the app ships, not after roles have already been hard-coded into business logic.

Authentication and authorization solve different problems

Authentication proves who a subject is. Authorization decides what that subject may do, at a specific resource and action level. The distinction matters because a secure login does not create safe permissions, and a valid session does not justify broad access. In mature environments, the authorization layer must express context such as tenant, resource ownership, job function, and state of the request. That is why zero standing privileges is a useful pattern here: access should be granted only for the task at hand, not left permanently attached to the identity.

Practical implication: separate sign-in controls from permission decisions and avoid treating a successful login as proof of broad access entitlement.

Why custom authorization logic becomes unsustainable

Hand-built authorization often looks acceptable in the first version of a product because the number of roles and resources is small. The problem is operational, not theoretical: every new edge case, integration, and exception increases the amount of code that must be maintained, reviewed, and secured. Once the original builders move on, the knowledge gap widens and the control model becomes fragile. Off-the-shelf authorization platforms exist because permission logic is a recurring infrastructure concern, not a one-off feature. The architecture question is whether teams want authorization embedded everywhere or governed in one place.

Practical implication: move recurring permission logic out of application-specific code paths before maintenance debt makes access changes risky and slow.

NHI Mgmt Group analysis

Authorization deferral is a governance failure, not a back-office coding shortcut. The episode makes clear that teams do not postpone authorization because it is unimportant, but because they assume a simple model will survive growth. That assumption fails once business logic, tenancy, and compliance requirements multiply. The practitioner lesson is to treat access decision design as part of system architecture from day one.

Zero standing privileges changes the authorization conversation from static roles to task-scoped access. The value is not merely reduced privilege, but reduced persistence of privilege. That matters because many software teams still behave as if login establishes a durable trust state, when the safer model is to grant only the permissions needed for the current action. The implication is that standing access should be the exception, not the baseline.

Custom authorization logic creates identity blast radius. When access rules live inside application code, every new feature can widen privilege in ways that are difficult to audit or unwind. That pattern is especially risky in multi-service environments where business logic and authorization logic blur together. The practitioner conclusion is that access policy needs a governed control plane, not scattered one-off checks.

Authentication maturity does not compensate for authorization immaturity. Many teams believe solving sign-in, SSO, or session handling covers the hard part, but the episode separates proving identity from limiting action. That separation matters across human IAM, service-to-service access, and NHI governance, because each can authenticate cleanly while still being over-permissioned. The implication is that access control quality must be assessed independently from login quality.

Authorization is becoming a compliance primitive as much as a software pattern. The discussion points to a future where regulatory expectations increasingly depend on fine-grained and explainable access decisions. That does not mean compliance drives design by itself, but it does mean weak authorization becomes harder to defend as systems scale. Practitioners should expect governance scrutiny to focus on how access decisions are made, not just whether users can sign in.

What this signals

Authorization needs to be treated as a governed policy layer, not a set of convenience checks. Once teams start encoding access decisions directly in product code, they create a control surface that is hard to review, hard to delegate, and hard to change safely. That is the point where IAM, PAM, and software engineering stop being separate conversations.

Zero standing privileges is the useful framing for modern authorization design. The goal is not simply fewer privileges, but privileges that exist only for the duration of a task or request. That shift matters for human users, service accounts, and other non-human identities that should not carry persistent access by default.

For practitioners

• Design authorization before feature expansion Map the core resources, actions, and ownership conditions that define access decisions before you add more roles or exceptions.
• Separate authentication from permission logic Review application flows to ensure sign-in success does not imply broad access and that permission checks happen at each sensitive action.
• Replace ad hoc roles with governed policy Move repeated access rules into a central policy layer so product teams do not keep re-implementing the same checks in code.
• Apply zero standing privilege to sensitive actions Grant elevated permissions only for the task in progress, then remove them when the request or workflow ends.
• Test authorization changes against scale and ownership Validate new rules against multi-tenant cases, delegated access, and changing ownership so the model stays explainable as the product grows.

Key takeaways

• Authorization problems often begin as development shortcuts and turn into governance debt once systems and access rules scale.
• Strong authentication does not prevent over-permissioning if authorization remains coarse, embedded, or hard to change.
• The practical fix is to design task-scoped, policy-governed access decisions early rather than retrofitting them after the product is already complex.

Key terms

• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Zero Standing Privileges (ZSP): A security posture where no identity, human or non-human, holds persistent access rights. Access is provisioned dynamically on demand and automatically revoked after use. ZSP is the gold standard for NHI access control.
• Coarse-Grained Access Control: Coarse-grained access control is a simpler authorization approach that grants access using broad categories, often centered on role alone. It is easier to implement, but it provides less precision and can create overly permissive access when users in the same role need different levels of access to systems, data, or actions.
• Access Decision Point: An access decision point is the place where an application evaluates whether an action should be allowed. For large systems, it becomes a control surface that must be reliable, auditable, and consistent across many workflows rather than embedded ad hoc in each service.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.