Protection objective
Access must follow an explicit grant. Missing, invalid, ambiguous, or unavailable authorization information must not create more authority. The system must also define what safe behavior means for availability and recovery, because a simple denial can block critical operations.
The principle
Fail-safe defaults establish denial as the base state and add narrow permissions. They cover new resources, unmatched rules, unknown identities, failed validation, missing context, stale policy, and dependency outages. The result must be deliberate and testable for each resource class.
Design failure behavior
List each authorization dependency and input. For timeout, invalid data, unavailable service, or version mismatch, choose deny, limited degraded operation, or a separately controlled emergency path. Record the reason, evidence, alert, expiry, and recovery step.
Failure and limits
"Fail closed" can cause unsafe loss of availability. Teams can then add an undocumented bypass that is less controlled than a designed recovery path. Cached grants can also turn an apparent deny default into continued access.
Pomerium boundary
Pomerium policy should grant named access and deny unmatched requests. Operators must define behavior for unavailable identity or context dependencies and protect any emergency route. The application still needs a deny default for permissions within the route.
Evaluation checklist
- Does a new or unmatched resource start denied?
- What happens for missing, invalid, stale, or unavailable decision inputs?
- Can cached grants outlive the intended failure or revocation bound?
- Is emergency access narrow, time-bound, attributable, and reviewed?
- Have deny and recovery paths been tested under dependency failure?
