Secretless OCI authentication exposes the limits of credential-based access

At a glance

What this is: This is a walkthrough of secretless OCI authentication using SPIFFE-based workload identity, with the key finding that stored credentials are no longer required for client access.

Why it matters: It matters because IAM and NHI teams need to treat workload identity, token exchange, and runtime enforcement as the control plane for cloud API access, not just secrets storage and rotation.

Context

Secretless OCI authentication is a workload identity pattern, not a new way to hide credentials better. The article shows how OCI access can be brokered at runtime so the client no longer depends on durable keys, token files, or configuration-stored secrets.

That changes the governance problem for NHI programmes. The question is no longer only where credentials are stored, but which workload identity is trusted, how that trust is established, and how access is bounded at execution time.

Key questions

Q: What breaks when OCI access still depends on stored client credentials?

A: Stored OCI credentials turn machine access into a secret custody problem. They create exposure in files, logs, backups, and build artefacts, and they force teams to manage rotation and revocation as separate hygiene tasks. When the application itself must hold the key, compromise of the runtime path can become compromise of the cloud identity path.

Q: Why does federated workload identity reduce risk for OCI authentication?

A: Federated workload identity reduces risk because the workload proves who it is at runtime and receives a short-lived credential only for the approved trust relationship. That removes the need for long-lived keys on disk and shrinks the window in which stolen material can be reused outside the intended process context.

Q: How do teams know whether secretless access is actually working?

A: Look for the absence of durable secrets and the presence of controlled token exchange. Workloads should authenticate without client secrets stored in files, images, or environment variables, and access should be granted only through scoped native authorization. If tokens are still recoverable or long-lived artifacts remain, the model is only partially implemented.

Q: Should teams replace every credential-based integration with secretless federation?

A: Not automatically. Teams should prioritise the integrations where credential sprawl, high-value cloud permissions, or supply-chain exposure make static secrets hardest to defend. Where federation is available, it should become the default pattern, but the operating model must still account for trust setup, workload inventory, and fallback handling.

Technical breakdown

SPIFFE-based workload identity and OCI federation

The pattern uses a SPIFFE subject as the stable identity for a workload, then maps that identity into OCI trust through federation. OCI receives a signed token, verifies the issuer and subject, and exchanges that proof for a short-lived session credential. The workload never needs to own a reusable secret to complete the transaction. This is a control-plane change: identity becomes the input to authorisation, not the secret material itself.

Practical implication: treat workload identity registration and federation trust as the primary access control decisions for OCI automation.

Runtime credential injection at the process boundary

The article’s central mechanism is on-the-wire credential injection. Riptides observes a process, matches it to a workload identity, and injects the temporary credential only when the process is making an approved outbound request. That pushes enforcement down to the runtime boundary, close to execution, rather than relying on application logic or environment variables. The important shift is not just secretlessness, but destination-specific credential issuance tied to a verified process identity.

Practical implication: align destination rules and process selectors so credentials are issued only when the expected workload is actually making the call.

Why credential-based access becomes the weaker assumption

Credential-based access assumes the application can safely possess a secret long enough to use it. This article shows why that assumption is brittle: the secret must be stored, rotated, protected from logs and builds, and kept out of reach of supply-chain abuse. With secretless access, the secret is no longer the unit of trust. The unit of trust is the workload identity plus the runtime condition under which access is granted.

Practical implication: re-evaluate any cloud access model that still treats static keys as the default control for machine authentication.

Threat narrative

Attacker objective: The attacker wants reusable cloud access that outlives the original process and lets them reach OCI resources without needing the workload itself.

1. Entry occurs when a client application depends on stored OCI credentials in files, tokens, or local configuration that can be exposed through logs, backups, or supply-chain compromise.
2. Credential access follows when the attacker obtains the reusable key material or session token that the application must keep to authenticate.
3. Lateral movement and impact follow because the stolen credential can be replayed outside the original workload context to access OCI resources with the granted permissions.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secretless access is a workload identity problem before it is a secrets problem: The article is really about moving authorisation away from possession of a credential and toward proof of workload identity at runtime. That matters because NHI governance fails when the credential itself is treated as the trust anchor. Practitioners should read this as a shift from secret custody to identity assurance.

