Beyond approvals: policy-based IAM and JIT for compliance

At a glance

What this is: This panel recap argues that IAM programs can move beyond manual approval queues by combining just-in-time access for privileged use cases with policy-based access control for deterministic, per-request authorization.

Why it matters: It matters because identity teams now need access decisions that scale across humans, workloads, and agentic systems without creating stale privileges, audit gaps, or policy sprawl.

Context

Identity and access management breaks down when approval queues become the control plane. The article describes a familiar problem set for IAM teams: approval fatigue, privilege creep, fragmented governance, and constant MFA friction that pushes users toward workarounds. In that model, identity-first security is not the end state. It is the point where access control becomes a governance and engineering problem, not just a workflow problem.

The article frames just-in-time access and policy-based access control as two different answers to the same operational pressure. JIT narrows privilege windows for humans and service scenarios, while PBAC moves authorization into deterministic, request-by-request policy evaluation. That distinction matters for IAM, IGA, PAM, and application teams because the right control depends on whether the problem is standing privilege, inconsistent authorization logic, or both.

Key questions

Q: What breaks when IAM still depends on approval queues for every access request?

A: Approval queues turn IAM into a throughput problem, so teams start rubber-stamping access, privilege creep accelerates, and audit evidence becomes weak. The failure is not speed alone. It is that the control no longer reflects actual business need, especially when requests span many systems and managers lack the context to judge them properly.

Q: Why do standing privileges create more risk than temporary elevated access?

A: Standing privileges leave high-risk permissions available even when no task is underway, which expands the window for misuse, compromise, and accidental damage. Temporary elevation narrows that window and makes privilege easier to review, but only if approval, logging, and revocation are consistently enforced across systems.

Q: How do you know whether policy-based access control is working?

A: Policy-based access control is working when access outcomes are consistent across platforms, policy changes are traceable, and exceptions are rare enough to review manually. If the same user receives different decisions in different tools without a business rationale, the policy model is not actually governing access.

Q: What is the difference between just-in-time access and role-based access control?

A: Role-based access control assigns permissions in advance based on a role, while just-in-time access grants elevated permissions only for a specific task and a limited time. RBAC is useful for baseline access. JIT is better for high-risk privilege because it reduces the duration and scope of exposure.

Technical breakdown

Why standing privilege keeps defeating approval-based IAM

Standing privilege is access that remains available long after the original need has passed. In practical IAM terms, that means the security model is asking people to request access once and then trusting that the entitlement will remain appropriate for weeks or months. JIT weakens that assumption by time-bounding access, but it still grants privilege for a duration. The technical issue is not just speed of approval. It is the persistence of access state, which becomes a permanent attack target and a recurring audit burden. In dynamic environments, that state is exactly what drifts away from actual business need.

Practical implication: Treat every long-lived privilege path as a control failure, not an administrative convenience.

How policy-based access control externalizes authorization decisions

PBAC moves authorization out of application code and into a policy decision point that evaluates identity, resource, action, and context on each request. That makes access decisions deterministic because the same inputs produce the same allow-or-deny result, and it makes the decision explainable because the policy can be versioned, tested, and audited like code. The architecture also depends on context feeds from directory, device posture, HR, and the application itself. Without those inputs, the policy engine cannot express the business rule fully. This is what makes PBAC an engineering discipline, not just a governance idea.

Practical implication: Externalize high-value authorization rules where you need consistent decisions across services and audit-ready change control.

Why AI must assist authorization, not decide it

The article draws a hard line between using AI around access and letting AI make the access decision itself. That distinction matters because authorization requires deterministic policy evaluation, while AI is better suited to analysis, anomaly detection, and policy suggestion. If an LLM makes the actual decision, the control stops being reproducible and becomes hard to defend in audit or incident review. That is why the useful pattern is AI-assisted governance with human approval over policy changes, not AI-native decision authority. The security boundary stays in the policy engine, not in the model.

Practical implication: Keep AI in the advisory layer and preserve deterministic policy enforcement as the control of record.

Threat narrative

