System and boundaries
A reference monitor is an abstract control that mediates access by subjects to protected objects. A practical reference validation mechanism should be invoked on every relevant access, resist tampering, and be small or structured enough to support analysis and testing.
Request and decision flow
Trace every subject-to-object path through the decision and enforcement mechanism. State which identity and context it accepts, which policy it evaluates, how it stops denial, and what evidence it produces. Include retries, caches, internal callers, administrative interfaces, and recovery routes.
Assurance questions
Complete mediation asks whether every relevant access is checked. Tamper resistance asks whether an untrusted subject can change or avoid the control. Verifiability asks whether the mechanism and its deployment can support justified confidence through design review, tests, isolation, and operational evidence.
Failure domains and residual risk
A gateway is not a reference monitor for resources reachable around it. A large distributed mechanism can have inconsistent policy or stale inputs. A privileged operator or compromised control plane can change the mechanism. Availability workarounds can create bypasses.
Pomerium boundary
Pomerium can serve as a route-level decision and enforcement mechanism for traffic that must pass through it. Upstream network isolation, Pomerium control-plane protection, identity-source integrity, and application authorization remain necessary. It is not the reference monitor for internal application objects unless every such access is represented and mediated there.
Evaluation checklist
- Does every path to the protected resource invoke the mechanism?
- Can the requester alter policy, trusted inputs, or enforcement state?
- Is the mechanism bounded enough to review and test?
- Do denial and dependency failure produce the intended result?
- What evidence shows mediation in the deployed system?
