Workload IAM closes the secret zero gap in multicloud access

At a glance

What this is: This is an analysis of why vaults alone do not solve non-human access, and why workload IAM, federation, service meshes and PKI each cover different parts of the identity problem.

Why it matters: It matters because IAM teams need to separate secret storage from runtime access control, especially where machine identities, CI/CD pipelines and AI services now outnumber human accounts in practice.

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.
• Stolen credentials were the leading initial access vector in 22% of breaches, according to the Verizon 2025 DBIR.
• Machine identities outnumber human identities by roughly 82 to 1 in the average enterprise, according to CyberArk's 2025 research.

👉 Read Aembit's analysis of workload IAM vs. secrets management

Context

Workload identity is the discipline of proving a non-human workload's identity at runtime and granting it only the access it needs for that specific request. The core governance gap is that storing secrets securely does not answer the harder question of how a workload proves who it is before it gets a credential.

That gap widens in multicloud estates, where each platform has its own trust model, vault, and policy syntax. As machine identities grow faster than human identities, identity teams have to treat secret zero, federation, and runtime authorisation as one governance problem rather than separate tools.

The article's framing is typical of current enterprise environments: most organisations have some combination of vaulting, cloud IAM, and certificates already in place, but few have a consistent access layer across all workloads.

Key questions

Q: How should security teams replace shared secrets for workloads that span multiple clouds?

A: Use federated workload identity so the workload proves who it is with a signed token or attestation instead of a shared static secret. Then scope the resulting credential tightly to the request and make the trust relationship revocable when the workload, supplier, or environment changes.

Q: Why do secrets managers not fully solve non-human identity risk?

A: Secrets managers protect where credentials are stored, but they do not decide who may request them or under what runtime conditions. If the bootstrap credential is stolen, the attacker can still reach everything behind that vault, so storage hygiene alone leaves the access problem intact.

Q: What breaks when service mesh or mTLS is treated as full workload governance?

A: Transport controls verify that services can talk securely, but they do not decide whether the request is appropriate for the workload's context. If teams stop at mTLS, they may miss policy failures around environment, posture, destination sensitivity, or business hours.

Q: When should organisations prioritise workload IAM over vault expansion?

A: Prioritise workload IAM when the same access pattern must work across clouds, SaaS integrations, and on-premises systems. Vault expansion helps with storage, but workload IAM matters more when the real problem is runtime authorisation and short-lived access tied to verified identity.

Technical breakdown

Why the secret zero problem persists in vault-based architectures

A secrets manager centralises credentials, encrypts them at rest, and can rotate them on schedule, but it still depends on a bootstrap credential to get the workload into the vault. That bootstrap secret is the secret zero. If an attacker obtains it, they inherit access to whatever the vault protects, which means the vault has reduced sprawl but not eliminated trust in a stored credential. This is why vaults solve storage more than authorisation. The identity question remains: who is allowed to ask for a secret, under what conditions, and with what lifetime?

Practical implication: treat vaults as one layer in a broader non-human identity model, not as the control that ends credential risk.

How OIDC federation and SPIFFE-based identities remove shared secrets

OIDC federation replaces shared static credentials with signed assertions about workload identity. A workload proves where it runs and who it is, then receives a short-lived token or credential scoped to the request. SPIFFE and SPIRE extend that idea by giving workloads cryptographically verifiable identities that are portable across environments. The technical win is that no long-lived secret crosses the trust boundary. The governance tradeoff is policy consistency: every trust relationship still has to be defined, monitored, and revoked when environments or suppliers change.

Practical implication: standardise on federated workload identity where cross-cloud access is common, and document trust relationships as part of lifecycle governance.

Why service meshes and PKI solve transport, not context

A service mesh authenticates workload-to-workload communication, usually with mutual TLS, and automates certificate issuance and rotation inside a cluster. PKI extends certificate-based trust across clusters, clouds, and on-premises systems. Both reduce static secret exposure and improve machine authentication. But they operate mainly at the transport layer. They can confirm that two systems may communicate securely, yet they do not decide whether the request is appropriate for the workload's current context, posture, or business function. That policy decision belongs elsewhere.

Practical implication: use service mesh and PKI for transport trust, then pair them with policy-based access controls for runtime authorisation.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• 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

Secret storage and secret use are different governance problems. Vaulting reduces exposure, but it does not answer who may authenticate to the vault, under what runtime conditions, or how access should be revoked when the workload changes. That split matters because many NHI programmes stop at storage hygiene and never close the authentication layer. The practitioner conclusion is that secret governance must be modelled as both custody and access.

Workload identity is now the control plane that matters most for non-human access. In multicloud estates, native IAM, OIDC federation, PKI, and workload IAM each solve a different part of the access chain. The category is moving toward policy-driven runtime decisions instead of persistent credentials. Practitioners should evaluate whether their current stack can enforce one access model across clouds, SaaS, and on-premises systems.

