Secure Oracle Cloud access with least-privilege Just-in-Time provisioning
Ever sign into Oracle Cloud Infrastructure (OCI) through SSO and realise you technically logged in… but you cannot actually do anything? No instances. No policies. No roles. That is what “zero standing access” looks like in real life.
In this short demo, you’ll see how P0 Security maps your existing identity into OCI without pre-provisioning users or groups, lets you request a tightly-scoped role for a set duration and then automatically removes it when the window ends. Approval happens in the flow of work (shown here in MS Teams) and you get a clean audit trail of request, approval, access and expiry.
======================================================
Transcript
Today I’m going to show you what “zero standing access” looks like in Oracle Cloud Infrastructure, and how you can still move fast without leaving permanent privileges behind.
First, I’m signed into OCI through SSO. Authentication worked, but I have zero access by default. When I go to compute, there are no instances available to manage. I also don’t have any policies, groups or roles that grant access to resources. This is the posture we want: no standing access sitting around “just in case.”
Now let’s look at how P0 handles this without forcing you to pre-provision users or groups ahead of time. Even if a group or user doesn’t exist yet in OCI, P0 can dynamically map your identity to what OCI needs only when access is approved.
From here, I switch to the P0 web app and request a specific OCI role with tightly-scoped permissions. I’m going to add our developer group for this demo. This group grants compute access, but only to the set of instances it’s intended to cover. I add a justification and I set a duration. The key point is that access is time-bound by default, not permanent.
Once the request is submitted, an administrator can review it and approve it. In this demo, I’m approving through MS Teams, but the same idea applies no matter where you handle approvals. Approval is explicit, tracked and tied to the request details: who asked, what they asked for, why and for how long.
After the request is approved, I go back to OCI. I refresh my existing session, and I can immediately see my newly granted permissions. Now I can see the compute instances that were previously unavailable and I can manage them.
Just as important, my access is still constrained. I can’t access other resources outside of this approved permission set. This approach is more granular than typical native IAM patterns where teams often end up reusing broad roles because it is operationally easier.
When the approved duration expires, P0 automatically removes access by revoking the underlying membership and permissions. No manual cleanup. No long tail of privileges that hangs around until someone remembers to remove it. You also get a clear audit trail across the full lifecycle: request, approval, access and expiry.
That’s the workflow. Engineers get fast access when they need it, and security gets access that is short-lived, least-privileged and fully auditable by design.