Cedar Authorization Policy Language

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.

Snapshot

• Type: open source authorization policy language, specification, evaluator, and validation toolchain.
• Core request shape: principal, action, resource, and context, often abbreviated PARC in Cedar documentation.
• Policy structure: effect, scope, optional conditions, and optional annotations; effects are permit and forbid.
• Decision model: default deny, forbid-overrides-permit, and skip-on-error semantics with diagnostics.
• Governance value: access rules become reviewable policy artifacts rather than hidden branches in application code or prompt text.
• Agent relevance: Cedar can enforce tool-level or resource-level authorization before an AI agent performs an action.
• Boundary: Cedar authorizes requests; it does not authenticate users, evaluate model truthfulness, sandbox tools, classify data, or guarantee that the surrounding application sends complete context.

Current Context

As of June 25, 2026, the Cedar reference guide identifies Version 4.5 as the current language reference. The Cedar GitHub organization describes Cedar as an open source policy language and evaluation engine for fine-grained permissions, while the main repository contains the Rust crates that implement the language.

Cedar is also tracked as a cloud-native open source project. CNCF's project page lists Cedar as accepted to the Cloud Native Computing Foundation on October 8, 2025 at the Sandbox maturity level. That status matters for source discipline: CNCF Sandbox status is a governance and ecosystem fact, not proof that every Cedar deployment is secure.

AWS continues to use Cedar in managed services. Amazon Verified Permissions uses the Cedar policy language engine for authorization decisions, but AWS documentation also warns that Verified Permissions and native Cedar can differ; as of May 2026, Verified Permissions had aligned with Cedar on multiple namespaces. Amazon Bedrock AgentCore Policy became generally available on March 3, 2026 and uses Cedar policies to control AgentCore Gateway tool access and input validation outside agent code.

For AI governance, AgentCore Policy is a current managed-product example: an agent may propose a tool call, but a gateway-side policy engine can intercept the request and evaluate it before the tool runs. The principle generalizes beyond AWS, but the implementation details do not. A self-hosted Cedar evaluator, Verified Permissions policy store, AgentCore policy engine, and another vendor's authorization layer have different logs, management APIs, failure modes, and trust boundaries.

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 when or unless 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.

The application still supplies the facts. Cedar can evaluate only the policies, entities, and context it receives. If the application omits a user's group membership, passes stale resource attributes, hides the fact that a model is acting through a delegated workflow, or normalizes identifiers inconsistently, the Cedar decision can be formally evaluated and still be wrong for the real-world situation.

Decision Semantics

Cedar's authorization algorithm is intentionally conservative. If no permit policy satisfies the request, the decision is Deny. If a forbid policy satisfies the request, the decision is Deny even if another policy would permit the same request. This makes forbid policies useful as guardrails that broad permit policies cannot cross.

The less obvious rule is skip-on-error. If evaluating a policy produces an error, that policy is ignored for the purpose of the authorization decision and the error is reported in diagnostics. The official documentation frames this as avoiding a single broken policy taking down an otherwise working application. Governance teams should decide whether certain diagnostics must fail closed in their own control plane, especially for high-impact or agentic actions.

Cedar's safety story is therefore split. The language and implementation aim to evaluate Cedar semantics correctly; the application owner remains responsible for the authorization model, schema, policy review, context integrity, identifier stability, and response to diagnostics. The official security guidance says Cedar does not perform authentication, and that applications must authenticate users separately before authorizing their actions.

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.

AgentCore Policy illustrates the same pattern in a managed product. AWS documentation describes Cedar policies for AgentCore Gateway tools, including conditions over OAuth-user tags and tool input parameters. That is useful because the amount, destination, account, branch, ticket, repository, or message body can become policy context rather than only model-readable text.

Cedar does not make an agent safe by itself. It does not judge whether the model understood the task, whether retrieved text was poisoned, whether a tool description was malicious, or whether a human approval was meaningful. It can enforce application-defined permissions once the request is represented in the policy model. That makes it a control point, not a complete agent-safety system.

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, diagnostics, 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.

Natural-language policy authoring raises a separate review problem. AWS says AgentCore Policy can convert natural-language requirements into Cedar. That can help teams draft controls, but generated policy should be treated like generated code: review it against the schema, test allow and deny cases, inspect for broad scopes, and preserve the generated source and approving human.

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, OAuth Security Best Current Practice, and incident review.

Minimum Evidence Record

A Cedar-backed authorization claim is useful only if reviewers can reconstruct what was actually evaluated. For agent and tool governance, preserve at least:

