What is Policy?
In access control, a policy is a machine-enforceable set of rules that decides whether a subject can perform an action on a resource under stated conditions. A policy can use identity, role, attributes, device, time, request, and resource context. Authentication supplies identity evidence. Policy evaluation produces an authorization decision. A written organizational security policy is broader and might not be directly executable.
Why it matters
A clear access policy turns security intent into repeatable authorization decisions. It also lets teams review why a request was allowed or denied and change the rule without changing the protected application.
How it works
- Collect verified facts about the subject, requested action, resource, and current context.
- Evaluate those facts against the applicable allow and deny rules at the policy decision point.
- Enforce the result at the policy enforcement point and record enough context for review.
Example
A Pomerium route policy allows members of the operations group to open an administration service only when the request also has the required device context.
Pomerium boundary
Pomerium attaches Pomerium Policy Language rules to routes and evaluates identity and context for protected requests. In PPL, a request must match an allow rule and must not match a deny rule. Enterprise can also apply inherited policy through namespaces and can use Rego for advanced logic.
Limits and non-claims
- A policy decision can be wrong when identity, device, resource, or context data is wrong or stale.
- A policy has no effect on a request path that bypasses its enforcement point.
- An allow decision does not make the requested application action safe or valid.
Evaluation checklist
- Does each rule state the subject, resource, action, conditions, and expected decision?
- Which default and conflict rule applies when inputs are missing or rules disagree?
- Do allow, deny, stale-input, bypass, rollback, and recovery tests prove the effective policy?
