Protection objective
No request receives authority unless an applicable policy grants it. New resources, unmatched subjects, unknown actions, missing context, invalid policy, and indeterminate evaluation must not create accidental access.
The principle
Default deny starts from no grant and adds explicit permission. It differs from a visible deny rule that can be overridden by another allow. The policy engine must define combining behavior for multiple matches, conflict, errors, and unavailable inputs.
Test the negative space
Test unknown users, resources, actions, and context. Remove required attributes. Introduce conflicting rules. Load an invalid policy version. Make an external context source unavailable. Confirm the enforcer maps every non-allow result to the intended safe behavior.
Failure and limits
An overly broad allow can still defeat the deny base. A different route or application API can bypass the policy. Denial during dependency failure can harm availability and drive undocumented workarounds. Design recovery rather than silently failing open.
Pomerium boundary
Pomerium policy should grant named route access and deny requests that do not meet it. The application needs its own default deny for internal resources and actions. Direct upstream access must not become an implicit grant.
Evaluation checklist
- What happens when no rule applies?
- What happens for conflict, invalid policy, and unavailable context?
- Can a broad allow or alternate route override the intended default?
- Are deny and indeterminate results enforced and logged?
- Is emergency access a separate controlled grant with expiry?
