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

At a glance

What this is: This is a Cerbos analysis of why non-human identities in cloud-native systems need runtime authorization, with the key finding that static permissions and long-lived credentials do not keep pace with ephemeral workloads.

Why it matters: It matters because IAM, PAM, and NHI programmes have to decide access at request time for services, jobs, and agents, not just provision identities once and hope their roles stay safe.

By the numbers:

• Non-human identities now outnumber human identities by 45:1 to 80:1 in many cloud-native environments.

Context

Non-human identity runtime authorization is the problem of deciding what a service, token, job, or workload may do at the moment of each request. In cloud-native systems, that matters because identities are created, used, and retired far faster than human accounts, while the surrounding context keeps changing.

The governance gap is that many teams still assign access at creation time and then treat a valid credential as sufficient for every later action. That breaks down for ephemeral workloads, CI/CD jobs, and service accounts because identity alone does not describe intent, runtime location, user context, or current risk.

Cerbos frames this around cloud-native architectures where microservices, containers, and automated jobs all act as non-human identities. The article’s starting point is typical for modern cloud programmes: the more distributed and ephemeral the environment becomes, the less useful static authorization becomes.

Key questions

Q: What breaks when non-human identities keep static permissions in cloud-native systems?

A: Static permissions break when the workload is short-lived, the context changes, and the credential keeps working long after the task should have ended. The result is standing privilege for a machine identity, which widens blast radius and makes least privilege mostly theoretical. Runtime authorization closes that gap by deciding each request in context, not at provisioning time.

Q: Why do valid service account tokens still create security risk?

A: A valid token only proves that the requester has a credential, not that the current action is appropriate. If the same token can be replayed from the wrong service, namespace, or workflow, an attacker or rogue process can move from authentication to unauthorized activity very quickly. That is why contextual checks matter more than token validity alone.

Q: How can organisations tell whether runtime authorization is actually working?

A: Look for three signs: decisions happen fast enough to stay inline, policies use live context instead of stale claims, and every allow or deny produces an auditable record. If teams cannot explain a specific decision after the fact, or if applications bypass the control because it is too slow, the runtime layer is not functioning as intended.

Q: Should organisations use the same governance model for CI/CD identities as for service accounts?

A: Yes, because both are non-human identities performing production work under delegated privilege. The governance mechanics are nearly identical: ownership, scope, expiry, review, and revocation. The difference is that CI/CD identities are often more exposed to supply chain and log-based theft, so their controls should usually be stricter.

Technical breakdown

Why admin-time permissions fail for ephemeral workloads

Admin-time authorization means deciding access when the identity is created, often by attaching a role or scope that persists for the lifetime of the account or token. That model assumes the workload’s purpose stays stable, but cloud-native systems do not. A container may exist for minutes, a CI job for seconds, and a service may only need one action on one resource. Once permissions are baked in at provisioning time, they can outlive the task, become overbroad, or remain active after the workload disappears. The technical problem is not just stale access. It is that the authorization decision is detached from the request that actually matters.

Practical implication: Treat provisioning-time roles as insufficient for ephemeral workloads and move the decisive control to request-time policy checks.

How contextual authorization changes the decision model

Contextual authorization evaluates the request using attributes such as workload identity, user identity, environment, time, namespace, and risk signal. Instead of asking only whether a token is valid, the policy engine asks whether this specific call is appropriate right now. That is a major shift for NHI governance because the identity becomes one input to the decision, not the decision itself. In practice, it allows a single service account or token to be constrained differently depending on where it runs, who triggered it, and what it is trying to do. That is the mechanism behind least privilege in dynamic systems.

Practical implication: Use policy decisions that combine identity, environment, and request context instead of relying on token validity alone.

Why runtime policy matters more than static scopes or long-lived keys

Static scopes and long-lived keys are coarse controls. They may reduce exposure compared with unrestricted access, but they still assume the credential can be trusted for an extended period and across multiple operations. Runtime policy closes that gap by checking every action as it happens, so a credential that is valid in one context can be denied in another. This is especially important when workloads act on behalf of users or chain into other services, because compromise of one credential can otherwise fan out into broader access. The architecture is essentially zero trust applied to machine actions.

Practical implication: Limit credential lifetime and scope, then enforce a policy check on each sensitive action rather than trusting the token for its full validity window.

Threat narrative

Attacker objective: Exploit a valid non-human credential to perform actions beyond the workload’s intended scope and expand access across cloud-native services.

