Dynamic authorization is replacing static secrets in cloud-native IAM

At a glance

What this is: This is an analysis of why static secrets fail in cloud-native environments and how dynamic authorization replaces stored credentials with runtime trust decisions.

Why it matters: It matters because IAM, NHI and platform teams need controls that govern workloads at access time, not just rotate credentials after exposure.

👉 Read Aembit's analysis of static secrets and dynamic authorization

Context

Static secrets are credentials that stay valid until someone changes them. In cloud-native environments, that model breaks down because applications spread across microservices, pipelines and environments, multiplying the places where keys, tokens and passwords can be copied, cached or forgotten.

The IAM issue is not just secret hygiene. It is the governance assumption that possession of a stored credential is a stable basis for trust. Dynamic authorization replaces that assumption with workload identity verification, policy evaluation and ephemeral access decisions at runtime.

Key questions

Q: What breaks when static secrets are used in cloud-native environments?

A: Static secrets break down when the same credential is reused across many services, repositories and pipelines. The result is secret sprawl, weak attribution and a wide blast radius if one value is exposed. Cloud-native teams then spend more time rotating and tracking credentials than governing access, which is a structural identity problem, not just a hygiene issue.

Q: Why do service accounts and API keys create more risk than runtime-issued tokens?

A: Service accounts and API keys often persist long enough to be copied, reused and forgotten. Runtime-issued tokens narrow that exposure by making access task-scoped and time-bound. That reduces the chance of lateral movement and limits what an attacker can do if a token is intercepted, especially in distributed microservice environments.

Q: How do security teams know whether dynamic authorization is working?

A: Look for fewer persistent credentials, shorter token lifetimes, and audit records that show workload identity, resource, policy outcome and context for each request. If teams still rely on broad allow rules, manual exceptions or hidden bootstrap secrets, the programme has not באמת moved from secret management to runtime trust.

Q: How should organisations reduce reliance on secret zero?

A: They should replace bootstrap credentials with cryptographic proof from the runtime environment, then use policy to broker ephemeral access. If a system still needs a stored secret to fetch another secret, the trust chain remains recursive and fragile. The goal is to remove the starting credential entirely, not just protect it better.

Technical breakdown

Secret sprawl and the limits of rotated secrets

Static secrets create a durable attack surface because the same credential is reused across systems until someone rotates it. Rotated secrets shorten that lifetime, but they still depend on possession-based trust and still leave credentials stored somewhere between rotations. In distributed environments, that means every repo, pipeline and config file becomes a potential exposure point. The real architectural weakness is not just long-lived secrets. It is the decision to keep a reusable credential at all when workloads can be authenticated in other ways.

Practical implication: treat rotation as a mitigation, not the end state, and map where persistent credentials still exist.

Environment attestation and workload identity

Dynamic authorization begins by proving that a workload is running where it says it is. Environment attestation uses cryptographic signals from Kubernetes, cloud instances or container metadata to establish workload identity without first presenting a stored secret. That identity proof is then consumed by a policy engine that evaluates context such as namespace, posture, resource sensitivity and time. The result is not static permission assignment but a decision made at access time, based on current conditions rather than provisioning-time assumptions.

Practical implication: anchor access to verified workload identity sources before expanding policy scope.

Just-in-time token brokering and secret zero removal

A just-in-time credential broker issues short-lived tokens only after policy approval, so the workload receives access for a specific operation and nothing more. This removes the secret zero paradox, where one credential is required to fetch the next credential. It also improves auditability because every access decision can record who or what requested access, what resource was involved and whether policy allowed it. The architecture is strongest when token lifetimes are short and issuance is tied to verified runtime context.

Practical implication: design brokered access so that no persistent bootstrap secret is needed to start the trust chain.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Static secret governance fails when trust is treated as a stored object instead of a runtime decision. The cloud-native model assumes possession-based authentication can remain stable across repositories, pipelines and microservices. That assumption breaks when credentials are duplicated faster than they are reviewed, because governance becomes a record-keeping exercise instead of a control point. The implication is that identity programmes must stop treating secret storage as the centre of trust.

Dynamic authorization is really a shift from credential management to workload proof. Environmental attestation, policy evaluation and ephemeral token issuance move the security decision to the moment of access. That is consistent with OWASP Non-Human Identity Top 10 concerns around overexposed credentials and over-broad access, because the workload proves itself each time rather than carrying a reusable secret. Practitioners should read this as a control architecture change, not a feature upgrade.

