Just-in-time access for Azure exposes the standing privilege gap

At a glance

What this is: This is an analysis of why Azure just-in-time access is really a permissions-layer problem, with standing privilege across human and non-human identities creating the main attack surface.

Why it matters: It matters because IAM, PAM, and NHI teams need one access model that governs humans, service identities, automation, and AI agents without leaving persistent privilege behind.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.

👉 Read Sonrai Security's blog post on just-in-time access for Azure

Context

Azure just-in-time access is a permissions governance pattern, not a sign-in feature. It assumes the real risk is standing privilege, where access remains active after the task that justified it has ended. That assumption fails across human admins, service principals, managed identities, automation, vendors, and AI agents when access is granted once and then left in place.

The article frames the problem correctly: cloud environments often preserve access because removing it feels disruptive. That is a classic identity governance failure, not a niche Azure issue. For IAM and PAM teams, the key question is how to make access temporary, scoped, and reviewable without relying on manual cleanup.

In practice, this is an NHI and cloud privilege issue as much as a human admin issue. The same governance gap appears whenever permissions are assigned for convenience, then forgotten, across workloads and delegated access chains.

Key questions

Q: How should security teams implement just-in-time access for Azure identities?

A: Start by scoping roles down before they are made eligible, then apply time-limited activation, justification, and approval to the exact permissions that carry meaningful blast radius. Include human administrators and non-human identities in the same governance model so JIT does not become a partial control that leaves service principals and automation exposed.

Q: Why do standing privileges increase cloud blast radius so quickly?

A: Standing privilege means an identity can act immediately with whatever permissions it already holds, so compromise, misuse, or simple operational drift can be turned into broader impact without any new access grant. In Azure, the permission itself is often the risk, especially when it can read secrets, change roles, or modify infrastructure.

Q: What do teams get wrong about Azure just-in-time access?

A: The most common mistake is treating JIT as a human-admin feature and assuming role activation alone solves privilege risk. That leaves service principals, managed identities, automation accounts, and AI agents with persistent permissions that still create a large attack surface. JIT only works when it is applied across the full identity estate.

Q: Who is accountable when a non-human identity keeps unnecessary Azure access?

A: Accountability sits with the IAM, PAM, and cloud platform owners who define and review entitlement policy, because persistent access is usually a governance choice, not a technical accident. The control expectation is simple: every identity that can affect infrastructure or data should have a clear owner, scope, and expiry condition.

Technical breakdown

Standing privilege in Azure identity and access management

Standing privilege means an identity has active permissions whenever it exists, not only when a task needs them. In Azure, that can apply to humans, service principals, managed identities, automation accounts, and external identities. The risk is not just authentication compromise. It is that a valid identity can already do too much once authenticated, so the blast radius is determined by overbroad permissions rather than login strength. Just-in-time access reduces that exposure by making access temporary and task-scoped instead of permanently available.

Practical implication: treat persistent Azure permissions as the primary control problem, not secondary hygiene.

Azure Entra PIM versus permissions-first cloud PAM

Microsoft Entra Privileged Identity Management governs activation of eligible roles, while Defender for Cloud JIT VM access governs temporary network-level reachability to virtual machines. Neither one fully solves the permissions-layer problem when unused rights sit outside eligible role workflows or when non-human identities never enter those workflows at all. A permissions-first cloud PAM model shifts enforcement to the role and entitlement layer, where least privilege is actually decided. That is why session controls alone do not close Azure blast radius.

Practical implication: separate network access control from entitlement control and assess both before declaring JIT complete.

Why non-human identities change the JIT model

Service principals, managed identities, CI/CD accounts, vendor identities, and AI agents often carry permissions that were granted for deployment convenience and never revisited. Unlike a human administrator, these identities may not pass through standard privilege review or activation workflows, yet they can still read secrets, modify access, or alter infrastructure. JIT for Azure therefore has to cover non-human identities explicitly, or it only protects the smallest slice of the actual privilege surface. That is a governance gap, not a tooling detail.

Practical implication: include every non-human identity in entitlement review and JIT design, not just named administrators.

Threat narrative

Attacker objective: The attacker wants to turn already granted Azure permissions into infrastructure control, secret access, and broader lateral reach.

1. Entry occurs through an identity that already has valid Azure access, such as a human account, service principal, or managed identity with standing permissions.
2. Escalation happens when overprivileged access allows the identity to read secrets, modify role assignments, or reach resources beyond the task’s original scope.
3. Impact follows when the compromised or misused identity can alter infrastructure, exfiltrate data, or widen access across the subscription without needing new credentials.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Standing privilege is the core Azure identity failure, not a side effect. Azure access becomes dangerous when permissions outlive the work they were meant to support. The article correctly points out that this affects humans and non-human identities alike, which is why the governance problem sits in entitlement management rather than authentication alone. Practitioners should treat every unused permission as active risk.

