Zero standing privilege (ZSP) is an access model in which no identity, whether human, machine or AI agent, holds privileged access it isn't using at that moment. Privilege is granted on request, limited in time and scope, and removed when the reason for it ends. The resting state of every account is zero.
The term is usually credited to Gartner, around 2019. Since then it has been attached to a lot of products that rotate credentials or add an approval step and never touch the privilege underneath, and I don't think many organizations have done the real thing. This post is a definition tight enough to tell the difference, a test you can run this afternoon, and the order to do the work in.
Key takeaways
- ZSP has three conditions: the default is zero, every grant is limited in time and scope, and every grant ends when its reason ends, with the timer as a backstop.
- Most products sold as ZSP meet the first two conditions. The third is where the gap is, and for AI agents it's the whole problem.
- The test is one question: can any identity perform a privileged action right now without requesting anything first? Every yes that isn't on your break-glass register is standing privilege.
- Do the work in this order: find the privilege, sort it by consequence, write policy, automate the grant, wire up revocation, then remove the standing entitlements. Removing first is how programs die.
Where standing privilege comes from
Privilege accumulates as a side effect of people doing their jobs.
An engineer gets production access during an incident and nobody revokes it afterward. A contractor is still in the admin group for a migration that finished 18 months ago. A service account has broad permissions because narrowing them would have meant understanding what the service does, and the deadline was Friday. Someone changes teams and keeps everything from the old one.
A few years of this and a large share of your privileged entitlements are dormant: held by identities that aren't using them and often don't know they have them. Each one is a credential to steal or a session to hijack, and it hands an attacker admin the moment the account is compromised.
That's standing privilege. A permission that stays attached to an account between uses, instead of being granted for a task and removed when the task ends.
The vault era answered this by guarding the privilege better. Vault the credentials, rotate them, put MFA in front, record the sessions. All of that is worth doing, and all of it leaves the privilege in place. A locked door in front of a standing credential is a standing credential with a door.
ZSP removes the privilege. By default, no identity holds elevated access at all.
What zero standing privilege actually requires
Three conditions. Two out of three is a weaker thing with the same name, and most products sold as ZSP stop at two.
1. The default is zero
No identity holds privileged access at rest. No dormant admin roles waiting to be assumed, no always-on group memberships, no service account carrying a permission it uses twice a year. Privileged access exists while a specific task needs it and at no other time.
2. Every grant is limited, in time and in scope
A grant has a ceiling on how long it lasts and a boundary on what it covers. Restarting one service does not come with production admin attached, and a two-hour window does not quietly become a standing role because someone forgot to set an end. The window is the maximum, and a maximum is a backstop, which brings us to the condition most products skip.
3. Every grant ends when the reason ends
The grant should end when the task completes, the session closes, the person moves off the team that justified it, or their device falls out of compliance. The timer catches whatever those miss. If the clock is the only thing that ends a grant, then from the moment the reason ends until the moment the timer fires you have standing privilege. Shorter, but the same kind.
Concretely: you terminate an employee at 10:04 and their elevation runs to 14:00. Disabling the account stops new logins. It doesn't touch the role assignment, which sits there until 14:00, and it doesn't touch any session already open on tokens issued before 10:04, which ride until they expire. Ending the grant on the event instead of the clock is what continuous access evaluation is for. The OpenID Foundation's Continuous Access Evaluation Profile (CAEP) and Shared Signals Framework are the published standards: the identity provider emits a signal (session revoked, device out of compliance, credential changed) and every system holding a grant for that identity acts on it. I'll come back to this in the agent section, because that's where a four-hour gap turns into a four-thousand-action gap.
The one-question test for zero standing privilege
Run this without a vendor in the room.
Can any identity, human, AI agent or service, perform a privileged action right now without requesting anything first?
Write down every yes. Then strike the ones on your break-glass register, meaning the accounts you've deliberately kept standing for the day the elevation path itself is down, hardware-backed, with an alert and a review on every use (more on those further down). What's left is your standing privilege. If the list is empty, you have ZSP. If it isn't, you have less standing privilege than you did, which is real progress and a different thing.
Zero standing privilege vs least privilege, and three other things it gets confused with
Each of these models answers a different question: how much access, who can retrieve it, when it's granted, what happens during a session. Only ZSP asks whether privilege exists at rest at all. That's the resting-state column, and it's where standing privilege lives or doesn't.
| Model | What it controls | Resting state | What it leaves standing |
|---|---|---|---|
| Least privilege | How much access an identity holds | Access persists, narrowed | Narrow privilege held forever is still standing privilege |
| Vault-based PAM | Who can retrieve a privileged credential | Credential exists and stays valid | The credential, and the account behind it |
| Just-in-time access | When privilege is granted, and for how long | Zero between grants | Whatever is left of the window after the reason ends |
| Session management | What happens during a session | Access persists | Records misuse; doesn't touch the standing grant |
| Zero standing privilege | Whether privilege exists at rest at all | Zero | Break-glass paths and systems that can't do dynamic grants |
Least privilege and ZSP are orthogonal, and you want both. Least privilege shapes the grant. ZSP decides whether the grant exists when nobody is using it.
Why a vault doesn't get you to zero standing privilege
Vaulting solved a real problem: privileged credentials in spreadsheets, shell scripts, wiki pages and people's heads. Centralize, rotate, audit. That was progress and I'm not arguing against any of it.
But a vault's control point is retrieval. The credential still exists, it's still valid, and it still maps to an account that still holds privilege. What the vault governs is who can check it out. So the standing privilege is intact, and the vault is now the one thing between an attacker and all of it at once. Anything that bypasses the vault bypasses the control: a cached credential, a session opened before rotation, a key someone extracted once and hardcoded into a build script, a break-glass account someone started using for convenience.
Vaulting manages standing privilege. Do both, but only one of the two changes what an attacker finds after they're in.
There's a longer version of this argument in Vaults won't get us to zero standing privilege.
Why just-in-time access alone isn't zero standing privilege
This is the section I'd keep if I had to cut everything else, because JIT is where most programs stop and declare victory.
JIT is the mechanism that makes ZSP possible. It grants privilege for a window. For the rest of that window after the reason ends, the privilege is still there. The window got smaller, and that's the whole of what changed.
How it fails in practice:
- Windows sized for convenience. Eight-hour grants exist because engineers hated re-requesting every hour, which I understand. Eight hours is also most of a workday of standing privilege.
- Grants that outlive their reason. The incident closes in 20 minutes. The elevation runs two hours. For the remaining 100 minutes that engineer holds production access that nobody needs and nobody is watching, and if their laptop is the one that gets phished that afternoon, the attacker inherits it.
- Broad grants for narrow jobs. Restart one service, receive production admin.
Shortening the windows trades risk for friction, and friction is what kills access programs, because people route around them. The fix is grants that end when the reason ends, with the timer as the backstop. That's condition three, and a JIT product with a shorter default timer is still a JIT product.
Zero standing privilege for AI agents
An AI agent is a privileged identity. It authenticates and it acts on production systems with the entitlements it holds. It differs from a person in velocity and in judgment. A person makes a few dozen deliberate actions in a session. An agent makes hundreds on a single approval, at machine speed, and it never logs off.
Right now most agents run on the worst form of standing privilege there is: API keys sitting in config files, OAuth refresh tokens that live for months, a shared bot user everyone on the team knows the password to, and a service account scope inherited from whoever wired the agent up, which usually means whatever made the demo work. An agent acting for your junior analyst has the analyst's permissions and none of the analyst's sense of which actions are unthinkable. Read access that's routine for the person is privileged for the agent, because the agent can read everything, and it will if a poisoned document tells it to.
So the three conditions apply, with one change in unit. For a person, the grant is a session. For an agent, a session-level grant is standing privilege: approve once, act all afternoon. The unit of control has to be the individual call.
In practice that means the grant is scoped to a task; a session is too coarse. The credential never enters the agent's context: something that isn't the agent injects it at the boundary and runs the command, so a prompt injection has nothing to steal. And every call is checked against the purpose the session declared, so a session opened to "summarize support tickets" that turns into a customer-table export ends mid-flight. That's condition three at the granularity agents operate at. The gap between "reason ended" and "timer fired" is measured in thousands of actions here, which is why I keep coming back to it.
The same property makes agents the attacker's tool of choice against your standing privilege. In July 2026, Hugging Face disclosed an intrusion run by an autonomous agent framework across a swarm of short-lived sandboxes. It came in through the dataset-processing pipeline, harvested long-lived pod secrets, service-account tokens and cloud credentials, found one connector credential shared across clusters, and moved laterally for four and a half days. The model behind it did nothing sophisticated. Every standing credential was a step it could take without asking anyone. Hugging Face's own remediation list (rotate everything, move to workload identity, isolate the clusters, narrow every credential) is step five of this post. Your agents need ZSP, and your standing privilege will not survive contact with someone else's agent. Here's the longer read on that incident.
How to get to zero standing privilege
Seven steps, in this order. The order is most of the advice. Start at policy without discovery and you're writing rules for an estate you can't see.
1. Find what privilege exists
Every privileged entitlement across identity providers, cloud accounts, databases and infrastructure. Include service accounts and machine identities; they're usually the largest and least understood pile. Expect the number to be bigger than anyone guessed.
2. Sort by what a compromise costs
Production data, identity provider admin, CI/CD signing keys and the secrets manager itself are in a different tier from staging. Job title has nothing to do with it. This decides where you start.
3. Write elevation policy per class
Who may request, what approval it needs, maximum duration, scope. High-consequence paths get a human approver. Routine access auto-approves against policy, or the program gets routed around within a month.
4. Automate the grant path
Requests, approvals and provisioning in the tools people already use, in seconds. This step decides adoption. A program that makes an on-call engineer wait on a ticket at 3 a.m. gets dismantled after its first bad incident, and it will deserve it.
5. Instrument revocation
Tie the grant's end to the reason's end: task done, session closed, termination, device compliance, group change. Without this you have time-boxed standing privilege, which is where the JIT section left off.
6. Remove the standing entitlements
Only now, with the grant path working and revocation wired in. Do this before steps 4 and 5 and one of two things happens: you break people's jobs, or you swap standing privilege for time-boxed standing privilege. Either way the program loses its credibility, and credibility on access programs does not come back.
7. Measure, then expand to the next class
Report two numbers for the class you just finished: the share of its privileged entitlements still standing, and approval latency, so you know whether people are living with it. Then take the next class down the consequence list. The first class is the slow one because you're building the grant path. Every class after it reuses that path.
The limits of zero standing privilege
Every honest program has an exception list. Four places the model doesn't reach cleanly.
Break-glass access
Some failures take out the elevation path itself: the identity provider is down, the network is partitioned, the automation is the thing that broke, or the vendor's control plane is having a bad day. You need a path that doesn't depend on the system being up, and that path is standing privilege by definition. So design it as standing privilege: hardware-backed, with an alert and a review on every use. A small, watched exception is defensible. An exception nobody wrote down is the one that ends up unwatched. This is the register the one-question test told you to strike. Keep it short enough to read aloud.
Legacy systems
Older infrastructure often has no API for granting and revoking access. Put a gateway in front, add a compensating control, or accept a documented exception with tighter monitoring. I don't have a cleaner answer than that for a 25-year-old mainframe, and I'd be wary of anyone who says they do. A rollout that assumes there are none stops at the first one.
Service accounts and machine identities
The largest ZSP violation in most estates, and the one most programs quietly defer. They outnumber humans, hold broad permissions, and were provisioned by people who have since left. They can't use a request workflow built for humans. They need short-lived credentials, workload identity federation, or brokered access: same principle, different mechanism. AI agents are the fastest-growing members of this category and got their own section above.
People
The engineer who has held production access for six years hears ZSP as a demotion. That's a fair reaction and it deserves a real answer: the point is to shrink what an attacker gets when they phish you. Skip that conversation and you get quiet non-compliance in place of loud objection, and you'll find out about the quiet kind from an auditor.
What to measure
The headline number is the share of privileged entitlements that are standing. If you ran the one-question test, that list is your starting numerator. The rest of the table supports it.
| Metric | What it tells you | Target |
|---|---|---|
| Share of privileged entitlements that are standing | How much privilege exists at rest | Down |
| Coverage | Share of privileged paths under the model | Up |
| Median elevation duration | Whether grants are right-sized or padded for convenience | Down |
| Time to revoke when the reason ends | Event-driven or clock-driven | Down |
| Approval latency | Whether people can live with it | Down |
| Break-glass uses | Rare, and every one reviewed | Flat and low |
| Access review hours | The hours the program gives back | Down |
Two of these carry more weight than the others. Approval latency is the canary: drive standing privilege to near zero while every request takes 20 minutes and you've built a shadow process with no controls at all. Access review hours are what funds the program. Standing privilege is why quarterly recertification is miserable (thousands of entitlements, reviewed by managers who can't judge them, bulk-approved because the deadline is Friday). Remove the standing entitlements and most of that work disappears, and reclaimed hours are the one line in this post that finance will read.
Zero standing privilege FAQ
What is zero standing privilege?
No identity holds privileged access when it isn't using it. Privilege is granted on request, limited in time and scope, and revoked when the reason for it ends. The resting state of every account is zero.
What is the difference between least privilege and zero standing privilege?
Least privilege governs how much access an identity holds. ZSP governs whether it holds any at rest. A narrowly scoped permission that persists forever satisfies least privilege and is still standing privilege.
Is zero standing privilege the same as just-in-time access?
No. JIT is the main mechanism for getting there, but grants that end on a timer outlive their reason. ZSP also requires that access end when the justifying condition changes.
Is zero standing privilege the same as zero trust?
No. Zero trust is an architecture philosophy: verify every time. ZSP is one access model that applies it to privileged access. You can run zero trust without ZSP, and most organizations do.
Is zero standing privilege realistic?
Yes, defined as zero standing privilege outside a small, deliberate, watched break-glass register. Zero exceptions is the part that isn't realistic.
Does a password vault give me zero standing privilege?
No. A vault controls who can retrieve a credential. The credential still exists and the account behind it still holds privilege.
Does zero standing privilege apply to service accounts and AI agents?
Yes, with a different mechanism, because neither can use a request workflow built for humans. Service accounts need short-lived credentials, workload identity federation, or brokered access. Agents need task-scoped grants, credentials that never enter their context, and every call checked against the purpose the session declared.
How do you get to zero standing privilege?
Discover what privilege exists, sort it by consequence, write elevation policy per class, automate the grant path, instrument revocation, then remove the standing entitlements. In that order. Programs that remove entitlements before the grant path works break people's jobs and lose the room.
What's fixable by the end of the quarter
Three moves, none of which needs a purchase.
- Run the test. List every account, human, service or agent, that can do something privileged right now without asking. Strike the break-glass register. Most teams have never written down what's left.
- Pick your two highest-consequence paths, and only two.
- Fire a revocation on a live grant and time it. If the answer is in hours, that's your first project.
Where Venice fits
Hold us to the three conditions. Hold everyone to them, especially anyone who added zero standing privilege to their homepage the year the term got popular.
Venice is privileged access management (PAM) built for humans, service accounts and AI agents, and it exists to take standing privilege away. The mechanism is role elevation. Your engineer asks for a role, gets that role and nothing broader, for the window they asked for, and the role is removed when the work ends or the window closes, whichever comes first. Between requests it doesn't exist, so there's nothing for an attacker to log in with. For agents the same model runs through the Venice Identity Gateway: the agent connects through Venice, Venice holds the credential, and every tool call is allowed or denied before it runs.
That covers conditions one and two. On condition three, the one I've spent this post saying most products skip: Venice ends the grant when the task completes, the session closes, or a call drifts from the purpose the session declared. The timer is the backstop, the same way I described it above. That's the bar we asked you to hold us to, and it's the same one we hold ourselves to.
What Venice doesn't do: design your break-glass register, or stop the phish that gets someone's password. Those belong to your incident team and your email security. What it does is empty the list your team wrote down in the one-question test, and that list is fixable this quarter.
