Kernel workload identity without secrets changes NHI governance

At a glance

What this is: This is a workload identity analysis arguing that kernel-level enforcement can remove secrets from the credential lifecycle and reduce exposure from static credentials.

Why it matters: It matters because identity teams now have to govern machine access without assuming tokens, vault entries, or service account secrets will exist long enough to be reviewed or rotated.

By the numbers:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Riptides' analysis of kernel workload identity without secrets

Context

Kernel-level workload identity is an attempt to remove the credential object from the access model entirely. Instead of issuing a secret that must be stored, rotated, revoked, and protected across logs, CI jobs, backups, and configuration files, the identity is bound to runtime provenance and attested where the workload executes.

That matters for NHI governance because most machine identity controls still assume credentials exist as managed artefacts. Once the secret disappears, the governance question shifts from protecting a token to proving workload identity continuously and enforcing access at the execution boundary.

Key questions

Q: What breaks when workload identity still depends on static secrets?

A: Static secrets create a replayable trust object that can be copied into logs, pipelines, backups, and metadata stores. Once exposed, the same credential can be reused until revocation reaches every copy, which often takes longer than the attacker needs. The result is standing machine access disguised as ordinary operational convenience.

Q: Why do workload identity programmes need runtime attestation?

A: Runtime attestation ties access to the actual execution context instead of to a token that can be moved or reused. That matters because machine identity risks rarely come from authentication alone. They come from where the secret lives, how long it survives, and whether the workload can prove it is still the same one that was authorised.

Q: How can teams reduce secret sprawl in cloud workloads?

A: Teams should remove default credential distribution paths, prohibit secrets in code and pipelines, and make every new workload prove identity at runtime. The practical goal is to shrink the number of places a credential can exist, because every extra copy expands the attack surface and increases offboarding and revocation failure.

Q: When should organisations prefer ephemeral identity over long-lived credentials?

A: Organisations should prefer ephemeral identity when the workload can authenticate itself at runtime and the business does not need a reusable secret to operate. If the access path can be re-established on demand, ephemeral identity lowers replay risk, reduces cleanup burden, and removes the assumption that a token must survive beyond the session.

Technical breakdown

Why secrets-based workload access keeps failing

Secrets are brittle because they exist outside the workload and therefore inherit every place the workload touches. A token may be injected into an environment variable, copied into a pipeline definition, cached in metadata, or preserved in a backup. Each transition creates a new persistence point and a new revocation problem. Vaults and service accounts reduce some of this risk, but they do not remove the underlying bootstrap problem: the system still needs a first credential before it can establish trust. That is why static secrets remain the default leakage path for machine identity.

Practical implication: inventory every place a workload credential can persist, not just the vault that issued it.

How kernel-attested identity changes the trust boundary

Kernel-attested identity ties access to the workload instance itself rather than to a portable secret. SPIFFE provides the pattern for short-lived, verifiable identities, while kernel-level enforcement moves the trust check closer to process execution so the identity cannot be bypassed in user space. The architectural point is not simply that credentials are short-lived. It is that the trust decision becomes runtime-bound, process-specific, and harder to exfiltrate because there is no reusable secret sitting outside the execution path.

Practical implication: evaluate whether your workload identity boundary is enforced at runtime or only at provisioning time.

Why ephemeral identity is stronger than faster rotation

Rotation improves hygiene, but ephemeral identity changes the failure mode. With static credentials, the question is how quickly a secret can be replaced after exposure. With runtime-issued identity, the question becomes whether an exploitable credential exists at all. That is why ephemeral identity pairs well with SPIFFE-style attestation and zero trust architecture: access is derived from verified workload state, not from a long-lived artifact that must later be cleaned up. The result is less secret sprawl, fewer offboarding gaps, and less dependence on perfect operational discipline.

Practical implication: treat ephemeral identity as a design choice, not a rotation schedule.

Threat narrative

Attacker objective: The attacker’s objective is durable machine access that outlives the original workload event and can be reused across systems.

1. Entry begins when a hardcoded API key, vaulted credential, or copied token is placed into logs, CI pipelines, metadata services, or backups where it can be recovered later.
2. Escalation occurs when the exposed secret is reused outside its intended workload boundary, giving the attacker standing access that can be replayed until revocation catches up, if it ever does.
3. Impact follows when the attacker uses that persistent machine access to reach connected services, move laterally, or exfiltrate data from systems that trusted the workload identity token.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets-based workload identity is now an exposure management problem, not a credential management problem. Once credentials are replicated into CI systems, backups, logs, and metadata stores, the governance burden shifts from issuing access to chasing exposure surfaces. That is why static secret reduction matters more than cleaner vault operations. Practitioners should treat every stored secret as an eventual compromise path, not an administrative asset.

