Bearer Token Meets Runtime Enforcement

Modern infrastructure has become very good at issuing credentials. JWTs, SPIFFE identities, federated trust, workload identity providers, and short-lived certificates have significantly improved how systems authenticate workloads and exchange trust information across increasingly dynamic environments.

These are important advances, but they also introduced an assumption that deserves closer examination.

Many systems implicitly treat possession of a valid credential as sufficient proof for access. If a token is correctly signed, issued by a trusted authority, unexpired, and presented successfully, the infrastructure often assumes the current actor presenting it should be trusted.

That assumption is increasingly breaking down.

A valid token proves that somebody authenticated successfully at some earlier point in time. It does not necessarily prove that the current actor presenting it is still legitimate, that the workload context remains unchanged, or that the current action should actually be allowed.

This distinction matters far more in modern infrastructure than it did in earlier generations of systems.

Historically, possession-based trust models worked reasonably well because environments were more static. Workloads lived longer, infrastructure changed more slowly, and credentials moved through systems less pervasively. Authentication and runtime behavior were often closely coupled simply because the environments themselves were comparatively predictable.

Modern infrastructure looks very different. Workloads are ephemeral by default, APIs continuously communicate with other APIs, identities cross organizational and cloud boundaries, and credentials move automatically between systems at machine speed. Runtime context changes constantly, yet many systems still make authorization decisions primarily based on possession of transferable artifacts.

This is one of the reasons credential theft remains so effective even in highly modern environments.

The problem is usually not that the credential itself is invalid. In many incidents, the credential remains perfectly legitimate from a cryptographic perspective. It may be correctly signed, issued by a trusted authority, short-lived, and fully compliant with modern identity standards. The failure occurs because token validity alone says very little about the legitimacy of the current actor presenting it.

The recent Vercel security incident is a useful example of this broader pattern. Although the specific technical details vary across environments, the underlying issue remains familiar: once valid credentials are exposed, replayed, or reused outside their original runtime context, infrastructure built primarily around possession-based trust tends to treat the actor presenting them as legitimate.

At that point, the infrastructure gradually loses the ability to distinguish between the original workload, a compromised process, malware operating within the workload, or an attacker replaying credentials elsewhere. The infrastructure validates the credential itself, but not necessarily the runtime legitimacy of the current actor using it.

This distinction becomes increasingly important as the industry shifts from workload identity toward workload access management. The realization that authentication alone is insufficient is directionally correct, but many modern access systems still fundamentally rely on transferable credentials underneath increasingly dynamic policy systems.

The architecture typically evolves into something resembling:

• authenticate workload
• issue credential
• attach policies
• evaluate access dynamically

While this improves flexibility and enables richer authorization decisions, it does not fully solve the core problem if access decisions remain detached from runtime execution itself.

The critical question is no longer whether a workload authenticated successfully at some earlier point in time. The more important question is whether the current runtime context still justifies access at the exact moment an action occurs.

Those are very different guarantees.

Many authorization systems evaluate policies in components that operate adjacent to execution rather than directly observing it. Proxies, SDKs, service meshes, and centralized policy engines are all capable of coordinating sophisticated authorization workflows, but they often do not directly observe the thing that matters most: which process is actually establishing the connection right now, under what runtime conditions, and whether the execution context still matches the original trust assumptions.

Once runtime context becomes detached from credential validation, authorization gradually degrades back into possession-based trust again.

The infrastructure is no longer continuously validating the actual workload, execution state, or legitimacy of the current action. Instead, it validates possession of something issued earlier and assumes the original trust relationship still holds.

This problem becomes even more pronounced in federated environments. As discussed previously in SPIFFE Identity Federation: Extending Trust Across Boundaries, federation solves trust propagation but does not inherently solve runtime enforcement. Extending trust across boundaries without continuously validating runtime legitimacy can significantly increase the blast radius of transferable credentials.

That observation led directly to another earlier post, Federation Is Easy. Runtime Enforcement Is Hard., which focused on the growing gap between establishing trust and enforcing trust during actual runtime communication.

This distinction is ultimately what shaped the architectural direction behind Riptides.

Instead of treating token validity alone as sufficient proof for access, Riptides continuously binds identity and authorization decisions to the actual running workload itself. Enforcement does not rely solely on portable artifacts copied into memory or assumptions made by adjacent infrastructure layers. Instead, authorization decisions are evaluated directly at the point where communication occurs, at the boundary between the process and the network.

This changes the security model substantially.

The system can continuously evaluate which process is initiating the connection, what identity is attached to it, where it is attempting to connect, and whether the current runtime context still satisfies the required trust assumptions. Most importantly, connections can be blocked immediately when those assumptions no longer hold.

This is fundamentally different from validating a credential once and assuming the resulting trust relationship remains valid indefinitely.

As infrastructure becomes increasingly dynamic, identity alone is no longer enough. Valid credentials still matter, but runtime legitimacy matters more. Modern systems need to continuously validate not only whether a credential is valid, but whether the current actor presenting it should still be trusted in the current execution context.

A valid token should not automatically mean access.

If these problems resonate with how you think about workload security, non-human identity, and runtime enforcement, give Riptides a try. We would love to show you what runtime-bound identity and real-time enforcement look like in practice.

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.