Permissions-first cloud PAM is the right model for cloud privilege governance. Traditional PAM was built to broker privileged sessions, but Azure often exposes risk through permission itself, not the login path. That is why controls focused on jump boxes or session recording miss the real blast radius. The implication is that IAM and PAM teams must move enforcement to the role and entitlement layer.

Non-human identities break human-centric privilege review assumptions. Service principals, managed identities, automation, and AI agents often sit outside the review cadence that was built for named employees. That means JIT programs that only cover human admins leave the majority of cloud privilege untouched. Practitioners should reframe access review as an identity-wide control, not a human workflow.

Task-scoped access is the named concept that matters here. Azure JIT works only when the access window, scope, and approval path match the actual work, not an arbitrary convenience setting. The article shows that long activation windows simply recreate standing privilege in a different form. For identity governance teams, the practical conclusion is that scope precision matters more than access volume.

Cloud privilege governance now spans humans, workloads, vendors, and AI agents. That broadening is not a future trend, it is the current operating state of Azure environments. As more identities act with meaningful permissions, governance that cannot distinguish between temporary need and permanent entitlement will fail to reduce blast radius. Practitioners should align review, approval, and expiry rules across the full identity set.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader lens on AI identity risk and governance maturity, see Ultimate Guide to NHIs, which ties access lifecycle controls to operational blast radius.

What this signals

Standing privilege is becoming a programme-level risk signal, not just an access review finding. With 70% of organisations already granting AI systems more access than human employees, per The 2026 Infrastructure Identity Survey, the governance model has to account for identities that act outside traditional human review cycles. Azure JIT is therefore part of a broader move toward time-bound entitlement control across the full identity estate.

Task-scoped access is the right framing for cloud privilege programmes. The value of JIT is not the activation workflow itself, but the discipline of matching permission scope to a concrete job. That is the same logic underpinning least privilege, workload identity governance, and modern PAM, and it should shape how teams evaluate Azure entitlements over time.

Non-human identity governance now sits in the same decision path as human IAM. As AI agents, service identities, and automation consume more permissions, cloud security teams need one operating model for reviews, expiry, and escalation. If your programme still treats those identities as exceptions, your blast radius control remains incomplete.

For practitioners

• Right-size roles before enabling JIT Review Azure roles for broad actions, wildcard permissions, and unnecessary subscription scope before making them eligible for temporary activation. A role that is too broad when eligible is still too broad when time-limited.
• Extend JIT governance to non-human identities Bring service principals, managed identities, CI/CD accounts, vendor identities, and AI agents into the same entitlement review process as human administrators. If an identity can read secrets or modify access, it needs explicit scoping and expiry.
• Separate network controls from permission controls Use VM access controls for connectivity and privilege controls for what an identity can do after authentication. Treat Defender-style port gating and PIM-style activation as complementary layers, not substitutes.
• Review eligible assignments that never activate Track which eligible roles are repeatedly unused and remove them or redesign them into narrower custom roles. Never let eligibility become a quiet form of standing access.

Key takeaways

• Azure JIT is a permissions governance problem first and a session control problem second.
• Standing privilege across humans and non-human identities is what expands blast radius in cloud environments.
• JIT only reduces risk when roles are right-sized, time-limited, and applied to the full identity estate.

Key terms

• Standing Privilege: Standing privilege is access that remains active even when no current task justifies it. In cloud environments, that means an identity can continue to read, modify, or escalate long after the original need has passed, which expands blast radius and weakens governance.
• Just-in-Time Access: Just-in-time access is a temporary privilege model in which permissions are activated only for a specific task and expire automatically afterward. In Azure, it is most effective when paired with tight scoping, justification, and role right-sizing before activation.
• Cloud Privileged Access Management: Cloud privileged access management governs high-risk permissions at the entitlement layer rather than only at the session layer. It focuses on what an identity can do in the cloud, not just how it connects, which makes it essential for Azure, workload identities, and non-human accounts.
• Non-Human Identity: A non-human identity is any machine, workload, token, service account, or AI agent that authenticates and acts in a digital system. These identities need the same lifecycle and privilege discipline as human users, but they often bypass traditional review processes unless governance is deliberately extended to them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Just-In-Time Access for Azure Without New Infrastructure. Read the original.