Cedar authorization is access control written as policies in Cedar, an open-source language purpose-built to decide who is allowed to do what in an application. Instead of scattering role checks through your code, you write rules that an engine evaluates against each request and answers with allow or deny. Cedar was created by AWS, is now an open-source project under the Cloud Native Computing Foundation, and powers Amazon Verified Permissions. Its point, and the reason it matters here, is that it goes past the flat role checks most systems start with.
Role-based access control took teams a long way, and it still handles the simple cases fine. The trouble is that real access rules rarely stop at "what kind of user is this," and RBAC has no clean way to add the conditions that do the deciding: which resource, whose data, from where, at what time. Cedar authorization exists to express those conditions in one readable place. This piece covers where RBAC runs out, how Cedar goes beyond it, and what that buys you as products add tenants, APIs, and agents. For the mechanics of writing Cedar rules, the companion piece is What Are Cedar Policies?.
Cedar authorization uses the Cedar policy language to define permissions and a matching engine to evaluate them. Per the Cedar project, Cedar is "a language for defining permissions as policies, and a specification for evaluating those policies," open source under Apache 2.0. A Cedar decision considers four parts of a request, the principal, the action, the resource, and the context, and returns a single allow or deny.
Three properties make it more than a rules file. It is expressive, purpose-built for both role-based and attribute-based access control, so one language covers cases that usually need two systems. It is analyzable, designed for automated reasoning, so tools can check that your policies actually mean what you think. And it is portable, so the same policies deploy across services instead of being re-coded per app. Those are the traits that let Cedar sit above a role table rather than inside one.
RBAC decides access by role, and its limit is that a role is a blunt instrument for rules that depend on anything else. A role says "admins can edit," but real policy is usually "an admin can edit records in their own region, during business hours, and not export them." RBAC cannot express the second sentence, so those conditions leak into application code, one check at a time.
The classic failure mode is role explosion. To fake context with roles, teams create admin-us, admin-us-readonly, admin-eu-billing, and on and on, until the role list is unmanageable and no one is sure which role grants what. Each new condition multiplies the roles instead of adding a rule. That is the signal a system has outgrown RBAC: the roles are proliferating because they are being used to smuggle in context they were never meant to carry.
Cedar goes beyond RBAC by expressing roles and attributes in the same policy, so context becomes a condition rather than a new role. Roles still exist, represented as groups a principal belongs to, but a policy can layer any attribute of the request on top: the resource's owner, the tenant, the time, the source network, whether a client certificate was presented. That is role-based and attribute-based access control in one language, which is exactly what the Cedar project is built for.
A single policy can carry what would have been a dozen roles. Instead of minting admin-us-billing-readonly, you write one rule that reads close to plain English:
permit (
principal in Role::"billing-admin",
action == Action::"read",
resource
)
when {
resource.region == principal.region &&
context.time_of_day_seconds >= 32400 &&
context.time_of_day_seconds < 61200
};
Cedar also evaluates predictably: if no policy permits a request it is denied by default, and a matching forbid always beats a matching permit, so a guardrail cannot be quietly overridden. The full walkthrough of that model lives in What Are Cedar Policies?; the point for this piece is that the conditions live in the policy, not smeared across your handlers.
Cedar matters because modern software multiplies the access decisions faster than roles can keep up. A product with multiple APIs, multi-tenant customers, and now AI agents acting on a user's behalf has to decide access per request, with context, at a scale where a role table falls apart. This is the fine-grained authorization problem, and Cedar is one of the strongest ways to answer it.
Agents make the case sharp. When an AI agent acts, the decision often turns on whom it is acting for and under what limits, which is context, not role. Because Cedar is analyzable, you can also prove properties of your policy set rather than hoping your checks are consistent, which is the kind of assurance a security review asks for. And because it is portable and open, adopting it does not lock you to one vendor's proprietary rules engine.
MonoCloud uses Cedar to decide access at the moment an access token is issued. Every token request is evaluated against Cedar policies first, with full context, the user and their groups, the requested scopes, the grant type, the source network and country, the time, and whether a client certificate was presented, and a token is granted only if policy permits it. The same engine governs users, machine clients, and agents, so the rules do not fragment as you add non-human callers.
Deciding at token issuance puts Cedar at a chokepoint every request passes, and keeps the rules in one reviewable layer instead of scattered across services. You can write policies in the dashboard with structured fields for common cases or author Cedar directly for context-aware rules, validated against a schema before they save. The full model is in the API Access Policies guide, and you can start building on MonoCloud for free.