Decision age
Authorization context becomes stale when the facts used for an allow no longer describe the action being enforced. Identity state, group membership, device posture, resource ownership, policy, risk, time, and transaction state can all change between evaluation and use.
Locate each clock
For every input, record its authority, collection time, cache time, maximum age, invalidation path, and consumer. Then trace the delay through identity tokens, sessions, policy distribution, attribute stores, decision caches, persistent connections, queues, and application caches.
Bind check to use
Evaluate close to the protected action. Bind the decision to stable subject, resource, action, and request data. Recheck mutable state before an irreversible commit. Use short cache limits only when the residual window is acceptable. Push invalidation where rapid revocation is required, and define behavior when a context source is unavailable.
Failure and residual risk
A valid session can preserve removed group membership. A cached allow can outlive a policy change. A resource can change owners after the check. A queued job can execute after delegated authority expires. A long-lived stream can continue after new requests would be denied. Short lifetimes reduce but do not remove these races.
Pomerium boundary
Pomerium can reevaluate route policy for requests using available identity, device, and external context. It cannot make an application's object state current or revoke an action already accepted by the application. Upstreams must recheck their own mutable resource and transaction state.
Evaluation checklist
- What is the maximum age of every authorization input and cached result?
- Does revocation reach sessions, connections, queues, and application caches?
- Is the allow bound to the same resource version and action that is used?
- What happens when a policy information source is missing or delayed?
- Has the team measured the longest stale-access window end to end?
