Secretless adoption redefines NHI governance for modern workloads

At a glance

What this is: This is an analysis of secretless adoption and its four-stage move from static secrets to identity-based access for workloads and AI agents.

Why it matters: It matters because IAM, NHI, PAM, and lifecycle teams need controls that govern machine access at runtime rather than relying on stored credentials and periodic review.

By the numbers:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Akeyless's analysis of secretless adoption for workloads and AI agents

Context

Secretless security is the idea that applications prove who they are at request time instead of carrying reusable credentials everywhere. That matters for NHI governance because static passwords, API keys, tokens, and certificates create a standing exposure window that modern cloud, CI/CD, and machine-to-machine environments no longer need.

The primary governance gap is not whether secrets exist, but whether any workload ever sees them. As organisations move toward OIDC, SPIFFE, dynamic secrets, and central policy enforcement, the identity programme shifts from credential custody to runtime authorisation and revocation control.

For security teams, the practical question is no longer whether to centralise secrets. It is how quickly they can reduce the number of places where secrets are visible, and whether their current controls can support ephemeral machine identity without widening operational risk.

Key questions

Q: How should security teams implement secretless access for workloads without breaking operations?

A: Start with the systems that expose the most reusable credentials, then replace those paths with workload identity, dynamic secrets, and central policy enforcement. Preserve application behaviour by keeping the authentication flow stable while removing the secret from the client side. The goal is not to change business logic, but to remove readable credentials from the workload boundary.

Q: Why do static secrets create more risk than dynamic machine identity?

A: Static secrets create a standing exposure window because they can be copied, reused, and forgotten long after issuance. Dynamic machine identity reduces that risk by making access short-lived, scoped, and revocable at runtime. That matters most in CI/CD, cloud, and service-to-service environments where one leaked credential can outlive the task it was meant to support.

Q: What do security teams get wrong about secretless architectures?

A: They often assume secretless means no secrets exist anywhere, when the real objective is to stop secrets from reaching the application or developer. Others treat OAuth or token use as automatically secretless, even though long-lived tokens can still be stolen and reused. The governance test is whether the workload ever sees a reusable credential.

Q: Who should be accountable for secretless governance in an IAM programme?

A: Accountability should sit with the identity, cloud, and platform teams together, because secretless depends on workload identity, policy enforcement, and lifecycle control at the same time. If any one of those functions is isolated, the model falls back into manual credential handling. That is why secretless governance belongs in the same operating model as NHI and access management.

Technical breakdown

From static secrets to dynamic secrets

Static secrets are long-lived credentials embedded in code, images, configs, or vaults. Dynamic secrets change the model by issuing short-lived credentials on demand, usually tied to a specific workload, resource, or session. That reduces the useful life of a stolen credential and removes the need for broad reuse across environments. The important control distinction is that the secret becomes an output of policy, not an input handed to the application. In NHI terms, the workload never needs to know the secret at all, only the identity it must present to get one.

Practical implication: map every persistent credential to a dynamic replacement path and remove any application flow that depends on the secret being readable by the workload.

Secret zero, workload identity, and runtime proof

The secret zero problem is the bootstrap challenge of proving identity before any credential exists. Secretless architectures solve that by relying on an already trusted identity source such as cloud IAM roles, Kubernetes service accounts, or SPIFFE-based workload identity. Once the workload proves itself, the platform can mint a short-lived credential or inject access without exposing the underlying secret. This is what makes secretless different from simple rotation: the authentication root shifts from stored secrets to verifiable identity at the edge of the transaction.

Practical implication: use trusted workload identity as the bootstrap control and eliminate designs where an application must cache a reusable bootstrap secret.

Why zero standing privilege changes machine access governance

Zero Standing Privilege means access exists only when needed and disappears immediately after use. In machine identity programmes, that changes governance from entitlement management to transaction-scoped authorisation. The platform becomes responsible for issuing, injecting, and revoking access in a way the workload cannot extend on its own. Standards such as OIDC and SPIFFE matter here because they give you a portable identity layer that is not tied to one cloud or one secrets store.

Practical implication: treat standing machine privilege as a design defect and redesign access paths so every request is time-bound, auditable, and centrally revoked.

NHI Mgmt Group analysis

Secretless is a secrets-governance model, not a secrets-elimination model. The useful distinction is that secrets still exist, but the workload never handles them directly. That shifts the control problem from storage hygiene to exposure prevention, which is the real governance win for NHI programmes. Teams should stop measuring success by how many secrets are vaulted and start measuring how many never reach the application boundary.

Dynamic machine identity exposes the weakness of review-based governance. Static access reviews assume credentials persist long enough to be examined, recertified, and removed. Secretless and just-in-time credentialing compress that window to runtime, which means lifecycle controls must move closer to request-time enforcement. The practitioner takeaway is that periodic review becomes a lagging assurance layer, not the primary control.

