Continuous authorization is an authorization model in which a principal's permission to act is re-evaluated at every action — against current policy, current trust standing, and current task context — rather than being decided once at session start or credential issuance and trusted until expiry. It is the zero-trust principle ("never trust, always verify") applied at the granularity where autonomous systems actually operate: the individual action.

The model exists because the traditional alternative, point-in-time authorization, embeds an assumption that no longer holds for modern workloads: that a principal's intent and risk are stable for the lifetime of a session. Check the permissions at login, mint a token, honor the token until it expires. That was tolerable when sessions were short, principals were humans, and behavior between checks was predictable.

Why point-in-time authorization fails for AI agents

AI agents break each assumption behind the point-in-time model:

  • Sessions are long and dense. An agent workflow can run for hours and issue thousands of actions. A grant that was right at action 3 can be wrong at action 3,000 — and at machine speed, the interval between "authorization became wrong" and "damage done" is milliseconds.
  • Intent is manipulable mid-run. A goal-hijacked agent does not re-authenticate; it inherits every permission of its already-authorized session. Under point-in-time authorization, the attacker's window is the credential's full lifetime.
  • Agents delegate. Orchestrators hand tasks to sub-agents. Without per-delegation authorization, authority multiplies across principals and the weakest agent's compromise inherits the strongest agent's permissions.
  • Estates drift. Agents accumulate grants as roles evolve; nobody removes what is no longer needed. Continuous evaluation is what makes stale privilege fail closed at the moment of use rather than persist as standing attack surface.

What gets evaluated, per action

A continuous authorization decision consults four inputs at the moment an action is attempted:

  1. Current policy — the permission model as it stands now, so revocation takes effect on the next action, not at token expiry.
  2. Current identity and trust — is the credential valid, and does the principal's trust score still support this action class? Trust that degrades on anomalous behavior becomes a dynamic gate.
  3. Current task context — is the action within the envelope of the task actually being performed? Authorization to read records for ticket resolution is not authorization to bulk-export them.
  4. Current resource state — budgets, rate limits, and concurrency caps checked at dispatch; reservation-based budget enforcement is continuous authorization applied to spend.

Architecturally, the evaluation must happen at an enforcement point outside the agent — a control plane its traffic traverses — because per-action checks inside the agent's own process share the agent's fate when it is compromised. That placement argument is developed in AI agent runtime security.

Continuous authorization and OWASP ASI03

The OWASP Top 10 for Agentic Applications 2026 lists identity and privilege abuse as ASI03, and continuous authorization is its structural mitigation: it converts privilege abuse from a standing condition into a per-action failure. The full analysis — including delegation-chain scoping and implementation patterns that keep latency negligible — is in agent privilege abuse and continuous authorization.

Relationship to adjacent concepts

Continuous authorization composes with, rather than replaces, its neighbors: least privilege defines how small a grant should be; continuous authorization decides when the grant is re-checked. Capability tokens are a natural carrier — short-lived, narrowly scoped credentials that expire with the task. And zero trust is the umbrella philosophy; continuous authorization is its per-action enforcement for autonomous principals.

Common questions

What is continuous authorization in one sentence? Re-evaluating a principal's permission to act at every action — against current policy, trust, and task context — instead of trusting a check performed at session start.

How is it different from short token lifetimes? Short tokens shrink the window between checks; continuous authorization removes the window. A five-minute token still authorizes everything within five minutes unconditionally. Per-action evaluation also consults context a token cannot carry: the current task, the current trust score, the current budget state.

Doesn't checking every action add unacceptable latency? Not in practice: identity and scope checks are sub-millisecond against local, short-TTL policy caches with explicit invalidation, and deeper contextual checks can be reserved for sensitive action classes. Milliseconds of evaluation against model calls measured in seconds is not the constraint that matters.

Is continuous authorization only relevant to AI agents? It benefits any long-running non-human principal, but agents make it essential: they act at machine speed, delegate authority, and can have their intent rewritten mid-session by adversarial content — the combination that makes any static grant unsafe.