Bearer tokens need runtime enforcement in modern workload security

At a glance

What this is: This is an analysis of why valid bearer tokens and workload credentials are no longer sufficient proof of runtime legitimacy.

Why it matters: It matters because IAM teams now have to govern non-human access as a live execution problem, not just a credential issuance problem, across workload, federated, and human-facing identity programmes.

👉 Read Riptides' analysis of bearer tokens and runtime enforcement in workload security

Context

Bearer tokens, JWTs, SPIFFE identities, and short-lived certificates all improve how workloads authenticate, but they do not prove that the current actor is still legitimate when access is exercised. The core governance gap is simple: possession of a valid credential is being treated as equivalent to runtime trust, even though modern infrastructure changes faster than the trust decision can keep up.

That creates a non-human identity problem as much as an architecture problem. Once credentials are transferable across APIs, clouds, and federated boundaries, the question is no longer only who obtained the token, but whether the workload context behind it still matches the original authorisation decision.

Key questions

Q: How should security teams handle bearer tokens that remain valid outside their original context?

A: Treat token validity as necessary but not sufficient. Security teams should require a second control that checks the current workload, process, or session context at the moment of use. If a token can be replayed after the original actor changes, possession-based trust is too weak for that path. A runtime-bound policy model is the safer design.

Q: Why do workload identities create new risk when used across clouds and APIs?

A: Because workload identities are transferable, their trust value can outlive the runtime conditions that made them safe. Across clouds and APIs, the credential may still be valid while the original process, container, or connection path has changed. That expands the blast radius of any exposed token and makes point-of-use enforcement more important than issuance alone.

Q: What breaks when authorisation depends only on a valid credential?

A: The system stops distinguishing between the legitimate workload that first obtained the token and any later actor that reuses it. That breaks the link between identity and runtime state, which is exactly where replay, process compromise, and lateral movement become dangerous. The control fails because it is checking proof of prior authentication, not current legitimacy.

Q: How can teams reduce the risk of replayed bearer tokens in federated environments?

A: Use runtime enforcement that checks the current workload at the point of connection, then limit how far trust is extended across boundaries. Teams should also review where identity propagation depends on portable artefacts alone. The goal is to stop treating a previously valid credential as permanent proof of access.

Technical breakdown

Why possession-based trust fails at runtime

Bearer tokens and similar credentials are proof of prior authentication, not proof of current legitimacy. In a static environment that shortcut was often tolerable because workloads changed slowly and access paths were predictable. In modern infrastructure, the credential can remain cryptographically valid while the process, container, or replaying actor has changed. That is why possession-based trust degrades into a brittle proxy for authorisation when runtime state is moving faster than the trust model.

Practical implication: Practitioners should separate credential validity from runtime authorisation and treat them as different control points.

Runtime enforcement at the point of connection

Runtime enforcement binds identity and policy to the actual running workload at the moment a connection is made. Instead of trusting a token because it was issued earlier, the control evaluates which process is connecting, where it is connecting from, and whether the execution context still satisfies policy. This is materially different from proxy-layer or adjacent policy evaluation that only checks an artefact passed into the flow. The architecture shifts the trust decision from possession to live execution state.

Practical implication: Security teams should favour controls that can validate the initiating workload at connection time, not just at issuance time.

Federation expands trust, but not legitimacy

Federation and workload identity frameworks make it easier to propagate trust across organizational and cloud boundaries, but they do not automatically solve runtime legitimacy. A signed token can travel farther and be reused more widely than the context that created it. That means federation increases the value of strong enforcement, but it also increases the blast radius when enforcement is detached from execution. The result is a broader trust surface with the same underlying assumption problem.

Practical implication: Teams should review federation designs for where trust is extended without an equivalent runtime check.

Threat narrative

Attacker objective: The attacker aims to turn a legitimate credential into durable access that survives beyond the original runtime context.

1. Entry occurs when a valid bearer token, JWT, or workload credential is exposed, replayed, or reused outside the original runtime context.
2. Escalation follows when infrastructure continues to trust the credential even though the current actor, process, or execution state has changed.
3. Impact is broader access than intended because the system authorises possession of the token rather than the legitimacy of the live workload.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• 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

