Runtime authorization for non-human identities in cloud-native systems

At a glance

What this is: This is an analysis of why non-human identity growth is forcing security teams toward runtime, context-aware authorization for workloads, APIs, and automated jobs.

Why it matters: It matters because IAM, PAM, and zero trust programmes now have to govern machine identities that are short-lived, highly distributed, and often more privileged than human accounts.

By the numbers:

• Industry reports peg the ratio of machine-to-human identities anywhere from 45:1 to 80:1.

👉 Read Cerbos's analysis of runtime authorisation for non-human identities

Context

Non-human identity sprawl is now a core IAM problem, not a niche cloud engineering issue. Service accounts, API tokens, CI/CD jobs, containers, and serverless functions all need credentials, but they often exist for far shorter periods than the systems that manage them. That mismatch is where static access models start to fail.

The deeper issue is governance, not just authentication. A workload can prove who it is with a valid token and still be far outside the access boundary it should operate within. For IAM teams, that means the old assumption that identity validation is enough has to give way to runtime authorization and zero standing privilege.

The lifecycle problem is familiar in shape but harsher in scale. When non-human identities are created manually, left behind after a pipeline or service is retired, or granted broad rights for convenience, the result is standing access that outlives the workload itself.

Key questions

Q: How should security teams govern non-human identities in cloud-native environments?

A: They should treat non-human identities as first-class principals with their own lifecycle, ownership, scope, and expiry. That means combining strong credential hygiene with request-time authorisation, so a valid token is not enough on its own. The goal is to align access with the workload’s actual runtime context, not with a permanent role assignment.

Q: Why do static roles fail for ephemeral workloads?

A: Static roles fail because they assume access is stable long enough to be reviewed and reused, while ephemeral workloads may exist only briefly and then disappear. When the workload changes faster than the role model, permissions become either too broad or too persistent. That creates standing privilege and expands the blast radius of a compromised credential.

Q: How do organisations know if non-human identity controls are working?

A: They should look for fewer long-lived secrets, shorter credential lifetimes, and fewer orphaned accounts after workloads are decommissioned. Effective controls also produce denials when a valid credential is used in the wrong context, which shows that runtime policy is actually constraining access rather than merely recording it.

Q: What should teams do when CI/CD credentials outlive the pipeline?

A: They should treat that as a lifecycle failure, not an isolated secret issue. The credential should be revoked, the pipeline ownership reviewed, and future issuance tied to an automated teardown path. Persistent access after the job ends is exactly the pattern that turns build systems into hidden attack surfaces.

Technical breakdown

Why static roles break down for non-human identities

Static roles work when the access pattern is stable, predictable, and tied to a person or long-lived application. Non-human identities are different because they are often created on demand, used briefly, and then disappear, while the permissions attached to them remain. That creates a structural mismatch between entitlement lifetime and workload lifetime. In cloud-native systems, this mismatch is amplified by microservices, CI jobs, and serverless functions that need access in bursts rather than in fixed sessions. Once a workload can appear, act, and vanish quickly, pre-assigned privileges become too blunt to express safe intent.

Practical implication: review where role assignments assume long-lived principals and replace those patterns with tightly scoped, time-bound access.

Runtime contextual authorization in zero trust

Runtime contextual authorization evaluates each request at the moment it is made, using attributes such as workload identity, environment, user context, and time. This is different from admin-time access, where broad permissions are attached once and then assumed to remain appropriate. It is also more precise than authentication-time scoping, because a token can still be valid even when the request is no longer safe. In zero trust terms, the decision is not whether the identity is real, but whether the specific action is acceptable in the current context. That is what allows policy engines to block valid credentials being used in an unexpected place or by an unexpected service.

Practical implication: move sensitive authorisation decisions closer to the request path so policy can evaluate context before access is granted.

Ephemeral credentials and zero standing privilege

Ephemeral credentials are designed to expire with the workload or transaction they support, which reduces the value of stolen secrets and limits credential reuse. Zero standing privilege pushes the model further by removing persistent access altogether and issuing rights only when they are needed. For non-human identities, this is especially important because unused keys and long-lived tokens often become orphaned access paths. A credential that outlives its workload is not just untidy administration, it is residual authority waiting to be found. In practice, ephemeral access only works when issuance, scoping, and revocation are automated and tied to the actual lifecycle of the workload.

Practical implication: treat every non-human credential as a lifecycle object with an expiry, an owner, and an automated revocation path.

Threat narrative

Attacker objective: The attacker wants to turn one valid machine credential into broad, durable access across cloud-native services and data.

