Cedar is a policy language for application permissions. Each policy either permits or forbids a request, names a scope of principal, action and resource, and can add when or unless conditions on attributes and context. The engine evaluates a request against all policies and returns allow or deny with the reasons.
The pieces
The Cedar reference guide defines the vocabulary.
| Term | Meaning |
|---|---|
| Principal | The authenticated user or device making the request |
| Action | What they want to do |
| Resource | What they want to do it to |
| Context | Transient details such as IP address or whether MFA was used |
| Policy | A statement that permits or forbids a request |
| Entity | A principal or resource, with attributes and group membership |
| Schema | A description of the entity and action types |
Authorization is the decision about whether a request is allowed by the set of policies. The guide is explicit that authorization is preceded by authentication, which proves identity.
Anatomy of a policy
A policy begins with an effect, permit or forbid. The scope then says which principal, action and resource it applies to, and the scope is mandatory. Optional conditions use when and unless clauses that evaluate attributes of the principal, resource and context, such as tags, time of day or source IP.
Here is a shape in the style of the documentation:
permit (
principal in Group::"editors",
action == Action::"updateDocument",
resource
)
when { resource.owner == principal };
It reads as: members of editors may update a document when they own it. That one policy mixes a role-like group with an attribute check, which is how Cedar covers both role-based and attribute-based styles.
How evaluation works
The engine evaluates the request against each policy and combines the results. The response contains the decision and the list of determining policies behind it. Your application has to gather all relevant facts and pass them in: the principal and resource entities, their group memberships, the folder hierarchy a photo sits in, and context such as the client IP.
That last point matters. The engine decides, but it does not fetch your data. If you hand it stale or incomplete entity data, the answer will be wrong in a confident way.
Static policies and templates
A static policy is complete and ready to use. A template has placeholders for the principal, resource or both, and becomes a template-linked policy when you fill them in. Templates suit sharing: "let this person view that folder" is the same shape each time.
Where it fits in your design
Cedar is a decision engine. In the vocabulary of the OWASP Authorization Patterns sheet, it plays the policy decision point. Your service remains the enforcement point and must apply the answer on every route, deny when no valid decision is available, and send verified attributes, not values the client claims for itself.
When to consider a policy language
- Rules are scattered in handlers and hard to review.
- Several services need the same rules.
- You want policy changes reviewed separately from business code.
- You need clear answers to "why was this denied".
For one small service with a handful of rules, plain code in a central authorization layer is simpler. Choose a language when the review and consistency benefits outweigh the integration work.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a written policy decides whether a change may proceed.
Safeguard supports policies, gates and guardrails for software changes and dependencies, and a free scan at gold.safeguard.sh/scan.
Quick check
Can a forbid policy override a permit?
The reference guide describes policies as explicitly permitting or forbidding. Check the evaluation rules in the guide for how results combine before you rely on a specific ordering.
Does Cedar authenticate users?
No. Authentication happens first. Cedar evaluates the already identified principal.
Sources
Last reviewed: 19 October 2026.