Possession-based trust is no longer a safe authorisation premise for modern workload identity. A valid credential proves that authentication succeeded earlier, not that the current actor should still be trusted now. That premise was designed for slower, more static environments. It fails when credentials are transferable, workloads are ephemeral, and runtime state changes faster than the trust decision.

Runtime legitimacy is the missing governance concept in workload security. The article points to a control gap that many identity programmes still leave open: validating the artefact instead of the actor. This is the identity blast radius problem in practice, where a single valid token can outlive the context that made it trustworthy. Practitioners should treat that as an architectural boundary issue, not a tuning issue.

Federation without point-of-use enforcement creates trust extension without trust confirmation. Cross-boundary identity propagation is useful, but it does not prove that the current session still deserves access. The gap is not that federation is broken, but that many programmes stop at issuance and never close the loop at execution. For NHI governance, that means access control is still too detached from runtime behaviour.

Static credential validity and runtime legitimacy are different control problems, and treating them as the same is a category error. Traditional IAM assumptions often collapse once identity becomes transferable across services, clusters, and clouds. OWASP NHI and Zero Trust thinking both point to the same conclusion: the control plane must stop assuming a previously valid token remains sufficient throughout the session. Practitioners should reframe authorisation around live context, not just signed proof.

Bearer token enforcement is becoming a lifecycle issue as much as an access issue. Once credentials can be replayed after issuance, the critical question becomes how long the trust relationship is allowed to persist and under what runtime conditions it is revalidated. That connects workload identity, secrets governance, and access review into one problem space. Teams should design governance for the moment of use, not only the moment of issue.

From our research:

• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
• From our research: 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• From our research: The case for runtime-bound identity is stronger when organisations recognise that a valid credential is not the same thing as a trustworthy current actor, a pattern explored in Ultimate Guide to NHIs.

What this signals

Runtime legitimacy will become a core NHI governance requirement, not a niche architecture preference. As workloads become more ephemeral and more federated, teams will need controls that evaluate the current actor at the moment of use rather than trusting the credential that got it there. This is where possession-based IAM starts to fail as a governance model, especially for cross-cloud and API-heavy environments.

Identity blast radius is the practical metric that matters here. If a replayed token can still traverse proxies, service meshes, and adjacent policy layers, the real issue is not token lifetime alone but how far trust can travel before it is rechecked. Organisations that already struggle with non-human IAM maturity will feel this gap first, because their runtime controls and inventory discipline are usually the weakest links.

For practitioners

• Separate issuance from runtime authorisation Map where your current controls only confirm that a credential was issued correctly and where they also validate the live workload at connection time. Prioritise the paths where transferable tokens can be reused across services or environments.
• Inventory trust-extension points in federated flows Identify where identity crosses cloud, cluster, or organizational boundaries without a second runtime check. Pay special attention to proxies, SDKs, and service meshes that validate tokens but do not verify the current process state.

Key takeaways

• Modern workload security cannot rely on a valid credential alone because possession does not prove the current actor is legitimate.
• The scale of the problem is already visible in NHI research, where 59.8% of organisations want dynamic ephemeral credentials and 88.5% say their non-human IAM lags human IAM.
• Teams should shift from issuance-centric controls to runtime enforcement that revalidates the workload at the point of connection.

Key terms

• Bearer Token: A bearer token is a transferable credential that grants access to a resource to whoever presents it. In NHI environments, that portability is the risk: the token can remain valid after the workload context changes, so possession alone is not a reliable authorisation signal.
• Runtime Enforcement: Runtime enforcement is the practice of evaluating access at the moment a workload attempts an action or connection, using the live execution context rather than only the issued credential. It closes the gap between authentication and use, which is where replay and context drift become dangerous.
• Runtime Legitimacy: Runtime legitimacy is the question of whether the current actor presenting a valid credential still deserves access right now. It goes beyond token validity and focuses on process state, connection context, and whether the original trust assumption still holds.
• Trust Extension: Trust extension is the spreading of identity trust across clouds, services, proxies, or federated domains. It is useful for interoperability, but it becomes risky when the expanded trust path is not matched by equivalent runtime checks, because the credential can travel farther than its original context.

Deepen your knowledge

Bearer token enforcement and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a runtime-bound governance model for modern infrastructure, it is worth exploring.

This post draws on content published by Riptides: Bearer Token Meets Runtime Enforcement. Read the original.