AI-powered JIT access exposes the limits of standing privilege

At a glance

What this is: This article argues that just-in-time access only works for least privilege when it uses dynamic context rather than static approval rules.

Why it matters: That matters to IAM and NHI practitioners because ephemeral access for service accounts, tokens, and agents fails if approval logic cannot distinguish routine use from compromised behaviour.

👉 Read Andromeda Security's article on AI-powered JIT access for privileged identities

Context

Least privilege is easy to endorse and hard to operate, especially when cloud permissions, service accounts, and machine-driven workflows expand faster than review cycles. In NHI governance, the core problem is not whether access should be temporary, but whether the decision logic can respond to real risk instead of relying on static role checks.

The article frames just-in-time access as the answer to standing privilege, but the deeper issue is whether JIT becomes another brittle policy layer if it cannot see device, location, behaviour, or request history. That is why NHI governance has to treat access decisions as dynamic control points, not as one-time approval events.

Key questions

Q: How should security teams implement JIT access for NHIs and privileged users?

A: Security teams should implement JIT as a conditional decision process, not a ticketing step. Grant access only when request context, behaviour, and device signals support the request, and expire the privilege automatically after use. For recurring machine access, pair JIT with visibility into request patterns so standing access does not quietly return through exceptions.

Q: When does rule-based JIT create more risk than it removes?

A: Rule-based JIT creates more risk when static conditions become a proxy for trust. If role, title, or time of day is enough to approve access, a compromised identity can still pass. That is especially dangerous for NHIs because many requests are repetitive and high volume, which makes weak rules easy to exploit and hard to notice.

Q: What is the difference between manual JIT and dynamic JIT?

A: Manual JIT depends on human approval for each request, while dynamic JIT evaluates live context before granting access. Manual workflows are slow and easy to rubber-stamp, but dynamic JIT can use behaviour, location, and risk signals to decide whether access should be approved, escalated, or denied.

Q: Why do least-privilege controls matter more for NHIs than for users?

A: NHIs often act at machine speed, across many systems, and with credentials that outlive the task they support. If those identities keep standing access, compromise can spread quickly and quietly. Least privilege matters more because the blast radius of an exposed token, key, or service account is usually larger than a single human session.

Technical breakdown

Why manual JIT approvals fail in high-velocity environments

Manual just-in-time access depends on a human approval loop before privilege is granted. That model can work for rare administrative requests, but it breaks down when access demand is frequent, time-sensitive, or tied to DevOps and cloud operations. Delays create pressure to bypass the process, while rushed approvals remove the security value entirely. The failure mode is not just inefficiency. It is policy erosion, where the organisation keeps the control in place but loses confidence in its outcome. For NHIs, this is especially dangerous because machine access is often automated, repetitive, and high volume.

Practical implication: Replace human-only approval chains with risk-based decisioning for recurring machine and privileged access.

How static rule-based JIT leaves identity risk unexamined

Rule-based JIT improves speed by using pre-defined conditions such as role, time of day, or organisational title. The weakness is that these are static attributes, so they do not answer whether the requester has been compromised, whether the request matches normal behaviour, or whether recent policy violations should change the decision. In identity terms, the control is context-blind. It grants access based on who someone is supposed to be, not on whether the current request is consistent with observed risk. For NHI governance, that gap is similar to trusting a token or service account because it exists, not because it is behaving safely.

Practical implication: Add behavioural and environmental signals before approving privileged NHI access.

What dynamic JIT changes in the access decision path

Dynamic JIT uses context such as request history, device posture, location, usage patterns, and peer comparisons to decide whether access should be granted automatically or routed for review. The key architectural change is that the access policy becomes a decision engine rather than a fixed allow rule. That supports least privilege without forcing every request into the same workflow. In practice, dynamic JIT is closer to continuous authorisation than to classic approval management. For AI agents and other NHIs, that matters because the access burst may be legitimate, but the surrounding context can still reveal compromise or abnormal use.

Practical implication: Use contextual signals to keep temporary access temporary, conditional, and reviewable.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• 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

