AI-powered JIT access exposes the limits of standing privilege

At a glance

What this is: This is an analysis of why manual and rule-based just-in-time access still fail to eliminate standing privilege risk, and why dynamic, context-aware approval logic is presented as the next step.

Why it matters: IAM teams responsible for NHI, autonomous, and human access should treat JIT as a governance model, not just a workflow, because static approvals can preserve excess privilege even when access is time-bound.

Context

Just-in-time access is a privileged access pattern that grants access only for a limited period instead of leaving permissions permanently available. The article argues that the main failure is not JIT as a concept, but JIT implementations that rely on manual approvals or static rules and therefore keep standing-privilege assumptions in place.

That matters for identity governance because access decisions based only on role, title, or schedule cannot see whether the requester's context has changed. In practice, the control problem is whether the approval model can account for risk, behaviour, and compromise indicators before access is issued.

Key questions

Q: What breaks when JIT approvals rely only on role and schedule?

A: Static JIT breaks when it treats identity as stable and predictable. Role, title, and time-of-day checks can approve access that looks normal on paper but is unsafe in context, so the programme preserves standing privilege risk instead of removing it.

Q: Why does context-aware JIT reduce security risk more effectively?

A: Context-aware JIT can evaluate whether a request matches the requester’s normal behaviour, device, location, and recent access history before granting privilege. That matters because risky requests are often visible only in the surrounding context, not in the role assignment itself.

Q: What are the signs that a JIT programme is not really enforcing least privilege?

A: Common warning signs include rubber-stamped approvals, long approval delays, frequent bypasses, and repeated access requests that look identical regardless of context. Those patterns show the process is moving access around, not actually constraining it.

Q: How should teams balance friction and security in B2C authentication?

A: Use the least friction that still matches the risk of the session or action. Keep ordinary sign-ins simple, then apply adaptive MFA or step-up verification only when device, location, behaviour, or transaction value raises the assurance requirement. This approach protects conversion while still allowing stronger checks where they matter most.

Technical breakdown

Why manual JIT approvals still create standing privilege risk

Manual JIT replaces always-on access with a request and approval step, but the security model still depends on humans making fast judgment calls. When approvals take hours or days, teams either bypass the process or rubber-stamp requests without context, which means the system preserves the same broad access outcomes it was meant to remove. The key weakness is not timing alone, but the absence of structured risk input at decision time. Practical implication: approval design must be evaluated as an access-control mechanism, not a workflow convenience.

Practical implication: measure whether approval latency is driving bypass behaviour or context-free approvals.

How static rule-based JIT misses dynamic access risk

Rule-based JIT improves speed by auto-approving requests that match predefined attributes such as role, title, or time of day. That works only if access need is stable and user context is predictable. Once identity state, device, location, or behaviour changes, static rules become blind to compromise and unusual request patterns. In other words, the control is deciding on yesterday's assumptions. Practical implication: static policy alone is insufficient when the approval decision must reflect live risk.

Practical implication: evaluate whether your JIT policy can distinguish routine access from suspicious repetition or context shifts.

What dynamic, AI-assisted JIT changes in privilege governance

Dynamic JIT introduces contextual signals such as request history, device, location, and behavioural baselines into the approval decision. The architectural shift is from pre-authorised standing policy to runtime risk evaluation, which makes the access grant conditional on whether the request fits expected behaviour. That does not remove governance, but it moves governance earlier in the request path, before privilege is issued. Practical implication: the decision engine has to be able to surface evidence, not just return allow or deny.

Practical implication: build JIT around runtime evidence feeds, not just a fixed approval matrix.

Threat narrative

Attacker objective: The objective is to obtain privileged access that can be used without meaningful runtime scrutiny, preserving broad reach into sensitive systems.

1. Entry occurs through a privileged access request that is processed by a manual or static JIT workflow rather than by runtime context evaluation.
2. Escalation follows when the requester receives access because role, title, or time window matched policy even though the requester's current state may have changed.
3. Impact is the continued exposure of privileged actions through standing privilege patterns that JIT was supposed to eliminate, including potential compromise of high-risk access paths.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

