Zero Standing Privilege is a security model in which no identity holds permanent privileged access. All privileged access is granted dynamically and automatically revoked when complete. In a ZSP model, an attacker who compromises an NHI finds an identity with no standing privileges — they must also compromise the credential issuance infrastructure to gain meaningful access. This is the target architecture for Agentic AI deployments.
Why This Matters for Security Teams
Zero Standing Privilege matters because NHIs are not static users. They are service accounts, API keys, workload tokens, certificates, and agent credentials that can be copied, reused, and over-permissioned long before anyone notices. NHI Mgmt Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which turns a single compromise into broad internal access. In practice, ZSP is the control model that removes that permanent access layer and forces every privilege grant to be deliberate, short-lived, and traceable.
That matters even more for autonomous agents. Agentic workloads do not follow fixed human workflows, so RBAC alone is too blunt when an agent can chain tools, pivot across systems, and act on changing instructions. Current guidance suggests pairing ZSP with OWASP Non-Human Identity Top 10 findings and the NHI lifecycle guidance in Ultimate Guide to NHIs — Key Challenges and Risks so access is granted only when an identity actually needs it. In practice, many security teams encounter ZSP failures only after a stale token or overprivileged service account has already been used for lateral movement, rather than through intentional design.
How It Works in Practice
ZSP for NHIs works by replacing standing entitlements with just-in-time access. The identity still exists, but it does not keep permanent privilege. Instead, a workload or agent authenticates with a workload identity, requests the minimum access needed for a specific task, receives a short-lived credential, and loses that privilege when the task ends. That model is consistent with zero trust thinking and with the NHI lifecycle problems documented in The 2025 State of NHIs and Secrets in Cybersecurity, where 91% of former employee tokens remain active after offboarding.
- Use workload identity as the base primitive, not a shared static secret.
- Issue JIT credentials with tight TTLs and task-specific scope.
- Evaluate authorisation at request time using policy-as-code, not only at provisioning time.
- Revoke or expire secrets automatically after the workflow completes.
- Log every grant, use, and revocation event for auditability and anomaly detection.
For agents, the authorisation step should be intent-based or context-aware: the policy should ask what the agent is trying to do, what data it can touch, and whether the request fits the current task boundary. That is a better fit than pre-defined role bundles when behaviour is dynamic. The implementation pattern is also reinforced by OWASP Non-Human Identity Top 10, especially where secret exposure, credential reuse, and unmanaged offboarding create standing access by accident. ZSP becomes effective when the platform can prove identity, constrain scope, and remove access immediately after execution. These controls tend to break down when a shared orchestration layer reuses one credential across many services because the platform can no longer distinguish task-specific privilege from ambient access.
Common Variations and Edge Cases
Tighter privilege controls often increase orchestration overhead, requiring organisations to balance faster automation against more frequent policy decisions and token issuance. That tradeoff is real in CI/CD systems, multi-agent pipelines, and legacy integrations where short-lived credentials are not supported natively. Best practice is evolving here: there is no universal standard for every agent runtime, but the direction is clear. ZSP should be adapted to the environment rather than treated as a single product feature.
One common edge case is third-party automation. If an external service must call internal APIs, it should still receive scoped, expiring access through a brokered trust flow instead of a standing API key. Another is human override. Emergency access may require a temporary exception, but that exception should be time-boxed, approved, and visible in the audit trail. For agentic systems, the most important design choice is to separate the agent’s persistent workload identity from the ephemeral permission it needs for a single objective. That is where Top 10 NHI Issues and the Cisco DevHub NHI breach illustrate the danger of secrets that live too long, travel too far, or can be reused outside the original intent. 52 NHI Breaches Analysis further shows why stale identity material becomes a repeatable attack path when governance does not keep pace with automation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic systems need runtime controls for autonomous, tool-using behaviour. |
| CSA MAESTRO | MAESTRO addresses governance patterns for autonomous multi-agent environments. | |
| NIST AI RMF | GOVERN | AI RMF GOVERN fits accountability and oversight for autonomous access decisions. |
Tie each agent to scoped workload identity and revoke privilege after task completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
