Zero standing privilege is the missing control in rogue developer risk

At a glance

What this is: This analysis argues that standing privileged access, not just broad permissions, enables rogue developer abuse in cloud environments.

Why it matters: IAM and NHI teams need to treat persistent elevated access as a governance failure because temporary access materially shrinks the blast radius of insider misuse.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Britive Team's analysis of the Ubiquiti breach and zero standing privilege

Context

Zero standing privilege is the practice of removing persistent elevated access and granting it only when a task requires it. In cloud environments, that matters because human users and service identities often retain access long after the work is done, which turns a single compromised or malicious account into an open path for data exposure.

The Ubiquiti breach is a clear example of why IAM teams must look beyond role design and focus on access duration, revocation, and monitoring. The core issue was not just what the user could access, but that access remained available long enough to be abused. That starting position is unfortunately common in cloud operations.

Key questions

Q: How should security teams reduce the risk of rogue developers with privileged access?

A: Security teams should remove standing privilege, shorten session lifetime, and require task-scoped elevation for high-risk actions. The goal is to make misuse harder to sustain, not merely to narrow the role. Monitoring must cover repository access, cloud consoles, and token usage so abuse is detected while the access window is still open.

Q: What is the difference between least privilege and zero standing privilege?

A: Least privilege limits what an identity can do. Zero standing privilege limits when that identity can do it. A user can still abuse least-privilege access if the access remains continuously available, while ZSP forces elevated access to exist only for the specific task and then expire automatically.

Q: When does just-in-time access reduce risk most effectively?

A: Just-in-time access reduces risk most effectively when privileged actions are infrequent, time-boxed, and easy to revoke. It is less effective if approvals are too broad, sessions last too long, or emergency access becomes the default. The best results come from pairing JIT with strong logging and rapid session termination.

Q: Why do non-human identities complicate privileged access governance?

A: Non-human identities complicate privileged access governance because they often carry durable credentials, run continuously, and are easy to overlook in reviews. Their access can be as powerful as a human admin account, but it may be harder to trace and revoke. That is why lifecycle control matters as much as role design.

Technical breakdown

Standing privilege in cloud identities

Standing privilege means an account or token can use elevated permissions continuously without a fresh approval step. In cloud and SaaS environments, that often shows up as long-lived admin roles, keys, or service identities that remain valid across sessions. The problem is not only excess permission, but persistence. Once a credential is stolen or abused, the attacker does not need to race a human approval cycle. They can act inside the existing trust boundary until the credential is revoked, rotated, or otherwise invalidated.

Practical implication: Inventory every elevated identity and remove any access that does not need to persist between tasks.

Why least privilege is not enough on its own

Least privilege reduces what an identity can do, but it does not determine when that identity can do it. A developer may still have enough access to clone repositories, query cloud resources, or exfiltrate data if the role is broad enough for daily work. ZSP narrows the attack window by adding time-bound access controls on top of permission scoping. That combination matters because insider abuse, stolen sessions, and compromised service accounts all depend on usable access remaining live long enough for the attacker to finish the job.

Practical implication: Pair role minimisation with just-in-time elevation so access exists only for the approved task window.

Cross-cloud privilege control and revocation

Multi-cloud environments make standing privilege harder to spot because elevated access is distributed across AWS, Azure, GCP, SaaS, and automation tools. Centralised visibility is only useful if it supports rapid revocation and consistent policy enforcement across those environments. Without that, teams may know which identities exist but still fail to stop misuse in time. For NHI governance, the control objective becomes lifecycle enforcement: issue, use, monitor, and revoke credentials on a defined schedule rather than treating them as durable entitlements.

Practical implication: Build one privilege revocation process that covers human users, service accounts, and automation identities across all cloud estates.

Threat narrative

Attacker objective: The attacker sought to extract data, pressure the company through extortion, and convert internal access into reputational and financial harm.

1. Entry through privileged AWS user access that should not have remained continuously available.
2. Escalation and movement across the cloud environment by using the same standing access to reach additional resources.
3. Impact through cloning GitHub repositories and attempting extortion after data exfiltration.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero standing privilege is a control problem, not a policy preference. The Ubiquiti case shows that persistent elevated access gives a malicious insider a usable attack window even when the role was originally legitimate. Security teams should treat access duration as part of the risk surface, not a secondary administrative detail. That makes revocation speed and session lifetime central governance controls.