Static JIT is a governance approximation, not a control boundary: When approval decisions rely on role, title, or request time, they inherit the assumptions of standing privilege. That model can reduce friction, but it cannot tell whether the access request is safe in the current context. The practitioner lesson is that a time-limited grant is not the same thing as a dynamically justified grant.

Dynamic context is the real least-privilege control point: Least privilege cannot be enforced well if the system only knows who is asking and when they asked. Request history, device, location, and behavioural pattern are what separate ordinary use from risky access. That means the governance question shifts from whether JIT exists to whether the approval logic can interpret live context.

AI changes JIT from policy enforcement to risk interpretation: The article's strongest claim is that AI can build behavioural baselines and flag anomalies that static rules miss. That matters because static access policy does not degrade gracefully under compromise, while contextual evaluation can trigger review before privilege is issued. The practitioner conclusion is that JIT programmes must be judged on decision quality, not only on process speed.

Least privilege without context creates privilege debt: A short-lived grant still leaves a governance debt if the system cannot explain why the access was safe at the moment of issuance. This is the named concept in the article's substance: privilege debt accumulates whenever access is time-bound but not context-bound. Teams should treat that debt as an identity governance risk, not an implementation nuisance.

Dynamic JIT narrows the gap between productivity and control: The article frames friction as the trade-off that causes teams to abandon security controls. The better governance answer is not more manual review everywhere, but better decision inputs for the cases that deviate from normal behaviour. Practitioners should read this as a sign that approval quality matters more than approval volume.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Privilege debt: Time-limited access that is approved without behavioural context still leaves organisations carrying standing privilege in practice. The governance debt shows up when teams can move fast, but cannot explain why a grant was safe at the moment it was issued.

Dynamic JIT should be evaluated as a decision-quality problem, not an approval-speed problem. If the control cannot use request history, device, location, and behavioural pattern to distinguish normal from risky access, it will keep reproducing excess privilege under a different name.

For practitioners

• Replace role-only auto-approval logic Remove static allow rules that approve access solely because a requester belongs to a team or requests during business hours. Require context from device, location, request history, and recent policy violations before privilege is issued.
• Define the risk signals that trigger review Specify which behavioural changes, repeated requests, or context shifts force a manual review before high-risk access is granted. Use those signals consistently across cloud and SaaS workflows so reviewers see the same risk logic everywhere.
• Measure approval bypass pressure Track how often requests are rubber-stamped, delayed, or bypassed because the JIT process slows delivery. High bypass pressure is a sign that the control is functioning as a policy formality rather than a privilege boundary.
• Attach evidence to every elevated grant Record the request context that justified the approval, including behavioural baseline, device, and location. That audit trail makes it possible to challenge approvals that look routine but were actually out of pattern.
• Separate productivity goals from approval criteria Do not let speed targets determine who gets elevated access. Set the approval standard around current risk and intended scope, then tune workflow efficiency around that standard instead of weakening it.

Key takeaways

• Manual and rule-based JIT reduce exposure only when they can see the current identity context, not just a role or time window.
• The core risk is that static approval logic can preserve standing privilege in practice even when access is technically time-limited.
• Dynamic JIT shifts the control point to runtime evidence, which is where least privilege becomes operational instead of aspirational.

Key terms

• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Dynamic Access Control: Dynamic Access Control is an access decision model that changes permissions in real time based on current context. It evaluates signals such as user risk, device posture, location, time, resource sensitivity, and behavior, then grants, limits, or revokes access continuously. It is commonly implemented with policy engines and identity telemetry.
• Privilege Debt: Accumulated access that remains in place because approval, review, or removal processes lag behind operational change. In ticket-driven environments, privilege debt grows when requests are fast to grant but slow to revoke, creating persistent exposure beyond the original business need.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.