• Policy boundary: policy store or policy set ID, policy IDs, policy version, template links, author, reviewer, deployment time, and rollback path.
• Schema boundary: schema version, entity types, action definitions, context shape, validation mode, and policy-validation result.
• Request boundary: principal, agent identity, delegated user or workflow, action, resource, context, entity data source, and timestamp.
• Decision boundary: allow or deny result, determining policies, diagnostics, policy errors, and whether the application failed closed on any diagnostic.
• Tool boundary: tool or MCP server, OAuth scopes or resource indicators, input parameters used as context, human approval event, and post-decision side effect.
• Change boundary: who can alter policies, schemas, generated policy prompts, entity feeds, policy templates, context mappings, and tool-to-action mappings.
• Incident boundary: blocked attempts, denied high-risk actions, policy bypass reports, stale entity data, policy-generation errors, and link to AI Incident Reporting.

Defense Pattern

• Model the domain first. Define principals, actions, resources, context, and schemas before writing agent policies.
• Keep policies outside prompts. Natural-language instructions can guide the model, but enforceable authorization belongs in code and policy.
• Validate every policy change. Use schemas, tests, review, and staging before policy updates reach production agents.
• Use stable identifiers. Cedar documentation warns that reused friendly names can accidentally transfer permissions; use immutable, non-recyclable identifiers for principals and resources.
• Handle diagnostics deliberately. Decide which policy errors or validation failures block deployment or runtime actions.
• Separate permit from approval. A policy decision can say an action is allowed; high-impact actions may still need human review.
• Constrain the context path. Treat the code that maps tool inputs, OAuth claims, retrieval state, and user attributes into Cedar context as security-sensitive.
• Log the decision path. Preserve the request, policy version, decision, determining policies, and side effect.
• Test denial cases. Red teams should verify that agents cannot bypass policy through alternate tools, stale context, or delegated agents.
• Pair with containment. Cedar should sit beside sandboxing, token scoping, network limits, and tool allowlists, not replace them.

Source Discipline

Claims about Cedar should cite the Cedar reference guide, the Cedar GitHub repository, AWS Verified Permissions documentation when discussing that service, AgentCore documentation when discussing agent-tool policy, CNCF pages when discussing project status, or the published Cedar papers 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. Cedar authorizes application requests; OAuth issues and protects delegated tokens; IAM governs AWS service permissions; sandboxing limits runtime blast radius.

For current product claims, preserve the source layer. "Cedar Version 4.5," "Cedar CNCF Sandbox," "Amazon Verified Permissions," and "Amazon Bedrock AgentCore Policy" are related but not interchangeable. A managed service can lag, extend, or restrict the native language, and a native Cedar claim may not describe what a hosted service exposes.

For AI-agent claims, require a concrete tool boundary. A claim that "Cedar governs the agent" should name the policy decision point, tool or gateway, request schema, principal, action, resource, context mapping, policy version, approval path, and logs. Otherwise the sentence may mean only that Cedar exists somewhere in the architecture diagram.

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

• Which agent actions should be represented as first-class Cedar actions rather than hidden inside generic tool calls?
• How much prompt, retrieval, and memory state should enter authorization context without leaking private information?
• Should agent policy stores require separate review for policies that permit external messages, purchases, deletion, deployment, or data export?
• How should policy engines represent one agent delegating to another agent across organizational boundaries?

Related Pages

• Confused Deputy Problem
• AI Agent Identity
• Capability-Based Security
• AI Agent Sandboxing
• AI Agent Observability
• AI Audit Trails
• Model Context Protocol
• Tool Use and Function Calling
• Prompt Injection
• Secure AI System Development
• AI Governance

Sources

• Cedar Policy Language, Reference Guide, Version 4.5; reviewed June 25, 2026.
• Cedar Policy Language, Terms and concepts, reviewed June 25, 2026.
• Cedar Policy Language, Authorization, reviewed June 25, 2026.
• Cedar Policy Language, Basic policy construction in Cedar, reviewed June 25, 2026.
• Cedar Policy Language, Cedar policy validation against schema, reviewed June 25, 2026.
• Cedar Policy Language, Schema overview, reviewed June 25, 2026.
• Cedar Policy Language, Security considerations, reviewed June 25, 2026.
• cedar-policy maintainers, Cedar GitHub repository, reviewed June 25, 2026.
• CNCF, Cedar project page, reviewed June 25, 2026.
• AWS, What is Amazon Verified Permissions?, reviewed June 25, 2026.
• AWS, Differences between Amazon Verified Permissions and the Cedar policy language, reviewed June 25, 2026.
• AWS, Understanding Cedar policies in AgentCore Policy, reviewed June 25, 2026.
• AWS, Policy in Amazon Bedrock AgentCore is now generally available, March 3, 2026.
• Joseph W. Cutler et al., Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization, arXiv:2403.04651, revised March 8, 2024.
• Craig Disselkoen et al., How We Built Cedar: A Verification-Guided Approach, arXiv:2407.01688, July 1, 2024.

Return to Wiki