Attacker objective: The objective is to preserve or abuse persistent access long enough to reach critical resources without triggering timely review or revocation.

1. Entry begins when a user, administrator, or service account receives standing access that remains valid beyond the immediate task need.
2. Escalation occurs when that persistent access is reused for sensitive actions, giving an attacker or overprivileged actor a stable path into critical systems.
3. Impact follows when stale privilege, weak auditability, or broad entitlements allow unauthorized actions to blend into ordinary operations.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

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

NHI Mgmt Group analysis

Approval fatigue is now a governance failure, not a workflow inconvenience. When security teams normalize rubber-stamped requests, they turn IAM into a queue-management exercise instead of a control system. The article captures the practical result: privilege creep, unaudited SaaS access, and users seeking shortcuts around friction. The discipline shift is from asking who can approve faster to asking which access should exist at all.

Just-in-time access reduces exposure, but it does not remove the underlying standing-privilege model. JIT still grants access for a window, which means the governance assumption is that a time box is an adequate control boundary. That holds better than months-long persistence, but it still depends on correct policy design and reliable revocation. For practitioners, the real question is where temporal privilege is acceptable and where request-by-request authorization is required.

Policy-based access control is the more durable answer where authorization logic must stay explainable. PBAC turns business rules into testable policy artifacts, which is why it scales better across services, queues, gateways, and legacy wrappers. The governance value is not just finer-grained access. It is the ability to prove why a decision happened and to separate policy definition from application code. That is the direction IAM is moving when auditability matters as much as enforcement.

Deterministic authorization is the named concept here: access decisions must be reproducible, versioned, and auditable even as environments become more dynamic. Once AI is added around the control plane, the demand for deterministic enforcement becomes higher, not lower, because model output is not an acceptable basis for a security decision. Practitioners should treat this as the dividing line between useful assistance and unacceptable delegation.

Agent identities force IAM to confront delegation quality, not just privilege scope. The article is right to separate agent access from user impersonation and super-user service accounts, because both destroy clean accountability. That makes the broader market signal clear: identity governance must now cover humans, workloads, and agents with the same rigor, but not the same control mechanics. The practitioner implication is that authorization architecture has to match the actor type, or auditability collapses.

What this signals

Identity teams should stop treating access approval as the primary control and start treating authorization design as the control surface. Once decisions move into policy and context, the programme can scale across applications without multiplying manual reviews. That shift also makes it easier to align IAM, PAM, and application security around the same decision logic.

PBAC becomes most valuable where teams need consistent authorization across humans, workloads, and emerging agentic workflows. The same policy model can support different actor types, but only if the identity architecture exposes the right context and keeps the final decision deterministic. That is where governance maturity will increasingly be measured.

Access review cadences are a weak substitute for runtime control when entitlements are short-lived or context-driven. The better indicator is whether the organisation can explain, reproduce, and defend each decision at the moment it was made. That is the operating standard modern identity programmes are moving toward.

For practitioners

• Prioritise JIT for standing privilege paths Target admin access, break-glass use cases, and other high-risk roles where continuous access is the main exposure. Use policy-based time bounds and automatic revocation so access exists only for the active task window.
• Externalise authorization for high-value applications Move core access rules out of application code and into a versioned policy layer when you need consistent decisions across APIs, services, and queues. Keep the policy decision point separate from the application runtime.
• Feed context into policy decisions Connect directory, device posture, HR, and application signals so policies can evaluate role, device state, time, and business context at request time. If the required context is missing, document that as an integration gap rather than a policy failure.
• Keep AI out of the final allow or deny decision Use AI for anomaly detection, access pattern analysis, and policy suggestions, but require deterministic policy evaluation for the actual authorization outcome. Make humans approve policy changes before they reach production.

Key takeaways

• Approval-heavy IAM creates friction, weakens governance, and encourages over-permissioning when teams cannot evaluate every request in context.
• JIT narrows exposure windows, but PBAC is the stronger model when organisations need repeatable, auditable access decisions at scale.
• The practical direction is to externalise authorization logic, keep AI advisory, and make deterministic policy the control of record.

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.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• 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.
• Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.

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.