Decision tuple
An authorization request asks whether a subject may perform an action on a resource in a stated context. The policy and decision system can also use attributes about those objects, but the core tuple keeps the decision scoped and testable.
Name each element
The subject is the active principal or delegated actor. The resource is the protected object or service. The action is the requested operation. Context includes relevant time, device, network, transaction, risk, and environmental facts. Policy defines the decision rule and result.
Produce explicit results
Useful results include allow, deny, not applicable, conflict, or indeterminate, depending on the policy system. The enforcement point needs a safe mapping from each result to behavior. Record the policy version, relevant inputs, decision, reason, and enforcement result.
Failure and residual risk
Broad resource or action labels hide application permissions. Context can be stale or attacker-controlled. A subject identifier can lose the originating actor during delegation. An allow can be enforced on a different request than the one evaluated.
Pomerium boundary
Pomerium evaluates route access with user, request, device, and external context. The upstream application must authorize its own records and business actions. The application request can use the verified identity context but must build its own resource and action tuple.
Evaluation checklist
- Does the request name one subject, resource, action, and relevant context?
- Are identifiers stable and bound to trusted sources?
- Can every decision result map to explicit enforcement behavior?
- Is the decision bound to the same request that the enforcer acts on?
- Does evidence include the policy version and reason without storing credentials?