1. Entry occurs when a service account, API token, or CI/CD credential is issued for a workload and later reused in a different context than intended.
2. Escalation happens when a valid credential is accepted without checking whether the request matches the expected workload, namespace, user, or task context.
3. Impact follows when the credential is used to call services or perform actions outside its intended runtime boundaries, turning one identity into broad cloud access.

Breaches seen in the wild

• 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

Runtime authorization is the control that cloud-native identity models were missing: the article shows that a valid credential is not the same thing as a valid action. In distributed systems, identity proves origin, while policy must prove legitimacy for the specific request. That distinction is now central to NHI governance, because static authorization collapses when workloads are ephemeral and context changes faster than provisioning cycles. Practitioners should treat request-time policy as the primary control plane for machine access.

Standing privilege is the wrong baseline for service accounts: service and workload identities were designed for execution, not persistence. When a credential outlives the job, the account becomes an implicit standing privilege with no natural offboarding point. That is not just a hygiene issue. It is a governance failure that creates orphaned access, weakens zero standing privilege, and makes NHI lifecycle management inseparable from authorization design. Practitioners need lifecycle ownership for every non-human principal, not just inventory.

Ephemeral workload identity needs ephemeral authorization, not just ephemeral secrets: short-lived tokens help, but they do not solve the underlying question of what the workload may do while the token is valid. The article’s strongest point is that authorization has to move from issuance time to runtime, because cloud-native systems change too quickly for static roles to remain accurate. The practical implication is that NHI programmes must govern decision points, not only credential length.

Zero trust for non-human identities is really a context problem: the traditional premise that a credential can be trusted across multiple actions no longer holds when services are spun up on demand and act on behalf of users. That assumption fails because workload context is part of the security decision, not a side condition. The implication is that identity governance teams must measure whether policy can see the request context, not just whether authentication succeeds.

Per-transaction identity is the right named control concept for this shift: the article points toward a model where access is scoped to a single operation or narrow transaction window. That concept matters because it aligns authorization with actual task duration instead of with an abstract account lifetime. Practitioners should regard per-transaction identity as the operational expression of least privilege for NHIs in ephemeral cloud systems.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Per-transaction identity: cloud-native teams should expect authorization to move from a one-time setup choice to a request-time decision, because ephemeral workloads do not preserve a stable enough state for static entitlements to remain trustworthy. That shift should be reflected in how security architecture reviews evaluate service accounts, CI/CD identities, and delegated workflows.

Runtime authorization changes the operating model for NHI governance because the question is no longer only whether a credential exists, but whether the action is still allowed in the current context. Teams that keep identity inventory but do not instrument request-time policy will retain visibility without control.

For practitioners, the practical signal is simple: if a workload can still do sensitive actions after its intended runtime context has changed, the authorization model is too static for the environment it is protecting.

For practitioners

• Define request-time authorization as the primary control Move high-risk service and workload decisions out of static roles and into policy checks that evaluate the request context at runtime.
• Inventory every non-human principal with an owner Track service accounts, API tokens, and CI/CD credentials as governed identities with named owners, lifecycle state, and offboarding triggers.
• Shorten credential lifetime to match workload duration Set token and secret expiry to the shortest practical interval for the job or service, then remove any credential that outlives the workload.
• Add contextual checks for each sensitive action Use environment, user, workload identity, and request purpose to decide whether a call should proceed, especially for privileged or cross-service operations.
• Segment policy for ephemeral and user-delegated flows Treat CI jobs, serverless functions, and AI-style delegated workflows as separate policy cases so one broad service account cannot stand in for all of them.

Key takeaways

• Non-human identities in cloud-native systems need request-time authorization because static roles do not track ephemeral workload context.
• The article’s core finding is that authentication alone is not enough for machine access, especially when credentials are reused across dynamic services.
• Practitioners should move toward policy decisions that combine workload identity, environment, and request context for every sensitive action.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Ephemeral Workload Identity: Ephemeral workload identity is a short-lived credential issued to a container, service, or agent for a specific task window. It reduces exposure by avoiding durable secrets on disk or in environment variables, which limits what an attacker can steal if runtime code is compromised.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Contextual authorization: A policy approach that evaluates access using real-time signals such as task, location, device posture, and time. It is more precise than static role assignment because it matches how autonomous agents operate, where intent and risk can change across a single workflow.

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 building or maturing an IAM programme, it is worth exploring.