Conditional access is no longer only a human identity concept. When machine identities authenticate into production APIs, databases, or AI services, context such as environment, posture, and request timing becomes part of access governance. That creates a named concept worth tracking: runtime credential trust debt: the accumulated risk created when secrets are reused longer than the context that justified them. The practitioner conclusion is that long-lived credentials create governance debt that vaulting alone cannot amortise.

The lifecycle problem is shifting from issuing credentials to proving trust continuously. As machine identities scale, recertification, offboarding, and rotation have to address not just the credential but the trust relationship behind it. A secret can be rotated while the underlying entitlement remains overbroad. That means identity governance teams need to review the lifecycle of both the workload and the credential together. The practitioner conclusion is that access reviews must cover runtime trust, not only inventory.

AI services make NHI governance brittle faster than traditional workloads do. The article's AI angle is a reminder that new machine classes often create credential sprawl before policy catches up. That does not make them autonomous by default, but it does mean they behave like high-volume NHIs with new integration surfaces. Practitioners should treat AI-connected workloads as an NHI growth vector and apply the same lifecycle discipline from day one.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• That acceleration makes the lifecycle view urgent, so compare it with Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for governance patterns that outlast a single tool choice.

What this signals

Runtime trust is becoming the real control boundary for machine access. As organisations distribute workloads across clouds, vaults and certificates can no longer be evaluated in isolation. Identity teams need to watch for access paths that still depend on persistent bootstrap secrets, because those are the places where programme risk accumulates fastest.

Runtime credential trust debt: this post's central pattern is that static access persists longer than the business context that justified it. That creates a governance backlog across provisioning, rotation and offboarding, and it becomes harder to justify each entitlement as machine populations scale. The practical signal is simple: if your reviews stop at secret inventory, your access model is already behind the workload model.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026, AI-connected infrastructure is creating new credential surfaces faster than legacy governance processes can classify them. Teams should expect more secretless access patterns, not because they are fashionable, but because they reduce the trust debt that static credentials keep creating.

For practitioners

• Separate secret storage from access governance Map every vault to the identity source that can ask it for credentials, then document the runtime conditions that authorize each request. If a workload can reach a vault, that path needs review as part of the access model, not just the secrets inventory.
• Use federated identity for cross-boundary workloads Replace shared static secrets with OIDC federation or workload identity where workloads must access resources in more than one cloud. Keep the trust relationship explicit, reviewed, and revocable when the environment, supplier, or workload role changes.
• Treat transport security as incomplete authorisation Use service meshes and PKI to protect workload communication, then add policy-based checks for request context, namespace, posture, and destination sensitivity. A secure channel does not mean the access decision was appropriate.
• Prioritise sensitive production paths first Start with the workloads that create the most blast radius if compromised: production databases, third-party API integrations, and CI/CD systems that deploy infrastructure. Those are the places where runtime identity controls deliver measurable reduction fastest.
• Review machine identity lifecycle alongside credential lifecycle Include provisioning, rotation, revocation, and offboarding for every workload that uses a credential, token, or certificate. If the workload still exists but the business need has changed, the entitlement should be revalidated as part of the same lifecycle process.

Key takeaways

• Vaults reduce credential sprawl, but they do not by themselves solve who may request access at runtime.
• The scale of exposed secrets shows that static credentials remain a live operational risk, especially as AI and multicloud expand the attack surface.
• Practitioners should align secrets storage, federated identity, and policy-based runtime access as one governance model rather than separate controls.

Key terms

• Secret Zero: The first credential that lets a workload authenticate to a secrets store or other protected system. It is the hidden root of trust in many vault-based designs. If it is compromised, the attacker can often reach every credential that the vault was meant to protect.
• Workload Identity: A cryptographically verifiable identity assigned to a machine workload, service, or process. It lets the workload prove who it is at runtime without relying on a shared static secret. In mature programmes, workload identity becomes the basis for short-lived, scoped access decisions.
• OIDC Federation: A method of exchanging signed identity assertions between trust domains so a workload can obtain access without sharing a long-lived credential. It is especially useful across cloud boundaries, where each provider has its own native identity model and policy syntax.
• Runtime Credential Trust Debt: The accumulated governance risk that appears when credentials remain valid beyond the context that justified them. In practice, it is the gap between how long an entitlement lasts and how quickly the underlying workload, vendor, or business need changes.

Deepen your knowledge

Workload IAM, OIDC federation, and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for multicloud workloads or AI-connected systems, it is worth exploring.

This post draws on content published by Aembit: workload IAM versus secrets management and related NHI access patterns. Read the original.