Least privilege without time-bound access still leaves a large blast radius. Narrowing permissions helps, but a user who still has continuous access can abuse the approved task scope. In practice, this means the control stack must include JIT elevation, session monitoring, and fast revocation. Practitioners should measure whether standing access can be abused faster than the organisation can detect and respond.

Identity blast radius is the right way to think about rogue developer risk. The decisive question is not whether a developer has some access, but how much damage that access can do before it expires. This is especially true in cloud estates where human and non-human identities are both operationally powerful. Teams should design controls around damage containment, not just entitlement reduction.

Multi-cloud governance exposes a lifecycle gap in privileged access management. When elevated access spans AWS, SaaS, and automation pipelines, fragmented administration makes revocation inconsistent and slow. That pushes NHI governance toward unified policy, central inventory, and task-scoped access issuance. Practitioners should assume inconsistency is the default unless they prove otherwise.

Rogue developer scenarios are now a standard insider-threat pattern, not an edge case. The broader lesson is that insider motivation is unpredictable, but access architecture is controllable. Organisations that still rely on permanent administrative access are accepting avoidable exposure. The practical response is to remove durable privilege where possible and make every elevation temporary.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• That same research found that DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
• For a broader NHI control baseline, review Ultimate Guide to NHIs for lifecycle, visibility, and access governance patterns.

What this signals

Identity blast radius is the better operational lens for this problem than role design alone. If a privileged account can remain live long enough to clone repositories or traverse cloud resources, the organisation has a revocation problem, not just a permissions problem. Teams should test whether their access controls can shut down abuse faster than an insider can move data.

With 44% of developers reported to follow security best practices for secrets management, the governance gap is behavioural as much as technical, according to The State of Secrets in AppSec. That means policy only works when it is reinforced by short-lived access, inventory discipline, and review processes that catch exceptions before they become habits.

Practitioners should expect privilege review to shift from periodic certification toward continuous verification. That aligns naturally with zero trust thinking and with external guidance such as the CISA cyber threat advisories, which reinforce the need for rapid containment when credentials are abused. The programme implication is simple: if revocation is slow, standing access is too risky.

For practitioners

• Implement just-in-time elevation for all privileged cloud roles Require approval and short-lived session issuance for admin tasks in AWS, GitHub, and adjacent control planes. Keep the approval window narrow and revoke access automatically when the task ends.
• Eliminate standing access for developers and automation identities Review every persistent elevated role, API key, and service account. Replace durable privilege with task-scoped access and ensure unused credentials are disabled rather than left dormant.
• Centralise revocation across cloud and source-control systems Use one revocation workflow that reaches cloud consoles, repository permissions, and token stores so a single compromised identity cannot retain access in a second system after the first is closed.
• Monitor privileged session behaviour for data-cloning patterns Alert on repository cloning, bulk downloads, unusual geographies, and access from newly elevated sessions. Correlate these events with the identity that received temporary access to spot misuse quickly.
• Map privileged human and non-human identities together Build a shared inventory for admin users, service accounts, keys, and tokens so governance reviews cover the full access chain instead of only human accounts.

Key takeaways

• Rogue developer risk is fundamentally an access-duration problem, because continuous privilege lets a bad actor move faster than governance processes can respond.
• Cloud least privilege helps, but without zero standing privilege it still leaves a live window for misuse, exfiltration, and extortion.
• Practitioners should prioritise JIT access, rapid revocation, and unified identity inventory across human and non-human accounts.

Key terms

• Zero Standing Privilege: Zero Standing Privilege is an access model in which elevated permissions are not permanently assigned. Instead, access is issued only when a task requires it and then revoked quickly. This reduces the time an attacker or insider can abuse a privileged identity.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised or misused identity can cause before it is detected and shut down. In NHI and IAM governance, it is shaped by privilege scope, credential lifetime, monitoring quality, and how quickly access can be revoked.
• Just-in-Time Access: Just-in-Time access is a provisioning pattern that grants credentials or elevated permissions only for a short, defined window. It is a practical control for reducing exposure in cloud and NHI environments, especially where permanent admin rights would otherwise remain available.
• Standing Privilege: Standing privilege is access that remains continuously available rather than being created for a specific task. It is risky because compromise, abuse, or simple neglect can leave powerful permissions active far longer than necessary, making revocation and monitoring critical governance controls.

Deepen your knowledge

Zero standing privilege and task-scoped elevation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for privileged cloud users and service identities, it is worth exploring.

This post draws on content published by Britive Team: Ubiquiti Security Breach: How Zero Standing Privileges Stop Rogue Developers. Read the original.