A policy scope identifies the requests a rule is meant to govern before its contextual logic is considered. It answers three direct questions: who is requesting access (the principal), what operation is requested (the action), and what object is targeted (the resource). In Cedar, these constraints appear in the policy header; together with an effect and optional conditions, they state a policy contract: a principal may be permitted or forbidden to perform an action on a resource when the relevant conditions hold. section 7.2.2 section 7.2.4
Scope is not the same as a condition. Scope selects the kinds of requests to which a policy can apply; conditions express additional facts that must be true, such as device trust, time of day, team membership, or on-call status. Keeping those roles separate makes a rule’s intended audience and operation visible while retaining flexibility for changing context. section 7.2.2 section 7.2.3
Document access with a narrow scope
A document policy can target any employee performing a view or edit action on a document they own. That scope prevents the rule from being considered for unrelated actions or resources. A managed-device requirement belongs in the condition logic: the policy is structurally about employees viewing or editing documents, but permits access only when the device is managed. section 7.2.2 section 7.2.4
Structured scope also affects evaluation. Cedar can inspect principal, action, and resource constraints first, then prefilter the policy set to rules relevant to the request before evaluating conditions. This can improve runtime performance and makes policy behavior easier to audit. In Rego, comparable constraints are written in the rule body rather than declared as structured scope, so authors manually express and manage that filtering logic. section 8.2.2
Figure 8.1 OPA (left) vs. Cedar (right) policy evaluation flow. OPA evaluates all policies using the full input, with no built-in filtering based on principal, action, or resource. In contrast, Cedar policies can declare structural scope, allowing the engine to filter policies before evaluation. This improves performance and ensures that only relevant policies are considered.
Compare full-input rule evaluation with Cedar’s scope-based filtering before condition evaluation. section 8.2.2
Use scope as a security and maintenance boundary:
- Constrain principals, actions, and resources precisely to support least privilege and avoid exposing resources beyond their intended audience. section 10.5
- Use a consistent business boundary, such as project membership, across related policies; mismatched manager-based and project-based scopes can create confusing or unintended access. section 10.1.1
- Split rules when distinct principal types need different access logic. Separate employee and customer rules keep scopes tight and avoid a broad rule with branching conditions. section 9.3.1
- Anchor rules to stable entities such as teams or projects when possible, rather than organizational labels that change frequently. section 10.5
Policy scope should not be confused with OAuth scopes. OAuth scopes define the outer delegated boundary of APIs a token bearer may access and can be revoked without changing an account password. After token validation, detailed authorization can still convert the API call into a principal-action-resource-condition request and apply policy scope and conditions to a specific resource. section 11.2 section 11.3
