Zero trust leaves a privilege gap that zero standing access must close

At a glance

What this is: This is an analysis of why Zero Trust alone leaves standing privilege untouched, and why Zero Standing Privileges is needed to remove persistent administrative power.

Why it matters: For IAM, PAM, NHI, and agentic AI programmes, the issue is that secure connectivity still leaves excessive runtime authority in place unless privilege itself is made ephemeral.

Context

Zero Trust Architecture controls who or what can reach a resource, but it does not by itself govern what that identity can do after arrival. That distinction matters because many cloud and workload environments still retain persistent administrative rights, static roles, and long-lived credentials that survive the connection decision.

The governance gap is the difference between access to the door and power inside the room. In NHI, autonomous AI, and human identity programmes, runtime authorisation has to cover task scope and duration or Zero Trust becomes a network posture with no privilege boundary.

The article argues that Zero Standing Privileges closes that gap by removing standing power at rest and issuing it only for the task at hand. That framing is typical of mature cloud estates where network verification has already advanced faster than privilege governance.

Key questions

Q: What breaks when least privilege is not enforced in a zero trust model?

A: The model stops containing blast radius. If an identity has broad reach, strong authentication only proves who or what entered the environment, not how far that actor can move once inside. Least privilege has to be enforced at the entitlement layer and the network layer, or compromise still spreads across the environment.

Q: Why do standing privileges increase security risk even when access appears legitimate?

A: Standing privilege creates a long exposure window. If credentials are stolen, misused, or left behind after a role changes, the attacker or insider already has persistent elevation and no additional access check is needed. Time-bound access reduces that risk because the privilege only exists when a task has been explicitly approved and executed.

Q: How do security teams know if just-in-time access is actually working?

A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.

Q: How should organisations govern workloads and AI agents that act continuously?

A: They should authorise those actors at execution time, not only at provisioning time. Workloads and AI agents can perform multiple actions within a single session, so fixed entitlements overstate what they need. Runtime authorization and ephemeral privilege match their behaviour more closely than static access reviews do.

Technical breakdown

Zero Trust secures the connection, not the privilege

Zero Trust Architecture evaluates contextual signals such as device posture, IP location, identity validity, and request context before establishing access. That means it controls whether a session can form and how traffic is isolated, but it does not decide whether the identity holds broad cloud permissions, static database rights, or admin-level entitlements after the connection is made. In practice, a secure channel can carry excessive privilege just as safely as a legitimate one. The mechanism is sound for reachability, but incomplete for authorisation. Practical implication: separate connectivity decisions from runtime privilege decisions so standing rights are not assumed to be safe once the session starts.

Practical implication: separate connectivity decisions from runtime privilege decisions so standing rights are not assumed to be safe once the session starts.

Zero Standing Privileges removes standing power at rest

Zero Standing Privileges is the model in which privileges do not exist continuously. Instead, access is minted only when a task begins and revoked when the task ends, so the identity never retains persistent administrative power between actions. This is especially relevant for workloads, service accounts, and autonomous agents that execute repeatedly without human oversight. The control logic changes from grant-and-wait to issue-and-expire, which is the difference between static exposure and task-scoped authority. Practical implication: treat persistent admin roles and long-lived cloud permissions as the design defect, not the implementation detail.

Practical implication: treat persistent admin roles and long-lived cloud permissions as the design defect, not the implementation detail.

Runtime authorization changes the decision point

Runtime authorization evaluates the intent of the request, not just the identity of the requester. That means the policy question becomes who is asking, on whose behalf, for what task, at what scope, and for how long. This is materially different from provisioning-time access design, where the assumption is that privilege can be safely defined in advance and left in place. For autonomous AI pipelines in particular, intent can change within a session, so static access models over-approximate what the actor should retain. Practical implication: authorise use cases at execution time when task scope is variable or agent-driven.

Practical implication: authorise use cases at execution time when task scope is variable or agent-driven.