Credential-based access has too many failure surfaces for machine authentication: A stored key has to be protected at rest, excluded from logs, rotated, and kept out of build artefacts and backups. Each of those steps creates a separate governance burden and a separate compromise path. The model is functional, but it scales poorly in environments where workloads authenticate constantly.

Runtime enforcement changes the trust boundary, not just the transport: When the credential is injected only for a matching process and only for a targeted destination, the control point moves to execution time. That reduces the value of any secret that leaks outside the runtime boundary. The implication is that workload identity, not secret distribution, becomes the decisive control surface.

Ephemeral credential trust debt: Secretless architectures reduce standing exposure, but they also expose how much existing governance still depends on long-lived credential assumptions. If your programme expects a secret to persist, be reviewed, and be rotated, then ephemeral issuance breaks that operating model. Practitioners need to recognise that the governance debt sits in the assumption, not only in the implementation.

SPIFFE-style trust is becoming the common language for machine access governance: The combination of cryptographically provable identity, federation, and just-in-time credentials is increasingly how modern machine access gets explained and audited. That does not remove governance work. It changes the questions from who holds the key to which workload is entitled to receive a token, and under what runtime conditions. Teams should align policy, inventory, and runtime enforcement around that model.

What this signals

Secretless OCI access is best understood as a control-plane redesign: the workload becomes the unit of trust, and secret handling becomes a platform responsibility rather than an application burden. That matters for IAM and NHI teams because the control surface shifts from rotation cadence to identity binding, trust policy, and runtime enforcement.

Ephemeral credential trust debt: Many programmes have built procedures around issuing, storing, and rotating keys because those procedures were the only practical way to authenticate non-human access. Secretless federation exposes the debt in that model by removing the need for durable secrets and forcing teams to govern issuance instead of possession.

The practical signal for readers is that OCI authentication models should be reviewed alongside workload inventory, federation trust, and process-level enforcement. If those three pieces are not aligned, secretless design becomes a label rather than a control.

For practitioners

• Define workload identities before credential design Inventory the OCI-facing workloads first, then map each to a stable workload identity and a specific trust relationship. Do not start by issuing reusable keys and trying to wrap controls around them later.
• Bind credentials to destination-specific runtime rules Limit credential issuance to approved process and egress combinations so a workload only receives access when it is making the intended OCI call.
• Remove application ownership of credential storage Eliminate local key files, session tokens, and environment-based secrets from the application path wherever federation can supply short-lived credentials instead.
• Test the fallback path as an equal control If filesystem-based access is still required, treat sysfs-exposed credentials as a constrained fallback and verify that only the matching workload identity can read them.
• Review supply-chain exposure around cloud client secrets Check whether OCI access still depends on secrets that could be captured through CI artefacts, dependency compromise, or build-time injection.

Key takeaways

• Secretless OCI authentication replaces reusable client secrets with workload identity and runtime token exchange, which materially changes how machine access should be governed.
• The strongest evidence in the article is the removal of stored keys from the client path and the use of short-lived credentials issued only when a trusted workload makes the request.
• Teams that still rely on credential custody for cloud automation should re-evaluate trust binding, runtime enforcement, and where secrets are allowed to exist.

Key terms

• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• On-the-wire Credential Injection: On-the-wire credential injection is a runtime pattern where credentials are added to a request as it is sent, rather than being exposed to the process beforehand. It narrows the place where trust must exist and helps prevent local storage of secrets in developer or workload environments.
• SPIFFE ID: A SPIFFE ID is a unique, cryptographically verifiable identity for a workload or service. In the SPIFFE framework, it is expressed as a URI, such as spiffe://trust-domain/path, and is used to authenticate software entities across systems without relying on static secrets, enabling workload identity and policy enforcement.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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 or NHI governance programme, it is worth exploring.