A policy set is the collection of authorization policies considered together for one access decision. In a large organization, relevant rules can come from security-group mandates, application teams, and other policy stores. The authorization layer gathers them into one set rather than treating a document edit, invoice approval, or device requirement as an isolated rule. section 7.3.2
For Cedar, evaluation first filters the set by scope: principal, action, and resource must match the request. No scope match means an implicit denial. Cedar then evaluates conditions on the scoped policies using attributes and request context. A policy contributes only when every when condition is true and every unless condition is false. section 7.3.2
A policy set provides a common decision point for rules that differ in purpose and ownership:
- Organization-wide controls can require managed devices or encryption standards. section 7.3.2
- Application policies can govern domain actions such as invoice approval or document editing. section 7.3.2
- Attribute-based access control (ABAC), relationship-based access control (ReBAC), and role-based access control (RBAC) checks can appear together. section 9.5.4
Combining relationship and team checks
A document-edit policy can permit an employee when the employee manages the document owner, or when the employee belongs to the legal team and the document is classified as Legal. The entity store supplies ownership, management, membership, and classification facts; the policy set evaluates those facts together at request time. section 9.5.4
permit(
principal is ACME::Employee,
action == ACME::Action::"doc:edit",
resource is ACME::Document
)
when {
resource.owner.manager == principal
|| (principal in ACME::Team::"team:legal" &&
resource.classification == "Legal")
};
This policy snippet shows one rule combining a manager relationship with legal-team membership and document classification. section 9.5.4
Treating policies as a set also makes change review broader than testing one request. Cedar uses deterministic, side-effect-free expressions and limited types, allowing tools to check a policy set for invariants, equivalence, coverage, contradictions, and unreachable rules before deployment. Efficient scope filtering supports decisions across hundreds or thousands of policies. section 7.4.6
A policy set sits in an authorization architecture: an entity store supplies facts, a policy enforcement point (PEP) turns an operational request into an evaluation, and a policy decision point can produce a decision that is testable and auditable. The same policies can be deployed through a local agent, managed service, or embedded PDP without changing the authorization model. section 9.9
Policy sets can also express narrowly delegated authority. An attached set may grant a subagent or assumed role permission for specific operations, resources, and conditions; the default posture is to forbid actions unless a policy explicitly permits them. Such policies may be temporary, contextual, or created during task execution. section 18.6.1
