Beyond approvals: policy-based IAM and JIT for compliance

At a glance

What this is: This is a panel-based analysis of how JIT access and PBAC can move IAM beyond approval queues and toward scalable, auditable authorisation.

Why it matters: It matters because IAM, PAM, NHI, and emerging agent governance programmes all fail when access remains static, over-broad, or hard to explain at decision time.

By the numbers:

• 80% of organizations have moved to an identity-first security model.
• 4,500 microservices in their architecture

👉 Read Cerbos's analysis of JIT, PBAC, and AI-assisted IAM governance

Context

Identity-first security only works when authorisation keeps pace with how work actually happens. The problem in this article is not identity as a concept, but the growing mismatch between approval-based IAM processes and modern environments where access needs to be contextual, short-lived, and explainable.

For IAM and PAM teams, the real governance gap is the persistence of standing privilege, manual approvals, and policy logic trapped inside applications. For NHI and agentic AI programmes, the same pattern shows up when machine identities or agents inherit broad access without deterministic enforcement or clear accountability.

Key questions

Q: How should security teams implement just-in-time access without creating new governance gaps?

A: Security teams should use just-in-time access to remove standing privilege, but only where the approval criteria, task scope, and expiration conditions are defined up front. The goal is to reduce exposure, not to replace governance with speed. The strongest programmes pair JIT with evidence-rich logging and tight ownership of privileged paths.

Q: Why does policy-based access control matter more than traditional role-based access in modern IAM?

A: Policy-based access control matters because it evaluates each request using current context instead of relying on broad roles that can drift out of date. That makes access decisions more precise, more auditable, and easier to apply consistently across applications, APIs, and legacy systems. It also supports zero standing privilege more naturally than static role assignment.

Q: What breaks when access decisions are embedded inside each application?

A: Governance breaks down because security teams lose a single place to test, version, and explain access logic. Application-embedded authorisation creates inconsistent rules, weak auditability, and hidden exceptions that are difficult to govern at scale. A central policy layer restores visibility without removing application ownership.

Q: How should organisations use AI in access governance without letting AI make access decisions?

A: Organisations should use AI for recommendations, anomaly detection, policy tuning, and recertification support, but keep the actual allow or deny decision deterministic. Access decisions need to be reproducible and defensible, especially when auditors or incident responders ask why access was granted. AI should improve the process around the decision, not replace the decision itself.

Technical breakdown

Just-in-time access and standing privilege removal

Just-in-time access replaces always-on entitlements with access that exists only for a defined task window. In this model, policy predefines who can obtain access, under what conditions, and for how long. That reduces standing privilege, improves auditability, and limits the attack window if an account is compromised. The limitation is that JIT still grants access for a duration, so it is better thought of as reducing exposure rather than eliminating it. In complex estates, it also depends on reliable provisioning paths and well-designed fallback workflows.

Practical implication: identify privileged paths where always-on access can be replaced with short-lived, policy-driven elevation.

Policy-based access control for request-time authorisation

Policy-based access control evaluates each access request in real time using identity, resource, action, and context signals. Instead of storing broad permissions and hoping they remain appropriate, the policy engine returns allow or deny at the moment of use. That makes authorisation more consistent across services, APIs, and legacy fronts, and it supports zero standing privilege as an operating model. The key design requirement is trustworthy context from directory, device, application, and HR systems, because a policy engine is only as accurate as the inputs it receives.

Practical implication: externalise critical authorisation logic so business rules can be versioned, tested, and enforced centrally.

AI-assisted governance without AI-driven access decisions

The article draws a hard line between using AI to support governance and using AI to make access decisions. Deterministic policy evaluation must remain in the control path because access decisions need to be reproducible, auditable, and defensible. AI can help with recommendations, anomaly detection, recertification prioritisation, and policy suggestions based on usage data, but it should not decide whether a user or agent gets access. That distinction matters even more as agentic AI enters the environment, because the identity layer must stay inspectable even when the workload becomes more dynamic.

Practical implication: allow AI to inform policy operations, but keep enforcement deterministic and policy-defined.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

JIT reduces exposure, but it does not erase the standing-privilege assumption. The article is right to treat JIT as a way to shrink the approval queue and the attack window, but it still grants access for a bounded period. That means the governance model is still built around the assumption that privilege can be safely pre-authorised for a task window. Practitioners should recognise that JIT narrows the risk, but does not change the underlying access model.

PBAC is the stronger expression of zero standing privilege because it moves authorisation to the moment of use. That shift matters across human, workload, and emerging agent identities because access is no longer held and reviewed later. Instead, the policy itself becomes the control object, which aligns better with runtime context and auditability. The practitioner implication is to treat policy design as an engineering discipline, not an admin side task.