NHI Mgmt Group analysis

Zero Trust is necessary but structurally incomplete when privilege remains standing: the model was designed to decide whether an identity may reach a resource, not to govern the authority it carries once connected. That leaves a persistent privilege layer outside the control boundary. In cloud estates, the result is a secure path to excessive power rather than a secure environment. The practitioner conclusion is that connectivity control and privilege control are different disciplines.

Standing privilege creates blast radius even when the session is clean: if the identity arrives through a verified channel but retains persistent admin rights, the attacker inherits the same authority surface. This is not a network problem; it is a privilege persistence problem. The named concept here is privilege gap at the point of action, where access has been approved but the amount and duration of power have not. The practitioner conclusion is that runtime authorization has to own the final enforcement decision.

Zero Standing Privileges is the control model that matches modern runtime behaviour: cloud workloads, service accounts, and autonomous agents act repeatedly, often outside human work cycles. A standing role or long-lived credential assumes the actor can safely hold power between tasks, which is increasingly untrue. The implication is that identity governance must move from entitlement preservation to task-scoped issuance. The practitioner conclusion is to design for ephemeral authority, not persistent availability.

Autonomous pipelines make the privilege gap more visible, not less: the article correctly ties Zero Standing Privileges to autonomous AI because these systems do not merely connect, they act. That means the old assumption that identity can be reviewed while privilege remains stable becomes weaker, especially when actions are machine-timed. The practitioner conclusion is that agentic and workload governance must be built around issuance and expiry, not after-the-fact review.

The useful distinction is between network trust and authority trust: Zero Trust answers who gets through the gate, while Zero Standing Privileges answers what they are allowed to do inside. Combining them does not duplicate controls; it closes the handoff where many modern access models fail. The practitioner conclusion is to treat privilege as a runtime state, not a persistent entitlement.

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.
• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Privilege persistence is the real control gap: many programmes have improved connection security faster than authority control, which leaves cloud roles, service accounts, and agent permissions standing long after the request that justified them has passed. When privilege is treated as a runtime state, the design target shifts from access allowance to access expiry.

Zero Trust and ZSP should be treated as complementary controls, not substitutes: one governs entry conditions, the other governs task-scoped authority. That pairing matters most where machine actors and autonomous pipelines execute without a human in the loop, because post-login review cannot compensate for privileges that never should have remained available.

The most durable governance pattern is to make privilege time-bound by default and exception-driven when persistence is genuinely required. That approach aligns human, NHI, and autonomous identity programmes around the same operational question: what power exists right now, and why?

For practitioners

• Define separate controls for connectivity and privilege Map where Zero Trust ends and privilege enforcement begins in your cloud, workload, and agent pathways. If the same approval decision is being used for both reachability and authority, standing privilege is still present.
• Eliminate persistent admin roles Inventory cloud IAM policies, database credentials, and service account grants that remain valid between tasks, then replace them with task-scoped issuance and automatic revocation.
• Shift to runtime authorization for machine actors For workloads and autonomous agents, evaluate access at execution time using request intent, scope, and duration rather than relying on fixed entitlements set during provisioning.
• Validate that JIT really removes standing access Check whether your just-in-time flow merely checks out an existing credential or actually removes the underlying privilege when the task ends.
• Review blast-radius assumptions across hybrid estates Test whether a compromised session can still pivot through cloud accounts, databases, or administrative consoles after the initial Zero Trust check has succeeded.

Key takeaways

• Zero Trust reduces exposure at the connection layer, but standing privilege still creates an operational path to excess authority.
• The article’s central gap is not reachability, it is persistent power that survives the access decision.
• Zero Standing Privileges closes that gap by making authority task-scoped and time-bound instead of continuously available.

Key terms

• 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.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Privilege Gap: The difference between the access an identity has by default and the access it actually needs to complete a task. A large privilege gap increases attack surface, complicates reviews, and makes offboarding harder because unused elevation often lingers after the business need has ended.

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.