Protection objective
Economy of mechanism reduces the amount of trusted logic that must be understood, tested, operated, and recovered correctly. It does not mean minimum features at any cost. It means the security-critical path has few concepts, explicit state, narrow interfaces, and one owner for each decision.
Security principle
Remove duplicate policy engines, compatibility modes, hidden fallbacks, mutable global state, and shared credentials that add authority without a required property. Keep parsing, identity, policy, enforcement, and evidence contracts narrow. Use standard mechanisms when their security profile fits.
Enforcement mechanism
Map the trusted computing base for one access decision. Identify every component that can alter identity, resource, action, policy, result, or enforcement. Remove unnecessary members, isolate optional features, and test the remaining interfaces and failure states.
Failure and residual risk
An implementation can be small and wrong. A shared simple mechanism can also create one broad failure domain. Splitting components can improve isolation and add protocol and state complexity. Measure both trusted size and interaction complexity.
Pomerium boundary
Pomerium can centralize authentication and route authorization for covered services. Operators should avoid parallel bypass policy, duplicate identity translation, and hidden direct routes. Applications still need their own object authorization and can require separate mechanisms.
Evaluation checklist
- Which components can change or bypass one access decision?
- Which mechanisms duplicate policy, identity, credential, or routing behavior?
- Can each security-critical interface and state transition be explained and tested?
- Does simplification create a new shared failure domain?
- Which complexity remains necessary for isolation, resilience, or application authorization?
