Cedar is a policy language built for one job — deciding who is allowed to do what, on which resources, and under what conditions. Expressive, auditable, and formally verified.
// Allow document authors to read their own docs permit ( principal in Group::"editors", action == Action::"read", resource in Folder::"public-docs" ) when { resource.owner == principal && context.mfa_verified == true }; // Deny deletions for read-only resources forbid ( principal, action == Action::"delete", resource ) when { resource.readOnly == true };
In most applications, access rules are scattered across codebases — an if-statement here, a permission flag there. Over time they drift, contradict, and become impossible to audit.
Cedar moves your authorization rules out of application logic and into a dedicated policy layer — a single, reviewable, testable, auditable source of truth for every access decision your system makes.
Explore Features →Cedar is purpose-built — not a general-purpose rules engine, not a workflow tool. Just authorization, done with precision.
Cedar's evaluation engine is written in Rust, indexed for fast retrieval, and capable of evaluating thousands of policies per request without becoming a bottleneck.
Cedar is the first policy language designed from the start to be formally verified. Its semantics are mathematically modeled and key correctness properties are machine-proven.
A well-written Cedar policy reads almost like an English sentence. Authorization rules are statements about what the organization considers acceptable — legible to engineers, security officers, and auditors alike.
RBAC via group membership. ABAC via attribute comparison. ReBAC via entity hierarchy traversal. All three patterns share the same syntax and the same evaluation engine.
Declare the shape of your entities in a Cedar schema. The validator checks every policy against it before deployment, catching typos, type mismatches, and impossible conditions.
Full specification, engine, SDKs, and tooling available under Apache 2.0. No vendor lock-in, no licensing tiers, no proprietary extensions waiting to surprise you.
Write Cedar policies as .cedar files using a clean, readable syntax. Each policy describes a rule: who (principal), what (action), on what (resource), under what conditions.
Because policies are plain text, they live in Git like any other source artifact — reviewable in pull requests, diffable, and fully traceable.
The Cedar CLI lets you evaluate policies against sample requests directly from the terminal — no servers, no signups, no SaaS accounts required.
// team_policy.cedar permit ( principal in Team::"backend-eng", action in ActionSet::"deploy-actions", resource in Env::"staging" ) when { context.is_business_hours }; // $ cedar authorize --policies . // --principal 'User::"alice"' // --action 'Action::"deploy"' // --resource 'Env::"staging"' // → ALLOW
Declare the types of principals, actions, and resources in your system — what attributes they carry, what relationships they participate in.
Before any policy reaches production, Cedar's validator checks it against the schema — catching type mismatches, missing attributes, and impossible conditions.
Add schema validation to your deployment pipeline so that malformed or schema-violating policies are rejected before they ever affect production users.
// schema.cedarschema entity User { department: String, mfa_verified: Boolean, }; entity Document { owner: User, classification: String, readOnly: Boolean, }; // $ cedar validate --schema schema.cedarschema // --policies . ✓ All policies valid against schema
At runtime, your application sends a request to the Cedar engine — including the principal, action, resource, and any contextual data the policy needs.
Cedar's indexed engine evaluates every relevant policy in milliseconds and returns a single, deterministic decision: allow or deny.
No access is ever granted by accident. If no policy explicitly permits an action, the result is deny. Period.
// Node.js SDK example import { Authorizer } from '@cedar-policy/cedar-wasm'; const result = await authorizer.isAuthorized({ principal: 'User::"alice"', action: 'Action::"read"', resource: 'Document::"report-q4"', context: { mfa_verified: true }, }); console.log(result.decision); // → "Allow" · elapsed: 0.4ms
Because Cedar policies are explicit, declarative, and stored as text, they answer security questions directly — no archaeology through application code required.
Access rules live outside application code. Update a policy and the change takes effect immediately — no application release required.
Because policies are in Git, every change has an author, a timestamp, and a diff. Rolling back a policy is exactly like rolling back any other code change.
# git log --oneline policies/ a4f2c1e Restrict delete to doc owners only b8e391a Add MFA requirement for finance folder c120dff Allow contractors: read-only staging d991ba3 Revoke legacy admin wildcard policy # cedar analyze --diff HEAD~1 HEAD ✓ 1 policy narrowed (no new permissions) ✓ Safe to deploy
Cedar is designed to serve engineers, security teams, compliance officers, and auditors — all from the same policy files.
Stop debating where to put the next permission check. Write it once in Cedar, version it, test it, and move on. Integration takes hours, not weeks — Cedar is designed to express the rules you already had.
Gain a single, reviewable artifact for every access decision in your system. Cedar policies are explicit, scannable, and testable as a complete set — not buried in a codebase no one fully understands.
Show auditors real policies, not pull request archaeology. Cedar gives compliance teams a reviewable artifact they can present directly — answering the "who can access what and why" question in seconds.
Govern who can deploy, restart, or access sensitive data across hundreds of services using a single policy layer. Cedar scales from a single service to a complex internal platform without changing the model.
Cedar fits any application that has outgrown simple ownership-and-role checks — without requiring you to build an entire authorization engine from scratch.
Separate tenants cleanly while still allowing fine-grained sharing within a tenant — without duplicating logic for every customer variation.
Govern who can deploy, restart, or read sensitive data across hundreds of services from a single policy layer.
Express friendship graphs, group memberships, and content visibility rules in a single coherent model that scales with your user base.
Cedar ships with SDKs, a CLI, a VS Code extension, a language server, and WebAssembly support for edge and browser environments.
Cedar is purpose-built to support compliance requirements. Its policies are explicit, declarative, and reviewable — designed to answer auditor questions directly.
We had authorization logic in six different services, all slightly different. Moving to Cedar took two weeks and gave our security team something they could actually audit. First time that's happened in four years.
The formally verified part isn't just marketing. When you're explaining access control to an auditor, being able to say "the semantics are machine-proven" changes the conversation significantly.
Cedar reads like English. My compliance team can actually review our policies without asking engineering to translate. That alone was worth the migration effort.