Dynamic JIT is becoming a governance pattern, not just an access pattern. The article shows why least privilege cannot be reduced to a single approval step. In NHI environments, access needs to be continuously evaluated against context, because service accounts and agents do not carry the same behavioural cues as humans. Practitioners should treat JIT as part of an identity decision pipeline, not as an isolated workflow.

Static role checks create ephemeral credential trust debt. When access is time-bound but approval logic is still based on fixed roles and schedules, the organisation gains only partial protection. The trust assumption moves from standing access to standing rules, which is a smaller but still real exposure. Teams should assume that any repeated access pattern without behavioural validation will be abused sooner or later.

Least privilege fails when operational friction becomes the security exception path. If approvals take too long, teams route around them or rubber-stamp them under pressure. That makes the control look mature while it becomes less reliable in practice. For NHIs, the lesson is that governance must be fast enough for production workloads and strict enough to stop anomalous privilege bursts.

AI-assisted context evaluation is now the practical threshold for modern JIT. The article points toward a control model where behaviour, location, history, and risk signals inform the access decision. That aligns with broader zero trust thinking, but it also raises the bar for data quality and policy tuning. Practitioners should modernise JIT only if they can also operationalise trustworthy context.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader view of lifecycle controls, review Ultimate Guide to NHIs alongside rotation and offboarding guidance.

What this signals

Ephemeral access does not eliminate identity debt if the approval model still trusts static attributes. As AI systems, service accounts, and automation paths multiply, security teams should expect more access decisions to shift from human review to contextual policy engines. With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the gap is no longer theoretical.

Dynamic JIT will increasingly sit between IAM and runtime control. That means programme owners need cleaner identity data, better behavioural baselines, and clearer exception handling. If those inputs are weak, dynamic approval logic simply automates bad judgment faster.

Least privilege for NHIs will be judged by revocation speed as much as by approval speed. Teams that cannot remove access cleanly after the task ends will keep accumulating trust debt, even if their requests look modern at the front end.

For practitioners

• Implement context-aware JIT for privileged access Use request history, device posture, location, and recent behaviour to decide whether privileged access is auto-approved or escalated for review.
• Retire standing access for recurring NHI workflows Map service accounts, API keys, and admin automation paths that still hold persistent privilege, then convert them to time-bound access with explicit expiry.
• Tune approval logic for anomaly detection Require manual review when access frequency changes, request origin shifts, or the request departs from a normal pattern for that identity or workload.
• Measure friction against policy bypass Track request delay, approval overrides, and emergency exceptions so you can see when process friction is causing users to circumvent least privilege.

Key takeaways

• JIT access only improves security when the approval logic can detect context, not just assign roles.
• Static approval rules can still leave NHIs exposed because they do not account for compromise, abnormal behaviour, or policy drift.
• Security teams should treat dynamic JIT as a lifecycle control, with expiry, review, and revocation built in from the start.

Key terms

• Just-in-time access: Just-in-time access is a pattern that grants privilege only when it is needed and removes it after the task is complete. In identity governance, the goal is to shrink the window of exposure so standing access does not become the default state for humans or NHIs.
• Standing privilege: Standing privilege is access that remains available without a fresh approval or time limit for each use. It creates persistent trust in an identity, which is dangerous when service accounts, API keys, or agents can be reused, stolen, or forgotten long after the original task ends.
• Dynamic approval: Dynamic approval is an access decision that uses live context such as behaviour, device state, location, and request history. It is more precise than static rule checks because it can adapt to risk in the moment rather than assuming that a role or schedule proves legitimacy.
• Ephemeral credential: An ephemeral credential is a secret or token designed to exist only briefly for a specific task. The security value depends on both short lifespan and reliable revocation, because a temporary credential that can still be reused, cached, or bypassed remains a real attack path.

Deepen your knowledge

JIT access and least privilege for NHIs are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing standing access with context-aware controls, it is worth exploring.

This post draws on content published by Andromeda Security: Holistic identity security for the agentic enterprise and AI-powered JIT access. Read the original.