OCI identity inventory exposes the access most teams miss

At a glance

What this is: This is a product announcement about OCI support that extends identity inventory into Oracle Cloud Infrastructure and exposes previously overlooked users, machine credentials and AI agents.

Why it matters: It matters because IAM and NHI programmes cannot govern what they do not inventory, and OCI-specific blind spots can leave standing access and unauthorised privilege outside review.

👉 Read Unosecur's OCI identity inventory update for Oracle Cloud Infrastructure

Context

OCI identity governance has often been weaker than in the larger public cloud estates because access review processes, entitlement mapping and credential inventory were built around AWS, Azure and Google Cloud first. When Oracle Cloud is not folded into the same programme, the gap is not visibility alone. The real problem is that people, machine credentials and emerging AI agents can hold access that nobody is consistently reviewing.

The governance issue is straightforward: identity inventory is the prerequisite for access review, privilege reduction and offboarding. If OCI identities, API keys and token-based access are missing from the programme boundary, least privilege becomes partial by design rather than by exception.

Key questions

Q: How should teams govern OCI identities that were outside existing access reviews?

A: Treat OCI as part of the core identity estate, not a special cloud exception. Bring users, credentials, policies and AI agents into one entitlement inventory, then run the same review and remediation cycle you use elsewhere. If OCI is not in the review loop, least privilege is only partial governance.

Q: Why do OCI API keys and secret keys create governance risk even when cloud access is read only?

A: Read-only access still creates risk when the keys are not inventoried, tied to owners and reviewed with the policies they can reach. The issue is not only what the credential can write. It is whether the organisation can see, certify and revoke the access path before privilege drift spreads.

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Should organisations centralise OCI identity governance with other cloud platforms?

A: Yes, if the goal is consistent least privilege. Separate treatment of OCI creates a review gap where policies, compartments and non-human credentials can escape the controls applied to other clouds. A single governance model makes entitlement drift and partial offboarding easier to detect and fix.

How it works in practice

Why OCI identity inventory breaks when access reviews stop at the tenancy edge

OCI brings a mixed identity estate into focus: human users, roles and groups, plus API keys, auth tokens, customer secret keys, OAuth client credentials and OCI applications that authenticate without a person behind them. Identity inventory is the control that makes this visible, but only if the inventory includes policy, compartment and resource relationships rather than just named accounts. Without that graph, broad permissions remain hidden inside the tenancy because the credential, the policy and the resource path are not examined together.

Practical implication: map OCI identities to the policies and compartments they can reach before you attempt any review or remediation.

How over-permissioned OCI access persists in cloud estates

OCI estates create the same access-control failure pattern seen across other clouds, but with an additional governance lag when the tenancy is treated as a separate universe. Over-permissioned access persists because a broad policy can grant more reach than any single account owner understands, and because non-human credentials do not show up in human-led review cycles unless they are explicitly inventoried. Real-time sync helps, but the core technical issue is entitlement discovery across identities, policies and the cloud resources they touch.

Practical implication: review broad OCI policies and the identities bound to them as a single entitlement set, not as isolated accounts.

AI agents in OCI need the same identity context as people and secrets

The article extends the scope beyond conventional machine identities by placing AI agents in the same inventory as humans and NHI. That matters because an agent in a tenancy is not just another workload. It may inherit access paths, call resources, and operate through credentials that never pass through a traditional login flow. Once that happens, access context must include agent ownership, reachable compartments and the secrets or tokens the agent can use, or least privilege becomes impossible to verify in practice.

Practical implication: treat AI agents in OCI as governed identities with explicit owners, scopes and revocation paths.

NHI Mgmt Group analysis

OCI identity blind spots are governance failures, not cloud coverage gaps. When Oracle Cloud sits outside the main access-review programme, the problem is not incomplete documentation. It is that the organisation has accepted a second class of identity governance for a live production environment. That creates a structural exception where entitlement drift, offboarding gaps and unreviewed machine credentials can accumulate. The practitioner lesson is to treat OCI as part of the identity control plane, not as an adjacent cloud silo.