Secret zero is a named failure mode, not just an implementation detail. The recursive problem of needing a secret to obtain secrets was designed for systems where bootstrap access was rare and manually controlled. That assumption fails when services scale horizontally and provisioning is continuous, because the bootstrap secret becomes the first durable weakness in the chain. The implication is that access governance must eliminate the premise that every trust chain needs a stored starting credential.

Identity blast radius: the smaller the credential lifetime and scope, the less damage a single compromise can do. Static secrets enlarge blast radius because the same artifact often authenticates multiple requests over long periods. Dynamic authorization compresses that window by issuing task-scoped credentials with narrow context. For practitioners, the important question is not whether a token exists, but how much of the environment it can still touch if it is copied.

Cloud-native IAM now needs to govern both human-requested access and machine-executed access patterns. The same lifecycle discipline that applies to human entitlements also applies to workload credentials, but the enforcement point differs. Static secrets depend on after-the-fact rotation and review, while dynamic authorization shifts control to issuance and context. Teams should treat workload identity as part of the broader identity fabric, not as an infrastructure side topic.

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.
• 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 pattern makes the Guide to the Secret Sprawl Challenge the natural next step for teams replacing stored secrets with runtime access controls.

What this signals

Identity blast radius: cloud-native teams should now treat every persistent credential as an exposure multiplier, because one leaked secret can authenticate many requests across many services. The practical shift is toward ephemeral access and tighter scoping, not larger secret inventories.

With 64% of valid secrets leaked in 2022 still exploitable today, according to the State of Secrets Sprawl 2026, the issue is not detection alone. Teams need revocation, runtime proof and auditability that survive fast-moving deployment cycles.

The governance question is no longer whether a workload can be trusted at provisioning time, but whether it can prove itself at the moment of access. That is why dynamic authorization belongs inside the broader identity architecture, alongside zero trust and workload lifecycle controls.

For practitioners

• Inventory persistent credentials by workload path Map where API keys, database passwords and shared tokens exist across repos, CI/CD systems, config files and service meshes. Prioritise the workloads that access production data or third-party APIs first, because those paths create the highest secret exposure density.
• Establish verified workload identity sources Use cloud instance identity, Kubernetes service account tokens or signed metadata as the starting point for authentication. Make sure the identity source is reliable before replacing stored credentials, or policy enforcement will simply move the failure elsewhere.
• Introduce ephemeral tokens for scoped operations Issue short-lived credentials only after policy approval and bind them to a specific resource, namespace or task. Keep token lifetimes short enough that copying them does not create a reusable access path.
• Test policy latency and failure handling before rollout Measure how long authorization decisions take, whether clock skew or metadata outages block token issuance, and what emergency access looks like if the policy engine is unavailable. Validate in staging before production cutover.

Key takeaways

• Static secrets create a durable cloud-native exposure pattern because the same credential is often reused across many services and deployment paths.
• The evidence points to scale, not edge cases, with millions of hardcoded secrets appearing in public code and AI-related leaks accelerating sharply.
• The practical move is to replace stored credentials with runtime proof, ephemeral tokens and policy checks that shrink blast radius.

Key terms

• Static Secret: A static secret is a credential that remains valid until it is manually changed or rotated. In cloud-native systems, it often lives in code, configuration, or pipeline storage, which makes reuse and exposure more likely across many services.
• Dynamic Authorization: Dynamic authorization is an access model that makes the trust decision at request time using current identity and context. It replaces reusable stored credentials with short-lived, policy-scoped tokens issued only after the workload proves itself.
• Environment Attestation: Environment attestation is cryptographic proof that a workload is running in a trusted runtime such as a verified pod, instance, or container. It gives policy engines a basis for issuing access without first relying on a stored bootstrap secret.
• Secret Zero: Secret zero is the first credential needed to obtain other credentials, creating a recursive trust problem. In mature identity programmes, it is a design flaw because the initial bootstrap secret becomes the weakest and most durable link in the chain.

Deepen your knowledge

Static secrets, workload identity and dynamic authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing stored credentials with runtime access decisions, it is worth exploring.

This post draws on content published by Aembit: Static secrets, rotated secrets and dynamic authorization. Read the original.