Zero-footprint access for external workloads and AI agents without standing users or standing credentials

OCI IAM now supports Workload Identity Federation for OCI resources using ephemeral RPSTs. The feature uses inbound WIF to give external workloads and AI agents a way to use the identity they already have and exchange it for short-lived OCI access. The workload can access OCI resources without a new OCI user, API key, secret, rotation schedule, or offboarding task for each caller.

That outcome is zero footprint workload access. A pod in self managed OKE or Kubernetes, a GitHub Actions workflow, or an agent running in AWS, Azure, or Google Cloud already carries a platform-issued credential. Human-assisted and autonomous AI agents, including agents launched from Claude, OpenAI, or Codex workflows, can follow the same pattern when their source platform can issue a verifiable token.

Figure 1. Workload Identity Federation for OCI Resources uses inbound WIF to exchange trusted external JWTs for ephemeral RPSTs that OCI IAM can evaluate for allow and deny decisions.

Why this matters now

External workloads now show up in more places than one cloud control plane can own. A GitHub Actions workflow may need to publish an artifact to OCI Object Storage. A service running in self managed OKE may need to retrieve a secret or call an OCI API. An agent running in another cloud may need temporary access to data or functions in OCI.

AI makes this access pattern more urgent. A developer may ask Codex to inspect build output before a deployment. A support engineer may ask Claude to summarize customer context. An autonomous operations agent may wake up on an event and call APIs without a person approving each step.

Each agent may need OCI resources such as Object Storage, Functions, Secrets, KMS, databases, and service APIs. Giving that agent a static OCI key creates a standing credential. Creating a service user for every runtime creates standing users. Both approaches leave security teams with objects that outlive the workload.

The model

The inbound WIF model has four steps. First, the administrator registers the issuer once so OCI knows how to verify tokens from that source. Second, the administrator defines the match by choosing which claims and values identify the trusted workload, such as repository, branch, workflow, service account, namespace, issuer, source cloud, or agent mode. Third, OCI maps a matching token to an OCI resource principal session that IAM policy governs. Fourth, the workload presents its native token and proof-of-possession key, and OCI returns an ephemeral RPST.

The RPST represents the workload session at runtime. It can carry selected source claims as ext_* attributes, such as ext_repository, ext_workflow_ref, ext_actor, ext_iss, or another claim the source token contains and the trust configuration allows. The workload then signs OCI API calls with the private key that matches the public key used during token exchange.

Deny policies as RPST claim guardrails

Deny becomes powerful because IAM can read attributes from the RPST, not only the fact that token exchange succeeded. During token exchange, OCI copies selected claims from the incoming JWT into the RPST using the ext_ prefix. In policy evaluation, those claims appear as principal attributes such as request.principal.ext_repository, request.principal.ext_workflow_ref, request.principal.ext_actor, or request.principal.ext_environment.

Allow policies answer the normal access question: which verified workload may perform this action on this resource? Deny policies answer the guardrail question: which workload context must never perform this action, even if another policy would otherwise allow it? When a deny condition matches, it blocks the request centrally at the IAM layer.

That gives security teams a clean control for agents. A human-assisted workflow from an approved repository may read a tagged bucket. An autonomous agent may be blocked from managing Secrets or KMS keys. A workflow with the wrong repository, branch, issuer, environment, subtype, or agent mode can be denied before it reaches the resource.

Figure 2. OCI IAM can read propagated RPST claims as principal attributes and use them for both Attribute-Based Access Control, or ABAC, allow policies and deny guardrails.

Illustrative deny pattern
Deny any-user to manage secret-family in compartment <production-compartment>
where all {
  request.principal.type = 'identityfederateddomainapp',
  request.principal.ext_agent_mode = 'autonomous'
}

Illustrative ABAC allow pattern
Allow any-user to read objects in compartment <application-compartment>
where all {
  request.principal.type = 'identityfederateddomainapp',
  request.principal.ext_repository = '<approved-org>/<approved-repo>',
  request.principal.ext_workflow_ref = '<approved-workflow-ref>'
}

The exact resource families, claim names, and policy conditions should follow the customer’s published OCI policy syntax and the claims available from the source provider. The design point is stable: after the source claims become RPST attributes, OCI IAM can use them for both positive authorization and negative guardrails.

The three outcomes

This model delivers three customer outcomes: No Standing Users, No Standing Credentials, and Claim-Based Authorization

Attribute-Based Access Control,ABAC for scale

Claim based authorization turns workload context into policy input. A repository claim can identify the GitHub source. A workflow reference can identify the deployment path. A self managed OKE or Kubernetes issuer and subject can identify a cluster, namespace, and service account. A source cloud claim can identify the AWS, Azure, or Google Cloud workload identity. An agent mode claim can distinguish human-assisted access from autonomous access when the source platform provides that signal.

Those claims can be combined with OCI resource scope and tags. Instead of creating a different OCI user and custom policy for every workload, teams can define policies that compare principal context from the RPST with resource metadata. This is the ABAC story: authorization follows attributes about the workload and the resource, not a growing inventory of standing identities.

Common access patterns

Self managed OKE and Kubernetes are natural examples. A pod can use its projected service account token as the source credential. OCI validates the issuer and signature, propagates selected claims such as namespace or service account, and returns an RPST that the OCI SDK can use. Policy can then scope access to the workload identity instead of the worker node identity.

GitHub Actions is another common pattern. The workflow can present a signed OIDC token that identifies the organization, repository, workflow, branch, or environment. OCI can exchange that token for an RPST and IAM can restrict access to the exact repository and workflow that should reach the resource.

Agents running in other clouds follow the same trust model. AWS, Azure, or Google Cloud can vouch for the workload with a native token. OCI validates the trusted issuer, maps selected claims into the RPST, and uses IAM policy to allow the intended operation while Deny policies block risky contexts.

The bottom line

Workload Identity Federation for OCI Resources using Ephemeral RPST gives OCI IAM a cleaner model for multicloud workloads and AI agents. Customers get zero footprint access: No Standing Users, No Standing Credentials, and Claim Based Authorization that supports ABAC policies and Deny guardrails. OCI trusts the source, validates the token, propagates useful claims into an ephemeral RPST, applies policy, and records the path in audit.