OCI identity inventory exposes the access most teams miss

At a glance

What this is: This is an analysis of OCI identity security support that inventories human, non-human and AI agent identities and surfaces over-permissioned access in Oracle Cloud tenancies.

Why it matters: It matters because IAM, NHI and PAM teams need one governance model across cloud estates, or OCI becomes the place where identities and privileges escape review.

👉 Read Unosecur's OCI identity security announcement

Context

OCI identity governance has often been weaker than in AWS, Azure and Google Cloud because many access review and entitlement processes simply did not extend there. That left users, API keys, auth tokens, customer secret keys and AI agents operating inside OCI tenancies with less oversight than the rest of the enterprise identity estate.

For identity teams, the core issue is not cloud coverage alone. It is whether a tenancy can be brought into the same inventory, review and least-privilege workflow as other platforms, including the identities that authenticate without a person behind them. That is the governance gap this announcement is trying to close.

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 broad OCI policies and stale identities increase identity risk?

A: Because excess access persists when policies are never recertified against actual use. In OCI, dormant accounts, unused permissions and unreviewed credentials can remain active long after ownership has changed, which expands the attack surface and makes privilege creep harder to reverse.

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 do AI agents change OCI identity governance?

A: AI agents turn OCI access into a governed actor problem, not just a user or workload problem. Once an agent can exercise cloud permissions, it needs inventory, ownership, least privilege and revocation just like any other non-human identity.

How it works in practice

OCI tenancy identity inventory and entitlement context

OCI identity inventory is the foundation here. In practice, that means discovering users, roles, groups, apps, API keys, auth tokens, customer secret keys, OAuth client credentials, compartments and the resources they can reach. Without that inventory, access reviews become partial and entitlement decisions are made without seeing the full identity graph. The inclusion of AI agents matters because the tenancy now contains software actors whose access paths must be governed alongside human and classic NHI credentials.

Practical implication: Map every OCI identity source into a single entitlement view before attempting least-privilege remediation.

Why over-permissioned OCI access persists

Cloud privilege drift usually comes from broad policies, stale accounts and unused permissions that are never reviewed in the same cadence as core IAM. OCI is especially exposed when identities are managed separately from the rest of the estate, because policy breadth, compartment reach and dormant credentials can accumulate without a consistent recertification cycle. The technical problem is not just excess access. It is excess access that remains hidden from the controls meant to remove it.

Practical implication: Use the same access review cadence for OCI as for other cloud estates, including dormant accounts and unused permissions.

AI agents in OCI and least privilege

AI agents in a tenancy are not a separate governance category. They are identities with access paths, runtime context and a privilege envelope that can expand if teams treat them as exceptions. Once an agent can reach cloud resources, policy scope and credential handling determine whether it operates within intended bounds or becomes another over-permissioned actor. That is why agent inventory and entitlement review belong in the same control plane as NHI governance.

Practical implication: Apply the same privilege review logic to AI agents as to service accounts and API credentials.

NHI Mgmt Group analysis

OCI support closes an identity governance blind spot, not just a cloud coverage gap. The issue is not whether teams can connect to another cloud. The issue is whether OCI identities, credentials and agent access now enter the same governance loop as the rest of the estate. If they do not, least privilege becomes a partial control rather than an estate-wide standard.

AI agents inside OCI are another NHI class that should not be governed separately from service credentials. The article’s value is that it places agents, API keys, auth tokens and secret keys into one inventory model. That reflects how access actually behaves in mixed estates, where a software actor can hold and exercise cloud privilege without a human in the loop. Practitioners should treat that as a single identity governance problem, not a special-case AI workflow.

Unreviewed OCI tenancy access is a standing privilege problem disguised as platform fragmentation. When a cloud platform sits outside the access review cadence, unused permissions and dormant identities persist longer than teams expect. That is how policy sprawl becomes risk accumulation. The practical conclusion is that cloud-specific exceptions are rarely just exceptions once they survive more than one governance cycle.

Identity blast radius is now a multi-cloud governance metric, not a post-incident metric. The article is describing a broader shift in how identity programmes must be run: by measuring how far each identity can reach across compartments, apps and cloud resources before the access is considered acceptable. Teams that cannot answer that question for OCI do not yet have a complete identity security programme.

Unified identity fabric only matters if it changes remediation behaviour. Inventory alone does not reduce risk unless it leads to revocation, privilege trimming and active review of partially offboarded accounts. For IAM and NHI teams, the test is whether OCI findings are acted on through the same control process as every other cloud, or merely displayed in a new console.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• That visibility gap is why OCI inventories cannot stop at users and groups. It has to include API keys, tokens, secret keys and agent identities as governed assets, not side data.
• For the governance pattern behind this gap, see Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Identity blast radius is becoming the more useful control metric for multi-cloud programmes. If OCI identities can reach more compartments and resources than teams can explain, the issue is not discovery alone. It is that access governance has not yet been normalised across every cloud control plane, which is exactly where recertification and least privilege need to converge.

With 92% of organisations exposing NHIs to third parties, per the Ultimate Guide to NHIs, the next governance problem is not whether identities exist in OCI. It is whether every external and internal identity path is owned, reviewable and revocable before it becomes permanent.

Teams should expect cloud identity tools to keep converging on cross-platform inventory plus remediation. The practical difference will be whether that convergence produces real revocation and privilege reduction, or just a more complete list of things that are still overexposed.

For practitioners

• Inventory OCI identities alongside the rest of the estate Pull users, roles, groups, API keys, auth tokens, customer secret keys, OAuth client credentials and OCI apps into one reviewable identity graph so entitlement decisions are not made in isolation.
• Apply access review cadence to OCI compartments and policies Review active and partially offboarded accounts, the policies granting broad access and the compartments those identities can reach, then remove unused privileges as part of the same control cycle.
• Treat AI agents as governed identities in OCI Include agents in the same least-privilege review path as service accounts and tokens, with clear ownership for access scope and revocation when the agent is no longer needed.
• Verify that read-only connections are actually bounded Use read-only onboarding for discovery, then confirm that the connector cannot become a hidden privilege path and that revocation works cleanly when access should end.

Key takeaways

• OCI support matters because identity governance breaks down fastest where cloud platforms sit outside normal review processes.
• The most important risk signal is not just a new inventory, but the exposure of API keys, auth tokens, secret keys and AI agents in one tenancy view.
• Practitioners should use OCI support to extend least privilege, revocation and offboarding into the same control model used for the rest of the estate.

Key terms

• AI Identity Inventory: A governed record of AI agents, copilots, assistants, and autonomous workflows that links each system to ownership, permissions, and business purpose. It gives security and governance teams a way to review access, assign accountability, and retire agents when they are no longer needed.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Partially Offboarded Account: A partially offboarded account is an identity that has had some access removed but still retains enough entitlement to remain operationally risky. This often happens when lifecycle processes are incomplete, leaving residual access behind after a role change, vendor transition, or departure.
• Unified Identity Fabric: A unified identity fabric is a control model that connects identity data, policy, and response across different identity types in one operating view. It does not remove the need for separate lifecycle rules, but it can reduce blind spots if ownership, inventory, and remediation are consistent.

What's in the full announcement

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

• How OCI tenancy discovery is structured across users, roles, groups, policies and compartments.
• Which identity objects are inventoried in real time, including API keys, auth tokens and customer secret keys.
• How over-permissioned access is surfaced and remediated in the product workflow.
• How read-only onboarding and revocation work for OCI connections.

👉 Unosecur's full post covers OCI inventory, access findings and remediation 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.