Zero trust now depends on centralized authorization and identity

At a glance

What this is: Cerbos argues that zero trust now depends on centralized authorization because identity verification alone does not answer what an identity is allowed to do.

Why it matters: IAM, PAM, NHI, and agentic AI programmes all need auditable request-level authorization if they want to contain blast radius and keep policy changes governable across distributed systems.

Context

Zero trust is an architecture built on continuous verification of identity and authorization rather than trust based on network location. In this article, the governance gap is not authentication, but the control that decides what an authenticated identity can actually do across distributed applications and cloud services.

As organisations move from perimeter-based security to distributed service architectures, authorization becomes the policy layer that determines whether identity-based trust is enforceable in practice. The article frames centralized authorization as the missing operational step that makes zero trust auditable, scalable, and compatible with workload and AI-agent identities.

Key questions

Q: How should security teams implement continuous authorization in zero trust environments?

A: Start by defining which actions require revalidation after login, then attach runtime signals such as device health, location, and resource sensitivity to policy decisions. Enforce those decisions at the destination system, not only in the access gateway. Continuous authorization works best when combined with short session lifetimes and least privilege.

Q: Why do distributed applications make authorization harder to govern?

A: Distributed applications create more places for authorization logic to drift. When services, environments, or teams implement permissions differently, the organisation loses consistency, auditability, and confidence that the same user will receive the same decision everywhere.

Q: What breaks when authorisation is hardcoded into application logic?

A: Hardcoded access rules become brittle as systems grow, because each code path must be updated and retested whenever permissions change. That creates audit gaps, slows remediation, and makes it difficult to apply consistent policy across clusters, services, and AI-driven workflows.

Q: How should security teams govern AI agents and human users under zero trust in generative AI environments?

A: Security teams should treat both people and AI agents as identities that must be authenticated, authorized, and continuously monitored. Apply least privilege to reduce blast radius, separate high-risk tasks from broad access, and review permissions as models and workflows change. This matters because compromised credentials, prompt manipulation, or overbroad access can turn an AI tool into a fast-moving insider risk.

Technical breakdown

Why centralized authorization matters in distributed systems

Centralized authorization separates the decision about access from the application that enforces it. Instead of embedding policy logic in each service, applications call a Policy Decision Point that evaluates human-readable rules and returns an allow or deny decision. That model matters because distributed environments create policy drift when every team implements authorization differently. Centralization also makes policy versioning, review, and audit logging possible at the control plane level, which is essential when identities are spread across microservices, Kubernetes, and cloud workloads.

Practical implication: move access decisions out of application code and into a centrally governed policy service.

How request-level authorization narrows blast radius

Request-level authorization evaluates each action against current policy rather than assuming broad session trust. That reduces the scope of compromise because a service or identity can only perform the specific operation allowed for that request. This is especially relevant in zero-trust environments where compromise is not prevented entirely, but its reach must be constrained. The technical value is containment: if an identity is stolen or abused, the attacker still faces policy boundaries at every action, not just at login.

Practical implication: design policies so a single compromised identity cannot execute unrelated actions or reach adjacent data sets.

Why workload identity and OpenID Connect are necessary but incomplete

OpenID Connect gives user authentication a standard federation layer, while SPIFFE gives workloads a verifiable identity for machine-to-machine trust. Those standards solve the question of who or what is making a request, but they do not decide entitlement. That distinction matters because many zero-trust programmes stop at strong identity proofing and still leave authorization hidden inside code. In practice, identity standards create the foundation, but policy governance must determine what the identity may do after it is authenticated.

Practical implication: treat authentication standards as prerequisites, not substitutes, for authorization governance.

NHI Mgmt Group analysis

Centralized authorization is the control plane zero trust was missing. Authentication and workload identity establish who is asking, but they do not govern what the identity is allowed to do. When authorization is buried in application code, every team becomes a policy engine, and the result is un-auditable permission drift. The practitioner conclusion is simple: zero trust fails operationally when entitlement is not centrally governed.

Identity standards have matured faster than authorization governance. OpenID Connect and SPIFFE reduce the friction of proving human and workload identity, but they do not remove the need for a separate decision layer. That means many organisations now have the identity layer needed for zero trust while still lacking the policy layer needed to enforce it consistently. The implication is that implementation maturity should be measured by decision control, not just by federation coverage.

Request-level policy is how blast radius becomes a measurable control. The article is right to frame containment as the business case, because broad entitlements turn every compromise into a lateral movement problem. A centralized policy engine makes access decisions explicit, reviewable, and revocable without code changes. Practitioners should treat blast-radius reduction as the primary zero-trust outcome, not a side effect.

Autonomous agents make hidden authorization logic unacceptable. Access review processes were designed for identities whose permissions are stable enough to be inspected and certified over time. That assumption fails when AI agents can act at runtime across tools and workflows, because permissions must be evaluated at the moment of action. The implication is that authorization governance must move from static entitlement review to request-time control for autonomous actors.

Identity blast radius: the central concept here is that zero trust only becomes operational when identity, policy, and enforcement converge at the point of request. Distributed systems and non-human identities widen the consequences of weak entitlement governance, so the control problem is no longer login assurance alone. Practitioners should map every high-risk action to a centrally owned policy decision.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Zero Trust Identity Guide

What this signals

Centralized authorization will become the operational test of zero trust. Identity verification is now table stakes, but programmes that cannot answer what each identity may do at request time will keep inheriting invisible privilege risk. Teams should expect policy engines to sit closer to application enforcement, with governance moving from code review toward decision control.

Policy-driven authorization also changes how AI agent risk is managed. As agents take on more delegated actions, static access reviews lose value because the meaningful control point is the runtime decision. Security teams should prepare for a future where agent entitlement is judged by policy boundaries and decision logs rather than by broad role assignment.

For practitioners

• Centralize authorization decisions Move entitlement logic out of application code and into a dedicated policy decision service so permissions can be reviewed, versioned, and audited consistently across services.
• Map request-level policy boundaries Define the exact actions each identity type may perform and test whether a stolen service credential can still reach unrelated data or functions.
• Pair identity standards with policy governance Use OpenID Connect for user federation and SPIFFE for workload identity, then verify that a separate authorization layer decides what each identity can do.
• Treat AI agents as policy subjects Write policies that govern agent actions at runtime instead of embedding permissions in code paths that assume the actor will remain static and predictable.
• Build audit-ready authorization logs Keep version-controlled policy history and decision logs so access reviews can answer who was allowed to do what, when, and under which rule set.

Key takeaways

• Zero trust fails in practice when organisations stop at identity proofing and leave authorization hidden inside applications.
• Centralized policy decisions improve containment because every request is checked against auditable entitlement rules instead of broad session trust.
• IAM and NHI teams should treat request-time authorization as the control that makes zero trust measurable across users, workloads, and agents.

Key terms

• Centralized Authorization Governance: A model where access rules are managed in one policy layer and enforced across many systems. It gives teams a single place to inspect, test, and audit decisions so they can prove what access was allowed, why it was allowed, and when the policy changed.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Request-level Authorization: Request-level authorization means access is decided for each request rather than once at login or network entry. It lets operators scope permissions by route, method, and identity, which is far more precise than broad network access and better suited to distributed systems and NHIs.

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.