What Are Cedar Policies? Human-Readable Authorization Explained
Cedar policies are access rules written in Cedar, an open-source policy language created by AWS for fine-grained authorization. You write the rules; a policy engine evaluates them against each request and returns an allow or deny decision. MonoCloud uses Cedar because it makes policies human-readable, easy to audit, and quick to write, so the rules governing your APIs and agents are something a person can actually read and trust.
That readability is the point. Authorization logic buried in application code is hard to review and easy to get wrong. Cedar rules are written to be read, by an engineer or a security reviewer, and validated against a schema so a typo is caught before it reaches production. This article explains what a Cedar policy is, how the model works, why it improves on static scopes, and how MonoCloud uses Cedar to decide who gets a token and how that token behaves.
This is part of our AI agent identity series, where policy-based authorization is the first layer of the stack.
What is a Cedar policy?
A Cedar policy is a single statement, written in the Cedar language, that an policy engine evaluates against a request to produce a decision: allow or deny. The request is described by four parts: the principal making it, the action being attempted, the resource being touched, and the surrounding context. Cedar itself does not enforce anything. It evaluates the rules and returns the result, and the system around it acts on that result. In MonoCloud, that system is the authorization server, which uses the decision to issue or refuse a token.
Cedar is declarative, which means a policy describes what must be true for a request to be permitted rather than the steps to check it. That keeps rules short and legible. A policy that lets a billing administrator read invoices is a few lines that read close to that plain sentence, not a function spread across a request handler.
Who created Cedar, and is it open source?
Cedar is an open-source policy language built by AWS for fine-grained authorization, and it is the engine behind Amazon Verified Permissions. The language, its specification, and its tooling are public, so teams can adopt Cedar without locking themselves to a single vendor. You can read the language reference and try policies in the playground on the Cedar project site.
Being open and specified matters for a security primitive. The evaluation rules are defined precisely, the behavior is the same wherever Cedar runs, and policies can be analyzed by tools rather than only tested by hand. MonoCloud chose Cedar for exactly these reasons: it lets customers express their access policies in a form that is human-readable, easy to audit, and easy to write, which matters when a security team needs to read the rules and trust them.
How does a Cedar policy work?
Every Cedar policy is either a permit or a forbid, evaluated against the principal, action, resource, and context of a request. A condition block adds the specifics: the attributes that must hold for the policy to apply. Here is a real Cedar policy from MonoCloud that permits a client to receive a billing token only when it requests the right scopes:
permit (
principal == Client::"web-client",
action,
resource == Api::"https://api.example.com/billing"
) when {
context.requested_scopes.contains(Scope::"billing.read")
};
Swap permit for forbid and the same statement becomes a guardrail that blocks the request instead.
Three properties of the model keep its behavior predictable, and they matter in practice:
| Rule | What it means |
|---|---|
| Default deny | If nothing permits a request, it is denied. Access is always granted explicitly. |
| Forbid wins | If any policy forbids a request, it is denied, even when another policy permits it. |
| Order-independent | Policies are declarative, so the outcome does not depend on how they are arranged. |
Default deny means a forgotten rule fails safe rather than leaving a hole. Forbid-wins makes guardrails reliable, because a "never from blocked networks" rule cannot be quietly overridden by a broad allow somewhere else. Order independence means you can add and remove rules without worrying about sequence.
Why Cedar beats static scopes and audiences
OAuth scopes and audiences answer two questions well: which API a token is for, and what it can do there. They have been the backbone of authorization for over a decade. The limit is that they answer the same way every time. A client either has read:billing or it does not. There is no room for "but only from the office network," "but not at 3am," or "but only for users in the admin group."
Real access rules are rarely that flat, so they leak into other layers. The API gateway enforces IP ranges, a piece of middleware checks the time, a request handler inspects the user's groups. Each works alone, but together they are hard to reason about. There is no single source of truth, rules drift when one of four places gets missed, and answering "who can call this API, and when?" turns into reading code across several repositories.
Cedar pulls those scattered checks back into one place. Because the rules live together and read declaratively, "who can access this API and when" becomes something you answer by looking, not by tracing logic across systems. Scopes and audiences still do their job at your APIs; Cedar adds the context-aware decision earlier, where the most information is available.
What does context-aware authorization look like?
Context-aware authorization uses everything known about a request at decision time, not just the scope list. At the moment a token is requested, the authorization server knows the client, the user and their groups, the grant type, the requested scopes and audiences, the source IP and its resolved country, the time of day, whether the caller is a browser or a server, and whether a client certificate was presented.
Cedar can compose any of these into a rule. Restrict an API to a single network zone with one condition. Permit a write scope only when an admin authenticated recently. Allow refunds only inside business hours. Block a partner integration unless the request comes from an approved country. None of this fits in a scope list, and all of it reads as plain policy. For example, this policy permits a request only when it comes from the United States, between 9am and 11pm, and from an approved IP address:
permit (principal, action, resource)
when {
context.location.country == Country::"US" &&
context.time_of_day_seconds >= 32400 && context.time_of_day_seconds <= 82800 &&
[ip("1.1.1.1"), ip("1.1.1.2")].contains(context.location.ip_address)
};
How MonoCloud uses Cedar
MonoCloud applies Cedar at token issuance through its API Access Policies. Every access token MonoCloud issues passes through Cedar evaluation first, at the authorization endpoint, at the token endpoint across all grant types, and again on every refresh. If no policy permits the request, no token is issued. Deciding this before a token exists is stronger than checking it later, because a request that breaks the rules never produces a credential to leak, replay, or revoke.
You do not have to write Cedar by hand to use it. For common cases such as "allow this client, restrict to these scopes, permit or deny," basic policies are configured with structured fields in the dashboard and compiled to Cedar for you. When you need full context-aware rules, advanced policies let you write Cedar directly, with a library of sample policies and an AI assistant that drafts a policy from a plain-English description like "Allow billing-admin during business hours from the corporate network." Either way, every policy is validated against the schema before it can be saved, so invalid rules never reach evaluation.
A permitted policy can also shape the token it issues, through the rule's Tokens tab. It can set a shorter access-token lifetime for a riskier context, change the token type between a self-contained JWT and an opaque reference token that can be revoked centrally, control whether the token may carry multiple audiences or call the UserInfo endpoint, and bind the token to the user's session so it ends at logout. The override applies only when that specific rule matches, so one API can issue different tokens for different situations without any change to the API itself.
Getting started with Cedar policies
Start by writing down the access rules you already enforce in scattered places: the IP ranges in your gateway, the time checks in middleware, the group checks in code. Each of those is a candidate for a single Cedar policy. Begin with basic rules, then add context conditions where a flat scope was hiding real requirements.
In MonoCloud, you can add your first policy in a few minutes from the dashboard, let the AI assistant draft a starting point from a plain-English sentence, and rely on schema validation to catch mistakes before they save.