1. Entry begins when a workload or CI pipeline receives a valid credential that was issued too broadly or left behind after the original use case changed.
2. Escalation occurs when that identity is trusted for more than authentication and can call APIs, services, or data paths that exceed its intended scope.
3. Impact follows when the exposed credential is reused for lateral movement, unauthorized data access, or automation abuse across cloud services.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 entitlement models are the wrong abstraction for ephemeral non-human identities. The article shows that workloads, CI jobs, and serverless functions now appear and disappear faster than traditional IAM assignment cycles can follow. That means role design based on durable principals no longer matches how access is actually consumed. The practitioner implication is that entitlement strategy has to shift from provisioning-time assumptions to request-time governance.

Runtime authorization is becoming the control plane for non-human identity risk. Authentication confirms identity, but it does not explain whether the current action is safe, necessary, or appropriately scoped. In cloud-native environments, that distinction matters because the same token may be valid across many services while only a subset of those calls is legitimate. The implication is that IAM teams need policy decisions that understand workload context, not just token validity.

Zero standing privilege is the right governance goal, but only if credential lifetime follows workload lifetime. The article makes clear that orphaned service keys and manually managed secrets create residual authority long after the business need has ended. That is not just a hygiene problem, it is access persistence by default. Practitioners should treat every long-lived machine credential as evidence that the governance model has drifted away from the workload lifecycle.

Identity blast radius is now a design variable, not an incident response afterthought. Once a machine identity can move through multiple APIs, clusters, and SaaS tools, the security question shifts from whether access exists to how far that access can travel. The article’s runtime-policy model points to a narrower blast radius through contextual checks at each request. The implication is that organisations must design for containment across the full delegation chain, not merely for successful authentication.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, 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.
• For teams governing workload identity and secret sprawl, the Guide to the Secret Sprawl Challenge helps translate leak detection into revocation and containment.

What this signals

Ephemeral access only works when lifecycle controls catch up to workload churn. In many environments, the governance problem is not lack of authentication but lack of timely teardown. That is why machine identity programmes need to be built around expiry, ownership, and automated revocation rather than around static account administration.

With 88.5% of organisations acknowledging their non-human IAM practices lag behind or merely match human IAM, the control gap is not subtle. Teams should expect more pressure to prove that a request-time policy model can actually contain blast radius across services, clusters, and SaaS integrations.

For practitioners

• Map non-human identity lifecycles Inventory service accounts, API keys, CI jobs, and workload identities by owner, purpose, creation date, and revocation path. Identify where access persists after the workload is retired or replaced, then tie each identity to an explicit offboarding workflow.
• Replace static privilege with request-time policy Move sensitive authorisation checks to runtime so each request can be evaluated against workload, environment, and user context. Use policy decisions to deny valid credentials when the call comes from the wrong service, namespace, or execution path.
• Automate credential expiry and revocation Issue short-lived tokens for CI/CD jobs, serverless functions, and service integrations, and ensure they are revoked when the task ends. Make token lifetime match the workload lifetime instead of allowing secrets to remain valid indefinitely.
• Eliminate manual secret handling Remove copy-and-paste key creation and secret placement from cloud consoles and build pipelines. Use infrastructure-as-code or orchestration so every new non-human identity is tracked, scoped, and torn down consistently.

Key takeaways

• Non-human identity growth has outpaced the static IAM models that were designed for human users and long-lived accounts.
• The operational risk is not only secret exposure, but the persistence of access after the workload or pipeline no longer needs it.
• Runtime authorisation, short-lived credentials, and automated revocation are the controls that most directly reduce machine-identity blast radius.

Key terms

• Non-Human Identity: A non-human identity is any machine or workload credential used by software rather than a person. It includes service accounts, API tokens, certificates, and CI/CD jobs. The governance challenge is that these identities often scale faster than their lifecycle controls, creating persistent access risk.
• Runtime Authorization: Runtime authorization is the practice of deciding access at the moment a request is made, using current context rather than only the identity’s static role. It is essential for ephemeral workloads because the same credential can be safe in one context and unsafe in another.
• Zero Standing Privilege: Zero standing privilege means no identity keeps persistent access by default. Privileges are issued only when needed and should expire when the task ends. For machine identities, this reduces the chance that abandoned keys or lingering service accounts can be reused by an attacker.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token that exists only for the duration of a workload, session, or transaction. It limits exposure if stolen, but only when issuance and revocation are automated and aligned to the workload lifecycle.

Deepen your knowledge

Runtime authorisation and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from static roles to request-time policy, the course is a practical next step.

This post draws on content published by Cerbos: runtime authorization for non-human identities in cloud-native systems. Read the original.