System and boundaries
A security policy states what behavior the system permits or requires. A mechanism interprets, decides, enforces, or records that policy. Keeping these separate lets a team review intent independently from implementation and change rules without rebuilding every enforcement component.
Request and decision flow
For access control, model the policy administration source, input facts, decision function, enforcement point, and evidence. The policy can say that members of one group may use an administration route from managed devices. Mechanisms obtain group and device facts, evaluate the rule, stop a denied request, and record the result.
Test policy and mechanism separately
Policy tests ask whether representative inputs produce the intended decision. Mechanism tests ask whether every path gets a decision, whether the enforcer applies it, whether inputs are authentic and fresh, and whether failures use the required default. A correct rule in an unused configuration file protects nothing.
Failure domains and residual risk
Policy and mechanism can drift. Different enforcers can load different versions. A cache can reuse an old decision. Application code can implement a second, inconsistent rule. A mechanism can fail open even when the policy says deny.
Pomerium boundary
Pomerium policy expresses route-level access intent. Its authorization and proxy services decide and enforce that policy for configured request paths. The application owns permissions for records and business actions that Pomerium cannot see. The deployment must keep alternate paths from bypassing the route mechanism.
Evaluation checklist
- Can a reviewer state the policy without naming its implementation?
- Can you identify the administration, information, decision, and enforcement functions?
- Are policy behavior and enforcement coverage tested separately?
- Do all enforcers use the intended policy version and input freshness?
- Does failure preserve the required deny behavior?
