Request-based authorization is displacing privilege management

At a glance

What this is: Pomerium argues that modern access control is shifting from privilege management to per-request authorization as machine and AI-driven systems replace human-paced sessions.

Why it matters: This matters to IAM teams because NHI, autonomous, and human governance programmes all have to decide whether access is governed at credential checkout, session start, or each request.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Pomerium's analysis of per-request authorization for modern access control

Context

For identity programmes built around privilege, the core assumption is that access can be approved, checked out, and monitored over a meaningful session window. That model is breaking as AI agents, workloads, and software-driven services make continuous decisions without waiting for a human to open or close a session. For NHI teams, the question is no longer who owns a credential, but what policy should decide each action in real time.

Pomerium frames the change as a move from controlling credentials to controlling authorization decisions. That is a practical identity governance shift for NHI, autonomous, and human access because the control point moves closer to the transaction itself. Existing PAM and vault-centric models still matter, but they no longer cover the full operating speed of API-driven systems and agentic workflows.

Key questions

Q: How should security teams govern machine access when requests are continuous?

A: Treat each request as the unit of control. Use policy that evaluates identity, context, resource sensitivity, and time at runtime, rather than relying on a one-time approval or session start. Vaults can still store and rotate secrets, but the access decision needs to happen at the moment of action, especially for service accounts and workload identities.

Q: Why do privileged access models struggle with NHI and agentic workloads?

A: They assume access is rare, elevation is exceptional, and sessions define trust. NHI and software-driven systems often operate continuously, so those assumptions no longer hold. When requests never stop, a control model built around checkout, approval, and session brokering leaves the most important decision outside the runtime path.

Q: What breaks when organizations rely on vaulting instead of authorization?

A: Vaulting protects credentials, but it does not decide whether an action should be allowed. That means teams can still end up with valid secrets and excessive runtime access, even if the vault is well managed. The failure is architectural, not just operational: custody is not the same thing as control.

Q: How do zero trust and least privilege change for autonomous systems?

A: They move closer to the request itself. Least privilege can no longer be treated as a provisioning-time state only, because software may select actions dynamically and act without a human approval gate. Zero trust then becomes a continuous authorization problem, with policy re-evaluated each time an identity tries to do something.

Technical breakdown

Why session-based privilege breaks down for machine-driven access

Session-based privilege assumes a bounded trust window: credentials are checked out, a session starts, actions happen, and the session ends. That works when a human operator is the actor and activity is episodic. In machine-operated environments, requests are continuous, credentials propagate across services, and the meaningful decision is not whether the identity is privileged, but whether a specific action should be allowed at that instant. The architecture therefore shifts from session brokering to request evaluation, with context becoming part of the authorization decision. Practical implication: design controls around per-request policy evaluation rather than relying on session start as the main trust boundary.

Practical implication: move authorization closer to each request instead of treating the session as the trust boundary.

Why vaults are not a control plane for ephemeral workloads

A vault protects and distributes secrets, but it does not decide whether an action should occur. That distinction matters in ephemeral, distributed, API-heavy environments where secrets may be short-lived but request volume is high. Vaulting remains useful for custody and rotation, yet it does not solve the authorization problem created when software acts autonomously across services. The control plane has to inspect identity, context, and request intent every time, because the same credential can be reused across many calls and many services. Practical implication: keep vaults for secret custody, but separate them from the authorization layer that governs runtime access.

Practical implication: keep secret custody separate from runtime authorization and do not treat vaulting as sufficient access control.

How continuous authorization changes access control architecture

Continuous authorization means the system re-evaluates access at the moment of use instead of assuming the earlier approval still applies. That model fits workload identity, service-to-service calls, and agentic systems because trust can decay quickly as context changes. It also changes operational design: policy must be expressive enough to account for identity type, target resource, request context, and time-sensitive conditions without requiring a manual gate for every call. This is not the same as adding more approval steps. It is a shift in where authority lives in the stack. Practical implication: build policy engines that can evaluate context on every call and deny by default when conditions no longer match.

Practical implication: enforce context-aware policy on every call and deny by default when conditions drift.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Privilege management is no longer the primary security control for machine-driven identity. PAM was designed for rare elevation, bounded sessions, and human-paced review. That premise fails when software acts continuously, credentials spread between services, and the real decision is whether a request should be allowed now. The implication is that identity governance has to stop treating privilege as the control surface and start treating authorization as the governing layer for modern access patterns.

Request-based authorization exposes the limits of credential-centric governance. When the access decision is made at runtime, the credential becomes only one input to policy, not the control itself. This is especially visible in NHI estates where secrets, tokens, and service identities are reused across distributed systems. The field should read this as a governance reset, because custody without decisioning leaves the highest-risk part of the transaction ungoverned.

