A policy check determines whether a specific access request satisfies authorization rules. The request names a principal, action, and resource, then supplies context such as device trust, time, location, ownership, or role. In Cedar, these inputs form PARC: principal, action, resource, and context. Policy scope is matched to the first three inputs; conditions are evaluated against entity attributes and contextual data. section 7.3 section 7.3.1
A policy engine needs more than policy text. The surrounding system constructs the request, supplies applicable policies, and provides entity data for relationships and attributes such as team membership or document ownership. The engine then returns allow, deny, or no decision; an enforcement point uses that result to permit, block, or route the request. section 7.3.1 section 13.4.3
A practical check follows this decision path:
- Normalize identity and runtime signals into a request, including the principal, action, resource, and relevant context. section 13.4.3
- Find policies whose declared scope applies to the principal, action, and resource; Cedar can prefilter this set before condition evaluation. section 7.3.1 section 8.2.2
- Evaluate conditions using supplied attributes, relationships, and context, then return the policy decision. section 7.3 section 7.3.1
- Enforce the result near the request, record the decision, and stop processing when policy forbids the action. section 13.4.3
Editing an owned document
Bob requests to edit document doc456 from a managed device. A policy scoped to employees editing documents matches the request. Its conditions confirm that Bob owns doc456 and that the device is managed, so a permit policy produces an allow decision. If either condition fails, that policy does not justify access. section 7.3.1 section 7.2.4
Policy checks support consistent enforcement across APIs, tenant boundaries, and agent tool calls. A gateway can apply global rules such as tenant isolation or data residency before a tenant layer applies fine-grained relationship-based rules. For an AI agent, every proposed tool action can be checked before execution; a denial becomes feedback for replanning rather than an unsafe action. section 11.0 section 13.4.3 section 18.3
The result must be deterministic and explainable. Identical policy, data, and context should yield the same decision, with a policy, rule, or condition available to explain a grant or denial. AI may help analyze policy practice or decision logs, but it should not infer enforcement decisions from prompts. section 17.1 section 17.6
Figure 7.2 Mapping an access request to a policy. Each component of the request (left) is matched against the corresponding part of the policy (right). Scope is matched directly; conditions are evaluated by using attributes and context.
Maps each PARC request component to policy scope and shows where attributes and context drive condition evaluation. section 7.3.1