Identity inventory becomes the control plane for least privilege in multi-cloud estates. The article shows the practical limit of entitlement management when accounts, API keys, tokens and secret keys are not inventoried together. Least privilege cannot be verified account by account if policy attachments and resource paths are invisible. The named concept here is the tenancy edge governance gap: access that exists inside a cloud tenancy but remains outside the organisation's review boundary. Practitioners should close the boundary, not just tighten individual permissions.

AI agents in cloud tenancy governance should be treated as first-class identities. OCI support is notable because it places agents in the same inventory model as human and non-human identities. That is the right direction for governance, because agents can exercise access paths without a person in the loop at runtime. The implication is not simply more discovery. It is that identity lifecycle, ownership and revocation need to extend to agentic access with the same rigor applied to human and machine accounts.

Vendor-neutral cloud identity programmes need cross-platform parity, not cloud-by-cloud exceptions. Many organisations have mature controls in one cloud and a lighter process in another, but attackers and internal mistakes do not respect that segmentation. The governance issue here is consistency: if OCI is not included in the same inventory and review model, the programme is only partially measuring the estate. Practitioners should align review scope, offboarding and privilege reduction across every cloud tenancy that matters to production access.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Tenancy edge governance gap: OCI support highlights a recurring multi-cloud failure mode where a cloud tenancy sits just outside the main identity review boundary. Once that happens, access review, offboarding and entitlement cleanup become inconsistent by design, and the programme loses parity across production clouds.

Identity inventory is not an administrative detail. It is the prerequisite for proving least privilege, especially where non-human credentials and AI agents can hold access without a visible login event.

For teams already governing AWS and Azure well, OCI is a reminder that coverage gaps usually appear at the edge of programme scope, not in the core controls themselves.

For practitioners

• Inventory OCI identities as part of the core identity estate Bring users, roles, groups, API keys, auth tokens, customer secret keys, OAuth client credentials and OCI applications into the same identity register used for the rest of the cloud estate.
• Map OCI policies to reachable compartments and resources Document which policies grant access to which compartments and cloud resources, then review those relationships as a single entitlement path rather than separate objects.
• Include AI agents in access review and offboarding processes Assign owners, review cadence and revocation steps to agents running in OCI so their access is governed with the same lifecycle discipline as other identities.
• Remediate broad permissions before expanding OCI adoption Identify risky accounts and unused privileges early, then remove broad access that is not required for the current operating model.

Key takeaways

• OCI support closes a cloud governance blind spot by bringing Oracle Cloud identities, machine credentials and AI agents into a shared inventory.
• The main risk is not that OCI exists, but that access in OCI can sit outside the reviews and offboarding steps applied elsewhere.
• Teams should treat OCI as part of the identity control plane and review policies, compartments and credentials together.

Key terms

• Identity Inventory: Identity inventory is the process of discovering and recording every identity that can access systems or data. For NHIs, it includes owner, purpose, privilege scope, lifecycle status, and where the credential is used. Without inventory, governance, audit evidence, and incident response all become partial and unreliable.
• Tenancy Edge Governance Gap: The blind spot that appears when a cloud tenancy or platform falls outside the organisation's main identity review boundary. It creates a split control model where some identities, policies and secrets are governed while others remain operational but effectively unreviewed.
• Over-Privileged Tool Access: Over-privileged tool access occurs when an AI agent is granted broader permissions than the task requires. This creates avoidable risk because a compromised or misdirected agent can call tools, reach data, or execute actions outside its intended scope, turning routine automation into a control failure.
• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.

What's in the full announcement

Unosecur's full post covers the operational detail this post intentionally leaves for the source:

• The full OCI inventory workflow for users, roles, groups, keys, tokens and OCI applications
• The policy and compartment context that shows how over-permissioned access actually propagates
• The real-time sync and revoke flow for identities discovered inside an OCI tenancy
• The specific way AI agents are surfaced alongside human and non-human identities

👉 The full Unosecur post covers OCI inventory scope, access context and agent discovery in more detail.

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.