Identity blast radius is shrinking from sessions to individual calls. That shift is the right named concept for this category change, because control is now evaluated at the moment of action rather than over a long-lived access window. The consequence is broader than security tooling. It changes how teams think about accountability, auditability, and least privilege across human, NHI, and autonomous actors. Practitioners should treat per-request decisioning as the new unit of control.

Autonomous execution makes intent the scarce governance signal. The article’s core point is that software can now decide and act without waiting for a human to open a session or approve a request. That does not eliminate NHI controls, but it does invalidate the assumption that access can be governed only after a session begins. The implication is that identity programmes must distinguish between credentials that authenticate an actor and policy that governs what that actor may do in motion.

Zero trust moves from a network posture to a runtime identity posture. The strongest reading of this shift is not about product architecture, but about where trust gets re-evaluated. If trust is only checked at login or checkout, the control fails for workloads that never stop moving. Practitioners should interpret this as a mandate to align authorization, telemetry, and policy with runtime behaviour across all identity types.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly remediation often follows discovery.
• The Ultimate Guide to NHIs , Key Challenges and Risks explains why visibility gaps, over-privilege, and unrotated credentials still define the control problem.

What this signals

Identity programmes should expect authorization to become the dominant control plane. As machine-operated systems make more decisions without human pacing, teams will need policy that can evaluate context at runtime rather than waiting for a session boundary. The practical effect is that IAM, PAM, and NHI governance converge around decision quality, not just credential custody.

Per-request controls will expose where access reviews are still anchored to static entitlement records. The fastest way to reduce operational drag is to separate secrets management from access decisioning and then measure how often runtime policy denies actions that would otherwise look legitimate in a vault-centric model. That is the signal that your programme has moved from storage control to true authorization control.

With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, the problem is not only over-entitlement but over-reliance on controls that assume a stable session. The concept to watch is identity blast radius, because it captures how much damage a single runtime decision can create when credentials are reused across distributed systems. Teams that can narrow that blast radius at decision time will be better positioned for both NHI and autonomous governance.

For practitioners

• Map every privileged workflow to its actual trust boundary Identify where your programme still assumes a session start, approval gate, or credential checkout is the point of control. Replace that assumption with per-request evaluation for workloads, services, and agent-driven calls, especially where secrets are reused across distributed systems. Use the Ultimate Guide to NHIs as the baseline reference for governance scope and visibility.
• Separate secret custody from access decisioning Keep vaulting, rotation, and storage controls, but do not treat them as substitutes for runtime authorization. The policy engine should decide whether a request is allowed based on identity, context, and target resource, while the secret store only manages credential custody. That separation becomes essential when access is short-lived and machine-originated.
• Rework PAM assumptions for machine and agent identities Review which PAM workflows were built for human administrators and do not scale to continuous machine activity. Approval workflows, session brokering, and checkout models may still be useful for legacy use cases, but they should not define the primary access layer for NHI estates. Align your controls with the OWASP Non-Human Identity Top 10 where secrets, overprivilege, and runtime access intersect.
• Instrument decision-level audit trails Log the policy decision that allowed or denied each action, not just the existence of a session or token. That gives IAM and security teams a defensible record for investigations, recertification, and access review in environments where access is evaluated continuously. Link those records back to lifecycle governance so service accounts and workload identities can be reviewed against actual runtime use.

Key takeaways

• Privilege-centric access models still matter, but they no longer define the primary control surface for machine-driven systems.
• The evidence across identity research points to the same problem: excessive privilege and slow remediation leave runtime access exposed.
• Practitioners should move toward per-request authorization, decision-level logging, and runtime policy that can keep pace with NHI and autonomous behaviour.

Key terms

• Per-request authorization: Per-request authorization is an access model that evaluates each action when it is attempted, rather than relying on a one-time approval or session boundary. In practice, it combines identity, context, and policy at runtime so machine and autonomous actors can be governed at the point of action.
• Identity blast radius: Identity blast radius is the amount of damage a single identity can cause when its credentials, privileges, or runtime decisions are abused. For NHI and autonomous systems, the concept is useful because access often propagates across services, making the impact of one decision much larger than the original entitlement suggests.
• Runtime authorization: Runtime authorization is the process of deciding whether an identity may perform a specific action while that action is being requested. It differs from provisioning-time privilege assignment because it uses live context, not just stored entitlements, to determine whether access should proceed.
• Session brokering: Session brokering is a control pattern that places an intermediary between the user or service and the target system so activity can be approved, recorded, and constrained. It is useful for human administration, but it becomes less effective when access is continuous and the actor is a workload or agent.

Deepen your knowledge

Per-request authorization, NHI runtime governance, and zero trust for machine identities are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still built around sessions and vaults, this course is a practical next step.

This post draws on content published by Pomerium: Privilege Access Is the Past. Per Request Authorization Is the Future. Read the original.