What is Zero Standing Privilege?
Zero Standing Privilege (ZSP) is a security model where no user, service account, or AI agent has permanent elevated access to cloud resources. Instead, privileges are granted just-in-time — for a specific task, for a limited duration, and with automatic revocation.
In a ZSP environment:
- No developer has permanent admin access to AWS, Azure, or GCP
- No service account holds standing database credentials
- No CI/CD pipeline stores long-lived cloud secrets
- No AI coding agent inherits a developer’s production permissions
Access exists only when needed, only as long as needed, and is automatically removed when the window expires.
Why Standing Privileges Cause Breaches
Standing privileges — permanent access that exists whether or not it’s being used — are the #1 attack vector in cloud security:
The Statistics
- 80%+ of cloud breaches involve compromised or over-privileged credentials
- The average organization has 3-5x more standing privileges than active users need
- Service accounts and API keys are rotated on average every 18+ months (many never)
- 60% of cloud identities have permissions they haven’t used in 90+ days
The Attack Chain
- Attacker compromises a credential (phishing, leaked key, supply chain)
- The credential has standing privileges (admin role, production DB access)
- Attacker uses those privileges immediately — no additional steps needed
- Blast radius is the full scope of the standing privilege — often org-wide
With zero standing privilege, step 2 fails — there are no privileges to exploit.
Zero Standing Privilege vs Traditional PAM
| Dimension | Traditional PAM | Zero Standing Privilege |
|---|---|---|
| Access model | Vault credentials, check them out | No credentials exist until requested |
| Standing access | Reduced but still present in the vault | Eliminated entirely |
| Credential lifecycle | Stored, rotated on schedule | Created on-demand, destroyed after use |
| Blast radius | Limited by vault access controls | Near-zero — no stored credentials to steal |
| Human identities | Governed via checkout/checkin | Governed via JIT approval workflows |
| Non-human identities | Stored in vault or secret manager | Ephemeral credentials per execution |
| AI agents | Not addressed | Governed with agent-specific JIT |
Traditional PAM vaults still have credentials inside them — a compromised vault means compromised access. ZSP eliminates the credentials entirely.
The Seven Flavors of JIT (How ZSP is Implemented)
Zero standing privilege is the principle. Just-In-Time (JIT) access is the mechanism. Cloudanix implements ZSP across seven access types:
1. Cloud JIT
What: Time-bound access to AWS, Azure, or GCP consoles via SSO. How: Engineer requests a role → multi-approver workflow → Cloudanix enables the assignment in IAM Identity Center / Entra ID / Google Cloud Identity → engineer SSOs in → auto-revoked when timer expires. Standing privilege eliminated: Permanent console admin access.
2. VM JIT
What: Keyless SSH into any virtual machine — short-lived certificates, auto-revoked. How: Engineer requests VM access → approval → Cloudanix issues a short-lived SSH certificate → session recorded → certificate expires automatically. Standing privilege eliminated: Static SSH keys, permanent bastion access.
3. Kubernetes JIT
What: Ephemeral kubeconfig for any cluster, including private clusters. How: Engineer requests cluster access → approval → temporary RBAC binding created → kubeconfig issued → auto-revoked. Standing privilege eliminated: Permanent cluster-admin, standing RBAC roles.
4. Database JIT
What: Short-lived, identity-stamped database access — no shared passwords, no jumpbox. How: Engineer requests database access → approval → Cloudanix creates temporary credentials → connection via IDE → credentials expire and all queries are logged. Standing privilege eliminated: Shared database passwords, permanent connection strings.
5. SaaS JIT
What: Time-boxed access to SaaS applications through your IDP. How: Engineer requests SaaS app access → approval → access granted through identity provider → auto-revoked after window. Standing privilege eliminated: Permanent SaaS licenses for occasionally-used tools.
6. Agentic JIT
What: JIT credentials for CI/CD pipelines, Kubernetes pods, Lambda functions, and ECS tasks. How: Pipeline requests access via SDK → policy-pre-approved or approval workflow → time-bounded credentials issued → revoked after job completion. Standing privilege eliminated: Long-lived CI/CD secrets, static service account keys.
7. Coding Agent JIT
What: Scoped, ephemeral credentials for AI coding agents (Claude Code, Cursor, Kiro) via MCP. How: Agent requests cloud/DB access via MCP → human-in-the-loop approval → short-lived credential issued → auto-revoked when task completes. Standing privilege eliminated: AI agents inheriting developer’s full production credentials.
Implementing Zero Standing Privilege
Phase 1: Inventory Standing Privileges
- Map all permanent access across humans, service accounts, and AI agents
- Identify which privileges are actively used vs dormant
- Prioritize: production first, then staging, then development
Phase 2: Implement JIT for Humans
- Start with Cloud JIT for console access — highest-impact, lowest-friction
- Add Database JIT for sensitive data access
- Implement VM JIT and Kubernetes JIT for infrastructure access
Phase 3: Eliminate Non-Human Standing Credentials
- Replace long-lived CI/CD secrets with Agentic JIT
- Deploy Coding Agent JIT for AI assistants
- Migrate service accounts to ephemeral credential patterns
Phase 4: Enforce and Audit
- Set policies that prevent new standing privileges from being created
- Monitor for privilege drift (new standing access appearing)
- Generate audit evidence of zero standing privilege posture
Zero Standing Privilege + Guardrails = Complete Agent Security
For AI coding agents, ZSP alone isn’t enough. You also need guardrails:
- JIT ensures the agent only HAS the credentials it needs (scope)
- Guardrails ensure the agent only DOES what’s allowed (behavior)
Example: A coding agent with JIT-scoped RDS read access still needs a guardrail to prevent it from exfiltrating the query results to an external service.
Zero Standing Privilege Compliance Mapping
| Framework | Relevant Requirement | How ZSP Helps |
|---|---|---|
| SOC 2 | CC6.1 — Logical access | Proves access is time-bound, approved, and logged |
| ISO 27001 | A.9.2 — User access management | Demonstrates least privilege and access reviews |
| PCI DSS | Req 7 — Restrict access | No standing access to cardholder data environments |
| HIPAA | § 164.312 — Access controls | Time-limited access to PHI with audit trails |
| NIST 800-53 | AC-2, AC-6 — Least privilege | Zero standing privilege is the strongest implementation |
