Your team did the hard foundational work. Credentials are vaulted, multi-factor authentication (MFA) is on and your zero standing privilege (ZSP) pilot closed on schedule. Access requests flow through a workflow, and the early numbers look good.
Then an auditor asks a question you can’t answer cleanly, or a service account nobody owns turns up with permanent domain rights. Starting ZSP and finishing it are two different projects: the first is a policy decision and the second is an architecture problem. That’s where most programs quietly stall.
Standing privilege isn’t a single setting you switch off
It hides in the accounts, environments and exceptions the pilot never touched. Zero standing privilege holds only when control reaches every identity and every action. The interactive users you started with are only a fraction of that.
AI agents raise the stakes. They are non-human identities (NHI) that act at machine speed and run on credentials, so any standing privilege they hold is the highest-risk kind.
Where zero standing privilege programs stall
The failure modes repeat across teams:
- Scope narrows to human sessions while service accounts and other non-human identities keep their always-on access.
- Just-in-time (JIT) becomes a checkbox rather than a policy you tune against real work patterns. The windows end up too tight to use or too loose to matter.
- Exceptions granted during rollout never get reviewed, and standing access creeps back one approval at a time.
- Approval steps add friction, and people learn to route around them.
- Policies written for the on-premise estate never extend to cloud consoles, DevOps pipelines or third-party access.
None of these point to a weak team. They are what happens when a model built for a subset of identities meets the full environment. Recognizing your own program in that list is the first step toward closing the gap.
The service account problem: securing non-human identities
Service accounts, API keys, application credentials and automated pipelines outnumber your people. Often by a wide margin. They hold standing access longest because rotating or removing it risks breaking production.
Non-human identities are where zero standing privilege is won or lost
The work starts with an honest inventory. Most teams underestimate how many service accounts exist and what they can reach. From there, map each account to its dependencies before you change anything, so rotation doesn’t take down the service that relies on it. Secrets management becomes a ZSP discipline of its own: vault the credential, rotate it and move toward dynamic credentials that exist only for the task.
In CI/CD and DevOps work, this collides with developer velocity, so governed access has to feel native to the tools engineers already use. Third-party and vendor access is the standing-access problem you don’t fully control, and it earns the same time-bound treatment as your own.
The multi-cloud gap: ZSP across AWS, Azure and SaaS
ZSP that works in one environment gets complicated the moment access spans on-premise systems, multiple clouds and SaaS. On-premise policies don’t translate directly to cloud workloads: the privilege models in AWS, Azure and Google Cloud each behave differently. SaaS application access is often the blind spot where a program has no visibility at all.
Chasing one standard with a different tool for each environment is how coverage debt builds up. Consistent enforcement needs one policy model that spans environments. A stack of point tools stitched together leaves gaps at the seams.
The gap after login: controlling privileged access at runtime
Here’s the pattern underneath every stalled program. Most identity and access tools make their decision at login and step out of the way after. Privileged Access Management (PAM) secures the credential. Identity providers verify who’s asking. Cloud entitlement tools define what a permission allows. The real risk starts after the connection opens, and that’s exactly where those controls go quiet.
Finishing ZSP means moving the point of control from the login to the action. Access is brokered through a control plane instead of granted directly. The credential is injected at the moment of use and never reaches the user or the agent. Each action is authorized while the session is live, and the session itself is recorded and can be stopped.
This matters most for AI agents, which keep acting long after the connection opens. A check at login says almost nothing about what they do next. Control that reaches past login is what makes standing privilege optional instead of assumed. It’s not something point tools can bolt on after the fact.
What a platform has to do to deliver ZSP
Delinea sequences a defensible ZSP program across five stages: discover identities and their access, govern accounts and secrets, make access just-in-time, control access at runtime and eliminate standing privilege as the default. A program that stops after the first three stages has done the visible work but left the exposure that matters.
Above: How Delinea sequences a zero standing privilege program, from discovery to non-persistent access.
The Delinea Platform is built to cover all five across human, machine and AI identities. It discovers identities and the accounts they use, governs those accounts through vaulting and rotation, and replaces persistent privilege with time-bound access. It controls access at runtime by brokering the connection and injecting the credential so it never lands in a user's or an agent's hands, then captures the session for review.
Delinea Iris AI applies intelligence to that access data. Teams can spot policy drift, right-size privilege against real usage instead of assumed need, and flag unusual privileged sessions at a scale manual review never reaches. Organizations that broker access this way have seen up to a 90% reduction in lateral movement in fully brokered environments.
The same design pays off at audit time. Continuous session capture and access records keep evidence current. ZSP becomes a provable, ongoing posture rather than a point-in-time snapshot you scramble to assemble.
Zero standing privilege FAQs: JIT, service accounts and AI agents
How is zero standing privilege different from just-in-time access?
JIT access is one mechanism inside ZSP. It grants time-bound access at the moment of need. ZSP is the end state where no identity holds persistent privilege by default, reached through JIT, brokered access and runtime control together.
How do you apply ZSP to service accounts without breaking production?
Map each account to its dependencies first, vault and rotate the credential under policy, then move to brokered or dynamic access so the secret is used without being handed out. Sequence the highest-risk accounts first.
What does ZSP give auditors that a static PAM model cannot?
Continuous evidence. Time-bound grants, runtime authorization records and full session capture show who had access and what they did with it. Least privilege and time-bound access are named controls in major frameworks, including NIST 800-53 AC-6, PCI DSS Requirement 7, ISO 27001 Annex A.8.2 and SOC 2 Common Criteria CC6.
How does ZSP apply to AI agents?
AI agents are the fastest-growing kind of non-human identity, and they act on their own at machine speed, so an agent that holds standing access is a large blast radius if it’s compromised. ZSP applies the same way it does to any identity, and it matters more here. The agent gets no standing privilege. Its credential is brokered and injected so it never holds one, and every action is authorized as it runs. A compromised agent then reaches very little.
How to finish your ZSP program
Most teams don’t stall for lack of commitment. They stall because the last stretch is an architecture change that a policy update can’t deliver. The programs that finish move the point of control off the login and onto the action.