Decision objective
Policy combining turns results from several rules or policy layers into one decision. Results can include allow, deny, not applicable, and indeterminate. The system must define precedence, inheritance, and error behavior before a conflict occurs.
Combining models
Deny-overrides favors a matching deny. Permit-overrides favors a matching allow. First-applicable uses order. Only-one-applicable treats overlap as an error. A product can use other explicit semantics. Default deny must cover no match and missing required context.
Test and evidence
Build a decision table for local, inherited, reusable, emergency, and application policy. Test each result alone and in conflict. Record which policy and rule contributed, which input was missing or invalid, and why the final result occurred.
Failure and residual risk
An allow can shadow a deny. Ordering can change during refactoring. An indeterminate result can become allow through unsafe error handling. Two enforcement layers can combine differently. A route decision and application object decision can each be correct and produce an unsafe combined result.
Pomerium boundary
Pomerium applies documented semantics to configured route and inherited policy. Operators must test the effective policy, conflicts, missing context, and application authorization. Pomerium decision evidence does not explain an independent policy engine unless its result is correlated.
Evaluation checklist
- Which result values can each rule or policy layer produce?
- Which combining rule applies to match, conflict, no match, and error?
- Does missing or invalid context fail safely?
- Can one decision be explained down to contributing policy and inputs?
- Do gateway and application policy combine to the intended final action?