Access review processes were designed for privileges that persist long enough to be reviewed. That assumption fails when access is ephemeral, request-scoped, or delegated through services and agents. The implication is not just to automate reviews, but to re-examine which identities still produce a stable review artefact at all.

Policy logic hidden inside applications creates an invisible governance surface. When every service embeds its own authorisation rules, security teams lose consistency, testability, and traceability. A central policy layer does not remove local ownership, but it gives the organisation a common point for evidence and control. Practitioners should treat scattered application logic as a governance defect, not just an engineering inconvenience.

AI belongs around the access decision, not inside it. The article draws the right boundary by using AI for insight, anomaly detection, and recertification support while keeping the actual allow-or-deny decision deterministic. That boundary protects auditability and reduces the chance that governance becomes opaque. Practitioners should keep the decision path explainable even as they automate the surrounding workflow.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• The lifecycle gap is not abstract. Read NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that need to keep pace with policy-driven access.

What this signals

Policy-driven access only scales if the surrounding identity data is reliable. In practice, that means identity, device, HR, and application context must be available at decision time, or the policy engine becomes a bottleneck rather than a control. For teams extending these models to workload and agent identities, the next step is not more policy language, but better context plumbing and governance around source-of-truth data.

Zero standing privilege becomes meaningful when access review is no longer the primary control. If your programme still depends on periodic review to catch stale access, you are already behind the operating model described here. That is especially true for NHI estates, where ephemeral or service-scoped access can outpace traditional recertification cadence and leave little durable evidence to review.

JIT and PBAC together create a useful governance split. JIT can contain privileged elevation, while PBAC can govern day-to-day runtime authorisation across applications and services. Teams that treat them as interchangeable will miss the real design choice, which is whether the organisation wants to govern access at provision time, request time, or both. For a deeper baseline, align your model with the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0.

For practitioners

• Map standing privileges by task and owner Inventory the accounts and roles that remain permanently active, then classify which of them can be converted to task-scoped elevation or request-time policy checks. Focus first on administrative paths and high-value systems where dormant access creates the largest blast radius.
• Externalise critical authorisation rules from code Move high-risk access logic into a central policy layer so every decision can be versioned, tested, and audited. Start with one application or service family, and require context signals such as device posture, role, and time conditions to come from trusted sources.
• Define the context signals your policies truly need Check whether identity, resource, device, HR, and risk systems can supply the attributes your policies depend on. Where signals are missing, close those integration gaps before expanding policy scope, otherwise your access model will fail at runtime even if the policy syntax is correct.
• Keep AI out of the enforcement path Use AI to surface anomalous access, recommend policy changes, and prioritise recertification, but require deterministic evaluation for the actual allow or deny outcome. This preserves evidence quality for audit and keeps governance defensible when access decisions are challenged.

Key takeaways

• Approval-heavy IAM does not scale cleanly across modern estates, especially where standing privilege and fragmented governance still dominate.
• JIT and PBAC solve different parts of the access problem, with JIT shrinking exposure windows and PBAC shifting decisions to runtime context.
• Access governance now depends on deterministic policy, trustworthy context, and clear evidence, not on faster human approvals or AI-made decisions.

Key terms

• Just-in-time access: Just-in-time access is a model where elevated permissions are granted only when a specific task requires them and then removed automatically when the need ends. It reduces standing privilege and shrinks the attack window, but it still depends on accurate policy, reliable provisioning, and clear governance over who can request elevation and why.
• Policy-based access control: Policy-based access control evaluates each access request against defined rules and live context such as identity, device posture, resource, and time. It externalises authorisation from application code, which improves consistency, testing, and auditability. For autonomous and machine-driven environments, it becomes the strongest pattern for deterministic runtime access decisions.
• Zero standing privilege: Zero standing privilege is the principle that no identity should retain always-on access beyond what is needed for an immediate task. It applies across humans, service accounts, and AI-driven workflows, but the implementation differs by actor type. In practice, it shifts governance from persistent entitlement management to request-time control and evidence.
• Deterministic authorisation: Deterministic authorisation means the same inputs produce the same allow or deny decision every time, without relying on probabilistic or opaque logic. It matters because access decisions must be explainable, auditable, and repeatable under scrutiny. This is especially important when AI is used for analysis around the decision rather than for the decision itself.

Deepen your knowledge

Policy-based access control, just-in-time access, and access governance for NHI are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from an approval-heavy starting point, it is worth exploring.

This post draws on content published by Cerbos: Beyond approvals - automating IAM for compliance, security, and business agility. Read the original.