Executive Summary
Every major identity platform built in the last two decades shares the same architectural assumption: authenticate an identity once, then grant it access that persists until someone remembers to revoke it. That assumption made sense when the identities in question were mostly humans, logging into a small number of systems, from inside a network perimeter that meant something. None of those conditions hold anymore. This paper makes the case that identity security has to move from a decide-once model to a decide-at-runtime model — and lays out what that actually requires in practice, not just in principle.
The Problem With Deciding Once
Standing Access Was Always a Compromise.
Standing privileged access exists because continuous authorization used to be operationally expensive. It was cheaper to grant broad, long-lived access and audit it periodically than to evaluate every single action against policy in real time. That trade-off produced a predictable failure mode: the gap between when access is granted and when it's actually used — or misused — is where nearly every modern identity-based attack now lives. A valid session gets hijacked. A service account nobody reviewed in eighteen months gets used to pivot into a domain controller. An AI agent's static API key gets discovered in an unrelated file and used to reach production. None of these require breaking authentication. They all live in the post-authentication gap that a decide-once architecture, by design, doesn't watch.
Three Forces Making This Worse
The Gap Is Widening, Not Closing.
Machine identities have overtaken human ones.
Service accounts, API keys, and workload identities now outnumber human employees by a wide margin in most enterprise environments, and the large majority operate with standing privileges and no in-line inspection. Access reviews built around quarterly human audits were never designed to keep pace with identity sprawl at this scale.
AI agents introduced a new class of identity with no established governance model.
Agentic systems make autonomous tool calls against production infrastructure, often through protocols like MCP that didn't exist eighteen months ago. Most organizations cannot yet answer who authorized a given agent, what it's permitted to do, or whether they could revoke its access on demand — because the tooling to ask those questions in real time doesn't exist in a decide-once architecture.
Regulatory expectations have shifted from point-in-time to continuous.
Frameworks like DORA, the EU AI Act, and continuous authorization mandates in government increasingly expect evidence generated at the moment access happens, not reconstructed for an annual audit. A decide-once system produces logs; it doesn't produce runtime evidence.
What Runtime Identity Security Actually Requires
Four Properties a Decide-at-Runtime Architecture Needs.
1. One policy engine, not a federation of point tools.
Splitting decision logic across a PAM vault, a cloud IAM tool, an AD security product, and a separate AI governance layer guarantees policy drift. The moment two tools disagree about what a given identity is allowed to do, you have a gap an attacker can operate in.
2. Enforcement in line, not logging after the fact.
A system that observes and alerts on standing access abuse after it happens is a detection system, not an authorization system. Runtime identity security means the decision and the enforcement happen in the same motion, before the action completes.
3. Coverage across every identity type, not just humans.
A platform that governs human privileged access well but treats service accounts, cloud workloads, and AI agents as someone else's problem has only solved part of the gap — usually the smaller part, given how the identity ratio has shifted.
4. Evidence as a byproduct of enforcement, not a separate reporting project.
If producing audit evidence requires a dedicated project every time an assessor asks, the underlying system isn't actually built for continuous authorization — it's built for periodic compliance theater. The record should already exist, generated the moment each decision was made.
Conclusion
The Login Was Never the Finish Line.
Authentication answers one question: is this identity who it claims to be. It has never answered the question that actually matters for security — should this identity be allowed to do this specific thing, right now, in this context. Decide-once architectures conflated those two questions because it used to be affordable to. It no longer is. The organizations closing the post-authentication gap are the ones treating every access decision as something to be made and enforced at the moment it matters — not once, at the door, and never again.
See This Architecture in Practice
Whiteswan is built on the four properties above: one policy engine, in-line enforcement, coverage across human, machine, and agentic identity, and evidence generated at runtime.
Want This as a Document to Share Internally?