Wiki · Concept · Last reviewed June 25, 2026

Cedar Authorization Policy Language

Cedar is an authorization policy language and evaluation engine for expressing fine-grained permissions outside application code, with growing relevance for AI agents, tool access, and delegated action.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, Cedar, policy-as-code, access control, governance

Definition

Cedar is a policy language for writing authorization rules and making authorization decisions from those rules. The official reference guide frames Cedar as a way to decide whether a principal may perform an action on a resource in a given context. Its GitHub repository describes the project as a Rust implementation with an authorization engine and a validator for checking policies against an application schema.

The important governance move is separation. Instead of embedding every permission rule in application code, Cedar lets teams write policies as separate documents that can be reviewed, tested, updated, analyzed, and audited. Amazon Verified Permissions is a managed service that uses Cedar policies, but Cedar itself is also open source.

For AI agents, Cedar is relevant because agent authority needs more than a prompt saying "only do safe things." A tool call, connector action, or delegated workflow should be checked against explicit policy.

How It Works

A Cedar authorization request is organized around four practical objects: principal, action, resource, and context. The principal is the authenticated actor or machine principal. The action is the operation being requested. The resource is the object being acted on. Context carries transient facts such as session details, network information, assurance state, workflow purpose, or other request-specific data.

Cedar policies use effects such as permit and forbid, a scope over principal, action, and resource, and optional conditions that inspect attributes. Cedar represents principals, actions, and resources as entities. Entities can have attributes and parent relationships, letting a system model groups, hierarchies, resource containers, and role-like patterns.

Schemas are a major safety feature. A schema defines the entity types, attributes, actions, and context shapes that an application expects. Cedar does not use the schema to evaluate a request; it uses the schema to validate policies before they are accepted. That validation can catch mismatched names, wrong attribute types, and policies that do not match the application's authorization model.

Agent Context

Agent systems often cross a dangerous boundary: a model interprets language, then software turns that interpretation into an external action. Cedar can sit at the policy decision point for that action. The agent may propose a tool call, but the application still asks an authorization engine whether this principal, acting through this agent, may perform this action on this resource under this context.

That pattern matters for Tool Use and Function Calling. A customer-support agent might summarize an account but not issue a refund. A coding agent might edit a branch but not merge to production. The policy should live in a reviewable rule layer, not only in natural-language instructions.

Cedar does not make an agent safe by itself. It does not judge whether the model understood the task, whether retrieved text was poisoned, or whether a human approval was meaningful. It can enforce application-defined permissions once the request is represented in the policy model.

Governance and Safety

The governance value of Cedar is policy legibility. It can help turn vague agent permissions into explicit rules that security, legal, product, and operations teams can inspect. The Cedar paper by Joseph W. Cutler and coauthors describes the language as expressive, fast, safe, and analyzable. Those are engineering properties, not deployment guarantees.

A governed agent stack should record the policy set, schema version, principal, agent identity, action, resource, context, decision, determining policies, approval event, and downstream side effect. If a policy is changed after an incident, the record should preserve the policy version that actually decided the action.

The failure mode is policy theater. A beautiful policy language can still encode the wrong rule, omit the risky action, receive incomplete context, or sit behind an interface that lets the agent act before the check occurs. Cedar should be paired with AI Agent Observability, AI Audit Trails, AI Agent Sandboxing, and incident review.

Defense Pattern

Source Discipline

Claims about Cedar should cite the Cedar reference guide, the Cedar GitHub repository, AWS Verified Permissions documentation when discussing that service, or the published Cedar paper when discussing design and analysis claims. Do not collapse Cedar into all policy-as-code, AWS IAM, Rego, OpenFGA, XACML, or OAuth. Those systems may solve related authorization problems, but their policy languages, evaluation models, deployment assumptions, and audit surfaces differ.

Spiralist Reading

Spiralism reads Cedar as a grammar for institutional permission. The agent may speak in fluid language, but the institution still needs a harder sentence: this actor may do this action to this object under these conditions.

That is not a mystical boundary. It is bureaucracy made executable. Done well, it keeps delegated machine action from borrowing every key in the room. Done badly, it becomes another dashboard that says "deny" after the real decision already happened elsewhere.

Open Questions

Sources

Return to Wiki