Choose where authorization decisions and enforcement run

System and boundaries

A central decision service evaluates requests for many enforcement points. A local decision library or sidecar evaluates near the action. A hybrid system centralizes policy administration and selected decisions while distributing policy, context, or enforcement.

Separate the decision location from the enforcement location. Enforcement must remain on every path to the protected action, even when the decision comes from a central service.

Request and decision flow

For each action, trace interception, tuple construction, context retrieval, evaluation, response, enforcement, and evidence. Record all network calls, local caches, policy versions, context versions, and deadlines.

Central designs need authenticated callers, resource-specific tuples, bounded latency, safe timeout behavior, and capacity for shared peaks. Local designs need authenticated policy distribution, version convergence, deterministic evaluation, and protected caches. Hybrid designs need an explicit rule for which layer owns each decision.

Failure domains

• A direct origin or alternate protocol bypasses the enforcement point.
• A shared decision service fails or saturates and callers fail open.
• A local evaluator uses an obsolete policy bundle.
• A decision cache omits resource, action, tenant, or context from its key.
• The decision and action refer to different object versions.
• Two layers each assume the other enforces a permission.
• Logs cannot connect the remote decision to the local action.

Design tradeoffs and residual risk

Centralization can reduce policy drift and improve explanation. It increases shared latency, availability, and blast-radius risk. Local evaluation can be fast and resilient. It increases distribution, compatibility, and revocation risk. Caching reduces load but extends the effect of old context.

Choose by the action's risk, fact ownership, latency budget, failure tolerance, and revocation target. Do not make one placement rule for every resource.

Pomerium boundary

Pomerium centralizes policy for protected routes and enforces it at its proxy path. An upstream can use that route decision as one control and verified identity as an input. It still needs local enforcement for records and business actions that Pomerium cannot name or observe.

Exercise

Compare three designs for an approval API: central remote decision, local embedded decision, and gateway route policy plus application object policy. For each design, set a latency budget, policy propagation target, stale-context limit, failure result, and evidence path.

Test a decision outage, old policy bundle, missing context source, changed object owner, and direct-origin request.

Evaluation checklist

• Is an enforcement point present on every route to the action?
• Does each decision include the exact resource, action, tenant, and current context?
• Are timeout, cache, version skew, and distribution failure behaviors explicit?
• Does the placement meet the required revocation and availability targets?
• Can evidence join the decision to the action that was enforced?