Secret zero is the named concept that separates modern machine identity from older secrets management. It is the bootstrap assumption that a workload can prove who it is without already possessing a reusable secret. When the environment supports cloud IAM roles, Kubernetes service accounts, or SPIFFE attestation, that assumption becomes manageable. Practitioners should treat secret zero as the design point that determines whether secretless architecture is feasible at all.

AI agents extend the NHI problem, but they do not change the underlying governance logic. The article’s own framing shows that agents still need verifiable identity, time-bound access, and revocation control. What changes is the number of runtime requests and the speed at which credentials are consumed, which increases the cost of any standing privilege left behind. Identity teams should govern AI agents as workloads with sharper access tempo, not as a separate policy universe.

Centralised policy control is the real scaling mechanism behind secretless adoption. Without a single point for issuance, revocation, and audit, organisations only move the exposure problem from one place to another. The operational implication is that secretless maturity depends on policy consistency across cloud, Kubernetes, CI/CD, and on-premises systems. Practitioners should evaluate whether their current architecture can enforce one policy model across all of those surfaces.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• That wider exposure pattern is why the Guide to the Secret Sprawl Challenge is the right next resource for teams trying to reduce secret visibility across code, pipelines, and runtime systems.

What this signals

Secretless governance will increasingly be judged by exposure reduction, not credential count. If your programme still reports success by how many secrets are rotated or vaulted, it is measuring activity rather than risk removal. The better signal is how many workloads can prove identity without ever seeing a reusable secret.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, the operational pressure is shifting from discovery to containment. That means identity teams need a control model that prevents secrets from becoming accessible in the first place, not just one that finds them after the fact.

As secretless patterns spread across cloud, CI/CD, and AI agents, the boundary between IAM and NHI governance will keep narrowing. Teams that can unify workload identity, policy enforcement, and lifecycle controls will be better positioned to adopt ephemeral access without creating a new class of unmanaged machine accounts.

For practitioners

• Inventory every secret exposure point Map where static credentials still appear in code, CI/CD, containers, cloud roles, and service-to-service calls. Prioritise systems where the application can read the secret directly, because those are the highest-exposure paths and the easiest to misuse.
• Replace reusable bootstrap secrets Use trusted workload identity such as cloud IAM roles, Kubernetes service accounts, or SPIFFE attestation so applications prove identity without storing a permanent secret zero. Remove flows that depend on a credential being embedded just to start the session.
• Shift from rotation to runtime issuance Use dynamic secrets and just-in-time credentials for access paths that still need credentials, then make revocation automatic at session end. Pair that with policy enforcement so the workload never sees the underlying secret value.
• Align lifecycle controls to machine identity tempo Rework access reviews, offboarding, and recertification for workloads and AI agents so they validate request-time access paths rather than long-lived entitlements. For background on credential exposure patterns, see the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10.

Key takeaways

• Secretless architecture does not remove secrets from the world, but it does remove them from the application boundary where attackers can steal them most easily.
• The strongest evidence in the market points to a structural problem, not an edge case: AI infrastructure and software delivery environments are generating more credential exposure, faster than legacy controls can absorb.
• Identity teams should treat workload identity, dynamic issuance, and runtime revocation as the control set that replaces static credential custody for modern machine access.

Key terms

• Secretless architecture: A secretless architecture is a model where applications and workloads authenticate with identity instead of handling reusable credentials directly. The secret may still exist in the system, but it is issued, used, and revoked behind the scenes so the workload never sees it.
• Secret zero: Secret zero is the initial trust problem of proving a workload’s identity before any credential has been issued to it. In practice, this is solved by using an existing trusted identity source such as cloud IAM, Kubernetes service accounts, or SPIFFE attestation to bootstrap runtime access.
• Dynamic secret: A dynamic secret is a short-lived credential generated on demand for a specific task, session, or resource. It reduces the usefulness of stolen credentials by limiting scope and lifespan, and it supports machine access models where standing privilege is no longer acceptable.
• Zero Standing Privilege: Zero Standing Privilege is the principle that access should not persist beyond the moment it is needed. For machine identities, that means credentials are issued just in time, tightly scoped, and revoked automatically so the workload cannot accumulate long-lived access.

What's in the full article

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

• Step-by-step explanations of the secretless workflow across authentication, authorisation, dynamic credential generation, and transparent injection.
• The vendor's staged adoption model for moving from static secrets to dynamic secrets, OIDC, SPIFFE, and secretless operation.
• Implementation detail on solving the secret zero problem across cloud IAM, Kubernetes service accounts, and on-premises identity.
• The AI agent extension path that maps secretless principles to runtime identity for automated workloads.

👉 The full Akeyless article covers the secretless workflow, secret zero problem, and AI agent access model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.