TL;DR: P0 Security shows that OCI teams often drift into standing access because manual user, group and policy setup is the fastest way to unblock work, while just-in-time provisioning keeps permissions short-lived, scoped and auditable. The real problem is preserving least privilege under operational pressure, not authentication alone.
At a glance
What this is: This video explains how just-in-time OCI access replaces standing privilege with time-bound, task-scoped permissions that appear inside the user’s existing session and expire automatically.
Why it matters: It matters because IAM and cloud teams need access models that preserve least privilege under production pressure without turning temporary operational needs into permanent NHI-style privilege.
👉 Read P0 Security's video on just-in-time OCI access and least privilege
Context
OCI access often becomes over-permissive when teams solve immediate work blockers by pre-creating users, groups and policies that remain long after the task ends. In practice, the security gap is not sign-in, it is whether authorisation stays temporary when engineers need to act quickly.
Just-in-time access changes the governance model from standing entitlement to request, approval, use, and expiry. For identity teams, the important question is whether cloud permissions remain auditable and task-scoped when they are granted inside the live workflow rather than ahead of time.
Key questions
Q: What breaks when OCI access is not granted just in time?
A: When OCI access is pre-provisioned and left standing, engineers can keep permissions long after the task that justified them. That creates privilege creep, weakens audit clarity, and increases the blast radius if an account is misused. The failure is not login, but authorization that outlives its business purpose.
Q: Why does standing OCI privilege create more risk than temporary access?
A: Standing privilege gives a user or role continuous permission after the operational need has passed, so compromise, misuse or simple drift can persist undetected. Temporary access narrows the exposure window and makes the approval, scope and expiry part of the control, not a cleanup assumption.
Q: What are the signs that cloud access governance is failing in OCI?
A: Common warning signs include outdated access records, inconsistent entitlement changes, weak review evidence, and gaps between approved access and actual system access. If teams cannot quickly show who has access, who changed it, and whether the change was enforced, governance is failing. In OCI, multiple entry points make those gaps more dangerous because one missed control can expose several connected systems.
Q: How should teams govern temporary OCI access requests?
A: They should tie each request to a specific task, a narrow role, a fixed duration and an explicit approver, then verify that expiry removes effective permissions. That makes the access decision auditable and prevents temporary work from turning into permanent privilege.
Technical breakdown
Standing privilege in OCI
Standing privilege is access that remains in place after the immediate need has passed. In OCI, this often takes the form of pre-provisioned users, groups and policies that are reused because they are operationally convenient. The problem is not only excess access, but persistence: the access path exists before the task, survives the task, and can be forgotten after the task. That creates a governance gap between what the engineer needed and what the identity system keeps allowing. Practical implication: treat persistent OCI permissions as a design smell, not a convenience.
Practical implication: audit which OCI roles exist purely to avoid request friction and remove those standing paths.
Just-in-time role issuance inside the active session
Just-in-time access shifts authorisation from pre-assigned membership to ephemeral role issuance. The user authenticates through SSO with no standing access, then requests a tightly scoped role for a defined duration and reason. Once approved, the permission appears in the existing session without a second login or separate credential handoff. This matters because the control boundary moves from who can log in to what the session can do right now. Practical implication: use time-bound role grants when the business need is temporary and explicit.
Practical implication: make duration and scope mandatory fields in the access request so the role maps to a task, not a person.
Automatic revocation and auditability
The governance value of JIT access is not the request alone, but the automatic end state. When the duration expires, membership and associated permissions are revoked without relying on manual cleanup. That removes the common drift where teams intend to unwind access later and never do. It also creates a cleaner evidence trail: request, approval, scope, and end time are all observable. For cloud operations, that auditability is part of the control, not an afterthought. Practical implication: verify that expiry actually revokes effective permissions, not just a group label.
Practical implication: test expiry and manual revocation paths to confirm access disappears from the workload, not just from the approval record.
NHI Mgmt Group analysis
Standing cloud privilege is a process failure, not a technical inevitability: OCI teams do not drift into excess access because least privilege is impossible, but because the fastest operational path is often to pre-create reusable permissions. That is a governance failure in the access model, not a flaw in authentication. The practitioner conclusion is that persistent roles should be treated as exceptions requiring explicit justification.
Just-in-time access works because it changes when privilege exists: the permission is issued only after the need is declared, approved and time-bounded. That matters more than the mechanism that delivers it, because the control problem in cloud operations is often duration and scope, not login. The practitioner conclusion is to govern authorisation by task window, not by long-lived membership.
Ephemeral credential trust debt: any cloud programme that relies on temporary operational exceptions accumulates trust debt when those exceptions are left standing. In this OCI pattern, the debt is visible in roles that remain after the task ends, making audit evidence weaker and incident containment harder. The practitioner conclusion is to eliminate access paths that depend on future cleanup.
Least privilege survives only if the operating model can absorb friction: this article shows that teams will violate the intended control when the approval path is slower than the work. That is why the right governance question is not whether engineers need access, but whether the access model can issue narrow permissions quickly enough to avoid permanent defaults. The practitioner conclusion is to align workflow speed with control scope.
Cross-domain identity governance matters here because cloud access is still identity governance: OCI just-in-time access is a cloud expression of the same lifecycle problem seen in human IAM and NHI governance. Privilege must be created, approved, bounded and removed on time, regardless of whether the subject is a person or a workload. The practitioner conclusion is to manage cloud access as lifecycle control, not as one-off admin convenience.
From our research library:
- 92% of cloud identities are over-permissioned and 62% are dormant.
- Read next: NHI Lifecycle Management Guide
What this signals
Ephemeral credential trust debt: the hidden risk in OCI access is not whether engineers can get in, but whether the organisation keeps paying for temporary exceptions after the task is done. Access reviews cannot compensate for permanently issued permissions, so the model has to fail closed at expiry rather than rely on later cleanup.
Least privilege becomes an operating-model test: if teams can only move quickly by creating standing roles, then the governance design is already misaligned with production reality. OCI access should be issued as a lifecycle event with bounded scope, approved duration and automatic revocation, because that is the only way to keep auditability intact when operations are under pressure.
For practitioners
- Audit standing OCI roles Inventory any OCI users, groups or policies that exist mainly to unblock work, then identify which ones can be replaced by time-bound requests and automatic expiry.
- Require task-scoped approval fields Make justification, role scope and duration mandatory in the access request so approvers can tie permission to a specific operational task.
- Verify expiry revokes effective access Test that the permission disappears from the live OCI session when the window closes, including group membership and any associated inherited rights.
- Remove cleanup-by-memory workflows Eliminate any process that depends on engineers or admins remembering to unwind access later, because the control must end automatically when the task ends.
- Map JIT access to cloud governance Treat OCI access requests as identity lifecycle events, not ad hoc admin actions, so your review and offboarding model covers temporary cloud privilege.
Key takeaways
- OCI access drifts into standing privilege when operational pressure makes permanent roles feel easier than repeated requests.
- Just-in-time provisioning reduces that drift by binding permission to a specific task, a fixed duration and an auditable approval.
- The control only works if expiry really removes effective access, so cleanup cannot depend on human memory.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on replacing standing OCI privilege with narrow, temporary access. |
| NHI-01 — Improper Offboarding | Automatic expiry and revocation address access that lingers after the task ends. | |
| NHI-07 — Long-Lived Secrets | The article argues against access that remains valid beyond the operational need. | |
| Recommendation — Reduce persistent OCI entitlements and issue only task-scoped permissions. Verify temporary OCI access is revoked when the approved window closes. Replace durable cloud access paths with short-lived, task-bound grants. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | OCI JIT access is an entitlement control problem inside the access lifecycle. |
| Recommendation — Apply entitlement governance so cloud permissions are approved, bounded and revocable. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The workflow depends on managing credentials and their lifecycle tightly. |
| Recommendation — Manage credential lifecycles so temporary access expires without manual cleanup. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | OCI access governance is a cloud IAM control issue across approval and revocation. |
| Recommendation — Use cloud IAM controls to enforce time-bound access and remove standing permissions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Standing privilege broadens what a compromised cloud session can reach. |
| Recommendation — Map standing OCI roles to credential-access and lateral-movement risk in detection plans. | ||
Key terms
- 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.
- 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.
- Task-scoped Authorization: Task-scoped authorization limits an AI agent’s access to the specific data, tools, and actions needed for one bounded objective. It is a stronger fit than static role assignment when the system’s behaviour can change during execution and when overreach creates immediate business risk.
- Ephemeral Permission: An ephemeral permission exists only for a short, defined window and is withdrawn automatically when the window ends or the task completes. This is useful for NHI governance because it reduces residual access while preserving the ability to automate high-risk operations safely.
What's in the full article
P0 Security's full video covers the operational detail this post intentionally leaves for the source:
- Step-by-step OCI request and approval flow for just-in-time access
- Live demonstration of access appearing inside an existing OCI session
- Automatic revocation behaviour when the approval window expires
- The exact operational workflow for moving from standing access to ephemeral permissions
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org