Zero Standing Privilege (ZSP) is an operating model in which sensitive privilege isn’t persistently assigned. Privilege is granted only when policy permits it, for the scope and duration a task requires, and it’s removed when the task ends. For AI agents, that means the agent can exist all the time, but its sensitive permissions shouldn’t.
P0 Security sums this up as persistent identity, ephemeral access. The agent keeps a stable, accountable identity with a named owner. Privileges to change production data, modify infrastructure or move money appear for a task and then go away. ZSP doesn’t mean an agent has no access at all. Low-sensitivity baseline access can remain under policy.
Key takeaways
- ZSP is an operating model, not a single control or product feature.
- An agent’s identity can persist while its sensitive privileges are granted only for a task.
- Agent permissions should be narrow, temporary and automatically revoked.
- Rotating or shortening credentials doesn’t create ZSP if broad permissions stay assigned.
- JIT access activates and ends privilege, least privilege sets its scope, runtime authorization decides whether it’s justified and verification proves it ended. ZSP depends on all four.
- Approved standing reads follow their own policy, but they don’t count as ZSP for that permission.
Why AI agents make standing privilege riskier
Standing privilege was already hard to govern for people and workloads. Agents raise the stakes. An agent may act through a user’s permissions, its own identity, a service account or a tool with separate credentials, and it can move through several systems in seconds. It also runs on schedules and triggers, often with no one watching.
AI doesn’t change the need for Zero Standing Privilege. It compresses the timeline. The gap between “this account has more access than it needs” and “something used that access” gets much shorter when the account belongs to software that acts on its own.
This is the failure P0 calls standing privileges and static credentials: long-lived access that exceeds the current task and stays available between runs. Any process, prompt or person that reaches the credential inherits everything it allows.
The math makes the point. A scheduled agent that works for 4 minutes a day but holds production write permissions keeps them for the other 23 hours and 56 minutes. That idle time is exposure with no business purpose.
What Zero Standing Privilege means for an agent
Under ZSP, an agent’s sensitive permissions have three properties.
Narrow
Permissions match the resources and operations the task needs, such as one database schema, one ledger or one deployment target. They don’t cover everything the agent’s tools could reach. For how to define that scope, see how to design least-privilege access for AI agents.
Temporary
Sensitive privilege exists only while the task needs it. It’s activated when policy approves the request and has a defined end condition, such as task completion, a maximum duration or session closure. Just-in-time access for AI agents covers how that lifecycle works.
Automatically revoked
Access ends on its own when the end condition is met or when risk changes. It doesn’t wait for someone to remember a cleanup ticket. Removal also has to be verified: a revocation request that reports success while a session or cached grant still works hasn’t ended anything. Revocation controls and kill switches are covered in AI agent access revocation and kill switches.
One more distinction matters. The originator, the agent identity, an access lease and the target permissions can each have their own lifetime. An agent identity that lasts for months is compatible with ZSP. A write permission that lasts for months isn’t. When you describe how long something lasts, name which of these you mean.
What Zero Standing Privilege isn’t
ZSP is easy to claim and easy to misread. It isn’t:
- Zero access. Baseline, low-sensitivity access can remain when policy allows it.
- Credential rotation or vault checkout. Issuing a fresh or short-lived credential for a broadly privileged account still leaves broad privilege in place. The entitlement and its lifecycle are what count.
- An expiring agent identity. Deleting and recreating agents doesn’t help if each new one receives the same standing permissions.
- Per-action checks alone. Evaluating each request is valuable, but if broad entitlements stay assigned, another path can still use them.
- A product you switch on. ZSP is a model organizations move toward workflow by workflow. No tool makes it true everywhere at once.
ZSP vs JIT access vs least privilege vs runtime authorization
These terms are related, and they’re often used interchangeably. They govern different things.
| Concept | What it governs | What it can’t do alone |
| Zero Standing Privilege | Whether sensitive privilege exists between tasks | Decide what a specific task needs or whether it should proceed |
| Just-in-time access | When privilege is activated and when it ends | Keep the granted scope narrow |
| Least privilege | Which resources and operations a permission covers | Remove a narrow permission that never expires |
| Runtime authorization | Whether a specific request is permitted, given identity, task and context | Remove privilege that’s assigned outside the decision |
For one agent task, they work together. Runtime authorization decides whether the request is justified. Least privilege defines what the resulting access covers. JIT access activates it for the task and ends it afterward. ZSP is the result you can verify when that pattern holds: no sensitive privilege waiting between runs.
How ZSP works for a single agent task
At a conceptual level, a ZSP workflow for an agent follows six stages:
- The task arrives with trusted context. The request carries the originator, the participating agents and the task. Blended identity context keeps each identity distinguishable.
- Policy decides. Runtime policy evaluates whether sensitive privilege is justified for this task, target and operation right now. The outcome may be allow, require review, limit or deny.
- Scoped privilege is activated. Where supported, the target receives temporary permissions or an ephemeral identity so it can authorize the action through its own controls.
- Use is enforced. Requests outside the approved scope are rejected at the action boundary or by the target.
- Privilege is removed. When the end condition is met, access is revoked and the removal is checked on the real access paths.
- Evidence ties it together. Decision, activation, enforcement and removal records are correlated so reviewers can see what was granted, what happened and when it ended.
Example: a scheduled reconciliation agent, before and after ZSP
A finance team runs a reconciliation agent every night at 2:00. It reads the day’s transactions, compares them with bank settlement files and writes adjustment entries to a reconciliation ledger for review. The run takes about 4 minutes.
No person starts the job. The originator is the scheduled workflow, so the context should record that trigger and the job owner rather than inventing a human.
| Element | Standing model | ZSP model |
| Identity | Shared finance service account used by several jobs | A dedicated agent identity with a named owner, persistent between runs |
| Write permissions between runs | Write access to the ledger and adjacent finance tables 24 hours a day | None. Write access to the reconciliation ledger is activated for the run and removed when it ends |
| Read access | Broad read access across finance schemas | Approved read access to transaction and settlement data may remain under policy. It’s a standing read, so it isn’t ZSP for that permission |
| Credential | Long-lived database password in the job configuration | Short-lived access tied to the run, with no broad privilege behind it |
| Revocation | Manual, when someone notices | Automatic at job completion or a maximum duration, then verified |
| Evidence | Database logs show the service account only | Records connect the schedule, agent, policy decision, writes and access removal |
The difference shows up at 2:05. In the standing model, the service account can still write to finance tables, and so can anything that obtains its password. In the ZSP model, the write path is closed until the next approved run.
Don’t take that on faith. After a run, attempt a write with the agent’s identity and confirm it fails. Check that no other role or credential preserves the same permission.
How to move agents toward ZSP
Most organizations start with agents that already hold standing access. A practical path:
- Inventory standing agent privileges. List each agent’s identities, roles and credentials, including service accounts it shares and tokens it can reach.
- Pick one workflow and separate reads from sensitive writes. Decide which reads can remain under policy and which privileges should exist only during a task.
- Activate sensitive privilege per task. Move those privileges to task-scoped activation with clear end conditions.
- Test removal and measure what remains. Verify that access ends on the real paths, record any standing sensitive privilege that’s left and expand to the next workflow.
For scope design, see how to design least-privilege access for AI agents. For ownership, policy and review across many agents, see how to govern AI agent access to enterprise systems.
How P0 helps organizations move toward ZSP for agents
P0 Security’s model starts from the ZSP premise: an agent keeps its identity, and sensitive access exists only for the task. The P0 Runtime Access platform provides runtime access control across agents, users and machines. P0 Runtime Access for AI evaluates sensitive agent requests using the originator, agent and task context. Where supported, it activates task-scoped access in the target system and removes that access when the task ends, so sensitive privilege doesn’t have to sit on the agent between runs.
For machine identities such as the reconciliation job above, P0’s published machine governance covers ownership, intended usage, credential rotation and JIT entitlements. Rotation supports that model, but the entitlement lifecycle is what moves an agent toward ZSP.
P0 works alongside existing identity and access management (IAM) and privileged access management (PAM) systems. Supported targets, integrations and deployment options vary, so confirm coverage for the agent workflows you plan to move first.
P0 does not evaluate whether a prompt is malicious, whether model output is safe or how sensitive data should be classified. P0 determines whether the identities involved are authorized to take the requested action and enforces that decision before the action reaches the sensitive resource.
Frequently asked questions
Does Zero Standing Privilege mean an agent has no access at all?
No. ZSP focuses on sensitive privilege. An agent can keep low-sensitivity baseline access that policy approves. Privileges that could change data, infrastructure or money should be activated for a task and removed afterward.
Is ZSP the same as just-in-time access?
No. Just-in-time access is a mechanism: it activates privilege when needed and ends it afterward. ZSP is the operating model JIT helps achieve. JIT access that grants broad scope, or that never actually ends, doesn’t produce ZSP.
Does credential rotation give an agent Zero Standing Privilege?
No. Rotation limits how long a particular secret is useful, but the account behind it keeps its permissions. If that account holds broad privilege between tasks, the agent still has standing privilege, whatever its credential’s lifetime.
Can an agent with a persistent identity follow ZSP?
Yes. A persistent, owned identity helps with accountability and attribution. ZSP applies to the agent’s sensitive permissions, not to its existence. Persistent identity with ephemeral access is the intended pattern.
Can an agent keep standing read access under Zero Standing Privilege?
Yes, if policy approves it. Zero Standing Privilege (ZSP) applies to sensitive privileges, such as permissions to change data or infrastructure, which should be granted only for the task and revoked when it ends. An agent can keep ongoing read access to data that isn’t sensitive enough to need a per-task grant. That read access is a standing permission, so it isn’t an example of ZSP, but it doesn’t break the model either. Document it and review it regularly to confirm it’s still needed.
Summary
Zero Standing Privilege asks a simple question about each agent: what sensitive privilege does it hold right now, when it isn’t doing anything? Under ZSP, the answer is none. The agent keeps its identity and approved baseline access, while sensitive permissions are narrow, granted for a task and removed automatically when it ends.
Getting there takes four pieces working together. Runtime authorization decides, least privilege sets the scope and JIT access activates and ends privilege. Verification proves it ended. Start with one scheduled or high-impact workflow, close its standing write paths and use what you learn to move the next agent.