Zero Standing Privileges (ZSP)

Zero Standing Privileges (ZSP) is the end state in which no person or machine holds privileged access between tasks, so a stolen administrator account or a forgotten role assignment grants nothing. Just-in-time (JIT) access is the mechanism that gets there: it creates a privilege when a specific request is approved and removes it when the task ends or its time limit passes. ZSP reaches only as far as the systems whose privileges can be granted and revoked on demand, which makes the list of what remains standing as important as the elevation workflow itself.

Just-in-Time Access as the Mechanism

JIT access replaces the standing assignment with a request. A user or workload asks for a named privilege on a named system, a policy or an approver decides, and the grant carries a time limit after which it is withdrawn whether or not anyone remembers to. This is least privilege applied to time as well as scope: the question is no longer only which rights an administrator needs, but for how long.

A JIT system can remove standing access in two ways, and a deployment has to know which one each target system allows. Where the target asks an external policy decision point on every request, as an application integrated through OpenID AuthZEN does, the privilege is a decision rather than a stored entitlement, and an approved elevation becomes an attribute the policy checks for the length of the task. Most privileged systems do not work that way. A database, an operating system, a directory or a cloud account checks its own role assignments, group memberships and local accounts, and a permit from a central decision point changes none of them. There ZSP needs a mechanism that writes the entitlement into the target when the request is approved and deletes it again afterwards, which is the path the diagram shows. Policy-Based Access Control (PBAC) runs into the same limit from the policy side.

The revocation is the part to test. An elevation that has expired in the request system but still exists in the target is a standing privilege with a ticket attached, so monitoring compares the grants recorded by the JIT system with the assignments actually present in each target, and flags any privilege that outlives its request.

Application to AI Agents

ZSP was conceived for human privileged access, but its strongest fit may be non-human. AI agents can be instantiated and decommissioned within seconds, which puts credential issuance and revocation well beyond the reach of ticket-driven provisioning and makes any standing agent credential an orphan waiting to happen. Issuing credentials at instantiation and revoking them automatically at decommission is ZSP applied to agents, and it depends on something observing both events: in practice, an AI Agent Registry that tracks runtime instances as well as agent definitions. Where an agent's authority is delegated onward to sub-agents, narrowing that authority at each hop instead of passing it forward intact extends the same principle across the delegation chain; see OAuth Token Exchange and Identity Chaining.

What ZSP Cannot Remove

Some privilege survives every ZSP programme, and a scope statement should name it rather than claim zero.

The elevation system itself holds standing privilege. To create and delete grants in the target systems it needs a service identity that can change role assignments in all of them, which makes it one of the most privileged identities in the estate and a better target for an attacker than any single administrator. Its credentials belong in Privileged Secret Management, and changes to its own configuration and policies need a second approver.

Break-glass accounts keep permanent privilege by design, because the elevation path can fail. When the identity provider, the approval workflow or the elevation service is down, someone still has to be able to restore it. These accounts are few, vaulted, alerted on at every use and given a new credential afterwards; Single Sign-On (SSO) makes the same argument for an outage of the identity provider.

Target systems without an interface for granting rights stay outside the model. Legacy applications, network appliances and embedded systems often know only local accounts with a shared password, which a vault can check out and rotate but a JIT system cannot create and delete per task. For those the realistic goal is brokered, recorded access through Privileged Session Recording and Management, listed as an exception with an owner rather than counted as covered.

The figure to report is therefore coverage: the share of privileged systems where access is granted on request and verifiably revoked, next to the list of standing privileges that remain and the reason each one does.

The Cost to Administrators

Every elevation puts a request, a decision and a wait in front of work that used to start at once. The request path has to be short enough that people use it: a policy that approves routine requests on its own, a human approver only where the risk calls for one, and an explanation to administrators of why their permanent rights are going away.