Kernel-level enforcement changes the control plane, but it does not eliminate the bootstrap problem. The article is right that machine identity still needs a trustworthy first assertion, and that first step is exactly where many NHI programmes remain fragile. SPIFFE-style runtime identity helps, but the broader lesson is that identity governance must now account for how the workload is authenticated before any secret exists. Practitioners should reassess how first trust is established.

Bootstrap credential elimination: The old assumption was that a workload could safely receive a first credential and then be managed from there. That assumption fails when the first credential is the primary leakage path, because the act of bootstrapping creates the exposure it is supposed to prevent. The implication is not just better rotation, but a redesign of the trust model itself.

Secret sprawl and runtime identity are converging into a single governance domain. Cloud IAM roles, service accounts, vaults, and workload attestation are no longer separate conversations. They describe one lifecycle: how a workload proves itself, acquires access, and loses that access when conditions change. Practitioners should align machine identity lifecycle governance across those layers instead of treating them as isolated control families.

The market is moving toward identities that are tied to execution, not storage. That trend will pressure teams to measure success by reduced secret persistence, reduced replayability, and stronger runtime attestation rather than by vault adoption alone. Practitioners should expect workload identity programmes to be judged on where trust is enforced, not how many credentials are catalogued.

From our research:

• 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, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why exposure and revocation have to be treated as one control problem.
• For a broader control perspective, Ultimate Guide to NHIs -- Static vs Dynamic Secrets explains why long-lived secrets create durable governance debt.

What this signals

Secret sprawl is now a lifecycle problem as much as a security problem. When machine identities can appear in code, logs, backups, and messaging tools, governance has to follow the credential across its entire usable life. That is why teams should align secret discovery, issuance, and revocation with the same lifecycle discipline used for other identity types.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the surrounding platform ecosystem is becoming part of the credential surface, not just the application stack. That means workload identity teams need to monitor developer tooling, integration layers, and runtime configuration as first-class identity exposures rather than side channels.

The practical shift is toward runtime proof, not static inventory. Teams that already map service accounts and workload identities to OWASP Non-Human Identity Top 10 controls will be better placed to reduce replay risk and narrow the blast radius of exposed credentials.

For practitioners

• Map every secret persistence point Trace where workload credentials appear in logs, CI pipelines, backups, metadata services, code commits, and config files, then remove each nonessential copy before changing the issuance model.
• Move first trust into runtime attestation Require a workload to prove its execution context before it receives access, so identity is bound to runtime state rather than a portable secret that can be replayed elsewhere.
• Separate bootstrap from standing access Design the initial trust step so it cannot become the long-lived credential path, and verify that no service account or token remains as the permanent fallback after startup.
• Measure secret persistence, not just rotation rate Track how long exposed secrets remain valid, how many copies exist across systems, and whether revocation actually reaches all replicas, including pipeline artefacts and backups.

Key takeaways

• Workload identity that still depends on portable secrets keeps the highest-risk failure mode intact: exposure can happen long before anyone notices.
• The scale of secret leakage is still growing, with 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone.
• The practical response is to move trust into runtime attestation and reduce the number of places a workload credential can exist.

Key terms

• Workload Identity: A workload identity is the identity assigned to a machine process, service, container, or application so it can authenticate and access resources. In mature programmes, it is tied to runtime context and lifecycle controls rather than a reusable secret that can be copied or replayed.
• Bootstrap Problem: The bootstrap problem is the challenge of securely giving a workload its first trusted credential or identity proof without already relying on a credential to do it. In machine identity programmes, this is where many secrets-first designs inherit their largest exposure risk.
• Kernel-Level Attestation: Kernel-level attestation is the practice of binding identity proof to the operating system execution layer so the workload can be verified where it runs. It narrows the trust boundary by making identity depend on runtime provenance and process state rather than a portable token.
• Secret Sprawl: Secret sprawl is the uncontrolled duplication of credentials across code, pipelines, logs, backups, and collaboration tools. It increases the number of places an attacker can recover a valid secret and makes revocation incomplete unless every copy is found and removed.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Kernel Workload Identity Without Secrets: a Blueprint for the Post-Credential Era. Read the original.