Design application authorization before writing Cedar policies

Start with the business action

Design the application authorization model before writing Cedar policies. Name the business operation, the principal requesting it, the resource affected and the trusted data needed to decide. Choose how tenant policies are isolated, then define how the application handles the authorization response and enforces it on the same operation. A collection of syntactically valid policies is not a complete access-control system if the application supplies unreliable entities or ignores the decision at the API boundary. ^[1][3][7]

Cedar evaluates authorization requests against policies and entity data. Amazon Verified Permissions provides a managed service built around that model, but the application still constructs requests and acts on the result. Keep the language, the managed policy store and the application's enforcement code conceptually separate. That separation makes it possible to ask whether an error belongs to the business model, policy evaluation, data supplied to the service or the code that performs the operation. ^[3][7]

Begin with an operation that matters to the business rather than a role name that already exists. In a hypothetical expense application, approving an expense is different from viewing it, editing its supporting information or changing who can approve it. A role called finance does not explain those distinctions by itself. The design should state which relationship or attribute permits each operation, which conditions prohibit it and who is authorized to change the facts on which the decision depends.

This is application authorization, not a replacement for AWS IAM. A workload role may permit the application to call Verified Permissions or read its database while saying nothing about whether a particular employee may approve another employee's expense. Conversely, a Cedar Allow does not grant the workload additional AWS permissions. Both layers can be necessary, but they answer different questions and should have different review records.

OWASP's authorization guidance recommends explicit permission validation on every request and a default-deny approach. These principles become operational only when the application can identify the requested action and object precisely. A page that hides an approval button is not enough if an API endpoint can still perform the approval without the same check. Treat the user-interface decision as a usability hint and the server-side enforcement as the authority boundary. ^[8]

The outcome of the design phase should be small enough to review: an action and resource model, an entity-provenance map, a policy-store decision, a failure-handling rule and a set of expected allow and deny cases. Those artifacts are original recommendations for organizing the work. They are not a claim that Cedar produces the business model automatically or that any application described here has been deployed and tested.

Name the entities and who may change them

A Cedar request identifies the principal, action and resource, with context for additional request information. Entity data describes the objects and relationships referenced by the policies. A schema can describe entity types, their attributes, permitted relationships and the expected request types for actions. These structures give the authorizer meaningful inputs, but they do not establish that the application obtained those inputs from a trustworthy source. ^[3][4]

Use stable identifiers for business objects and principals. Display names, email addresses and human-readable labels can change or be reused in ways the authorization model does not intend. The exact identifier design belongs to the application, but its ownership and lifecycle must be explicit. A deleted and recreated account should not silently inherit another person's application relationships merely because the visible label matches an earlier record.

For each authorization attribute, identify its authoritative writer. The principal's department may come from a controlled identity source; an expense's owner may come from the application database; a request's target amount may need to come from the persisted transaction being approved. If the client can supply a field that is supposed to establish privilege, policy evaluation can be internally consistent while the overall decision is wrong. A schema validates shape, not the honesty of a client assertion.

Distinguish identity evidence from application entitlement. A federated identity can establish which account authenticated, but its claims do not automatically define the application's tenant membership, object ownership or approval hierarchy. Decide which claims are accepted, how they map to local identifiers and which business relationships are resolved independently. This is particularly important for partner users whose home organization controls attributes that the resource application might otherwise treat as authoritative.

The expense example illustrates why action naming needs care. An approve action might apply only to a submitted expense that the principal did not create and whose amount is within an approved scope. Changing the approver assignment is a separate operation because it changes the future authorization relationship. If both are collapsed into a broad edit action, the policy may allow a user to alter the facts that later make their own approval permissible.

Record relationships with the same care as scalar attributes. Membership in a team or placement beneath an organizational entity can influence a policy even when no explicit administrator flag exists. Review who can create or remove those relationships and whether the supplied entity graph represents the relevant current state. A trustworthy value at the wrong point in its lifecycle can still produce an unintended authorization decision.

Context should describe request-specific information with a defined source and meaning. Avoid treating it as an unrestricted bag of client-supplied facts that policies can trust opportunistically. For example, if a policy depends on a workflow state, resolve whether that state belongs to the persisted resource or to a claimed client request. Naming the distinction in the schema and request-construction code prevents a later policy author from accidentally depending on the weaker source.

Document what happens when a required entity is unavailable. An unavailable lookup should not be silently replaced with an empty or default object that changes policy meaning. The application can reject, retry or use an explicitly supported alternative according to its requirements, but that behavior needs a deliberate contract. Otherwise, an infrastructure failure can become an unreviewed change to the authorization inputs rather than an observable request failure.

Choose the tenant policy-store boundary

AWS's multitenant guidance discusses shared and per-tenant policy-store designs. The choice affects isolation, policy management and operational scale. A shared store centralizes some configuration, while separate stores establish a policy-storage boundary between tenants and require the application to route each request to the correct store. Neither choice removes the need for correct application resource identification and trustworthy entity data. ^[2]

In a shared store, tenant restrictions must be expressed and supplied correctly throughout the model. Review how the principal's tenant and the resource's tenant are established, and how policy authors prevent a request from crossing that boundary unintentionally. A common schema can simplify consistency, but it can also distribute the effect of a mistaken shared assumption. The relevant question is which policy or input error could affect more than the intended tenant.

Per-tenant stores change that exposure, but they introduce an important routing obligation. The application must select the store using trusted tenant context, not simply a store identifier sent by the client. A correctly written policy in the wrong store is not a satisfactory outcome. Tenant onboarding, deletion and migration also need an inventory that connects the application tenant to the intended policy-store state.

Compare the operating costs in terms of work that must be done, not invented financial or risk scores. Shared configuration may require fewer independent schema updates. Separate stores may require a rollout record that proves each tenant reached the intended version. The actual service quotas, account organization and tenant population should be evaluated for the deployment, but this article does not supply a fabricated break-even tenant count or a universal architecture recommendation.

The matrix identifies useful decision dimensions: isolation boundary, change distribution and the evidence needed to operate the design. It is a conceptual comparison based on AWS's documented patterns, not a benchmark of two implementations. Use it to ask which failure the organization is trying to contain and which maintenance process it can reliably support. A theoretical isolation advantage is less useful if the tenant-routing inventory is incomplete or routinely bypassed.

Keep this choice separate from compute isolation. Dedicated namespaces, clusters, accounts or databases may address other tenant boundaries, but their presence does not establish correct business authorization. An application with strong infrastructure separation can still select the wrong tenant object, and an application authorization service cannot compensate for every shared-runtime weakness. Record the interfaces between these controls rather than presenting one as a substitute for all the others.

Source. AWS, Verified Permissions multitenant design considerations, Shared and per-tenant policy-store tradeoffs. ^[2]; AWS, Verified Permissions policy templates, Template update behavior ^[6]; AWS, UpdatePolicyTemplate API, Eventual consistency notice ^[9]; Cedar, Cedar policy validation, Request validation expectations and schema changes ^[4].

Method. Original conceptual matrix synthesizing the cited documentation. It represents design relationships, not observed test results. Reviewed 2026-09-02.

Accessible table and figure data

Figure 1 accessible table

Decision	Shared store	Per-tenant stores
Isolation boundary	Tenant conditions and request selection share a policy store	Policy storage boundary separates tenants
Change distribution	Shared schema and template changes can affect many tenants	Rollout must reconcile each tenant store
Operating record	Prove tenant inputs and policy scope	Prove store routing and per-store version state

Figure 1 accessible table

Decision	Shared store	Per-tenant stores
Isolation boundary	Tenant conditions and request selection share a policy store	Policy storage boundary separates tenants
Change distribution	Shared schema and template changes can affect many tenants	Rollout must reconcile each tenant store
Operating record	Prove tenant inputs and policy scope	Prove store routing and per-store version state

Download imageDownload table CSV

Treat policy errors as a distinct result

Cedar's decision algorithm has three essential rules. A satisfied forbid policy produces Deny even when a permit is also satisfied. In the absence of a satisfied forbid, a satisfied permit can produce Allow. If no policy grants access, the result is Deny. These rules are useful because explicit prohibitions and positive grants have defined interactions rather than relying on an informal policy ordering convention. ^[5]

The fourth behavior that an application reviewer must understand is skip on error. If evaluating a policy produces an error, Cedar skips that policy when determining the result and includes the error in diagnostics. It does not automatically change the entire authorization response to Deny merely because one policy was erroneous. The distinction is explicit in Cedar's authorization documentation and should survive every simplified explanation of default deny. ^[5]

An erroneous forbid policy is the important counterexample. Suppose the hypothetical expense application has a permit that matches a manager's approval request and a forbid intended to stop self-approval. If the forbid fails during evaluation because expected data is missing or inconsistent, another satisfied permit can still lead to Allow. This is a conceptual consequence of the documented algorithm, not a reported vulnerability in Cedar or a claim that every missing attribute creates this result. ^[5]

The application must decide how to handle a response that contains diagnostics. It may choose to reject an otherwise allowed result when relevant evaluation errors are present, or apply another explicitly reviewed rule appropriate to the integration. Rejecting error-bearing responses is an original conservative design option, not Cedar's default behavior. It can also reduce availability, so describe the errors covered, the user-visible outcome and the operating response rather than adding a blanket catch-all without review.

Do not treat diagnostics solely as a troubleshooting convenience. Determining policies and evaluation errors help explain why the authorizer returned its result. Retain the information needed for a permitted investigation while avoiding unnecessary sensitive entity data. The exact telemetry contract depends on the application and service integration, but the record should distinguish a clean Deny, an Allow with diagnostics and a failure to obtain an authorization response at all. ^[5]

Those three outcomes imply different operating actions. A clean Deny may be an expected policy decision. An Allow with a skipped forbid can indicate a model or input defect. A network or service failure prevents the application from obtaining a decision under its normal contract. Converting all three to an indistinguishable access denied message can be reasonable for a user interface while still being inadequate for the operator who must repair the underlying condition.

Finally, keep the application's error policy from becoming an alternate authorization engine by accident. If application code starts reconstructing every permit and forbid condition from diagnostics, the system can accumulate two inconsistent policy implementations. Prefer an explicit response-handling rule and correct the model or supplied data that produced the error. The aim is an understandable boundary between evaluation and enforcement, not two drifting copies of the same business logic.

Validate the model and the request

Policy validation checks a policy against a schema. It can identify mismatched entity types, unsupported attributes and other mistakes before those policies affect requests. That is a valuable development and change gate, but it does not prove the policy expresses the intended business rule. A perfectly valid policy can authorize the wrong action if the model or rule was chosen incorrectly. ^[4]

Cedar also documents limits to what validation establishes. For example, validation does not guarantee that every entity referenced at runtime exists, and it does not eliminate every possible runtime error. The application must supply suitable entity data and conforming requests. Avoid describing a schema-valid policy set as impossible to error, especially when the deployment retrieves entities from several sources with different failure and update behavior. ^[4]

Write test cases from business requirements before selecting convenient examples that the policy already allows. For the expense application, include an approver acting on another person's submitted expense, the same approver attempting self-approval, a user from another tenant, an object in the wrong workflow state and a request with missing authoritative relationship data. The cases should identify the expected decision and the reason, not merely record the current engine output.

Separate negative authorization tests from malformed-input tests. A validly formed request from an unauthorized user should produce the intended policy denial. A request whose entity data cannot be trusted or assembled may need rejection before evaluation or through the application's error rule. Combining those cases under denied hides whether the security model worked or an incidental parser error stopped the action. Both can matter, but they establish different things.

Use the exact schema and policy versions intended for deployment. A test result from a previous schema can lose relevance after an attribute changes type, a relationship changes meaning or an action is broadened to another resource class. The test ledger should connect the request, supplied entity set and policy version to the expected outcome. This is an original proposed review artifact, not a feature that automatically appears merely because a store contains a schema.

Review the tests for assumptions about omitted data. If the fixture always supplies a convenient manager relationship, it cannot demonstrate what happens when the production lookup fails. If every resource uses one tenant identifier, it cannot demonstrate routing across tenants. Add cases that challenge the provenance and selection of the inputs, not only the syntax of the policy expression. Authorization failures often become clearer when the test names the authority responsible for each field.

No executed Cedar test suite is claimed here. Teams adopting executable examples should pin the actual Cedar library or Verified Permissions integration, use the supported validation interface and retain reproducible results. A policy example that merely parses is weaker evidence than a set of expected decisions with correct inputs, and neither proves that the application's eventual write path enforces those decisions.

Enforce at the API boundary

The application must turn the authorization response into an enforced decision on the actual operation. Amazon Verified Permissions documentation describes application integration rather than a mechanism that automatically intercepts every database write. Identify the server-side location that receives the request, resolves the principal and resource, calls the authorizer and either performs or refuses the action. The relationship between these steps is the core enforcement contract. ^[7]

Ensure that the checked resource is the resource actually used. An API can correctly authorize one object and later execute an operation against a different identifier taken from another parameter or message. Keep the resolved object identity attached to the operation through the enforcement point. This is a design recommendation that applies regardless of how expressive the policy language is; the authorizer cannot validate an object it was never asked to evaluate.

Consider state changes between authorization and action. A document can move to another workspace, an expense can change workflow state or a membership can be removed while a request is in progress. The application needs a consistency strategy appropriate to the operation, such as verifying relevant state at the write boundary. Do not assume that a remote authorization decision freezes the database or makes the following transaction immune to concurrent change.

Caching decisions creates another explicit contract. The cache key and validity must account for the facts that can change the result, including the principal, resource, action and relevant policy or entity state. A general cache of principal is allowed can be much broader than the request that produced it. This article does not prescribe a universal cache duration; the accepted staleness and invalidation mechanism are application-specific decisions that need evidence.

Background workers and alternate interfaces belong in the enforcement inventory. A web handler may call the authorizer while a scheduled task or internal API performs the same operation directly. Decide whether those paths act under their own service authority or on behalf of a user, and state how the business permission is checked in each case. Calling an endpoint internal does not explain which actor can invoke it or what authority it carries.

The architecture diagram therefore returns the decision to the application boundary before the business operation. It does not draw Cedar directly writing the application's data. Request construction, trustworthy entities, response handling and enforcement remain visible as distinct responsibilities. This also makes review easier when another protocol, such as an MCP server, carries the request: transport authorization and token checks still need the business operation's resource-level decision.

Source. AWS, Verified Permissions terms and concepts, Requests, entity data, schemas, policy stores and authorization responses. ^[3]; AWS, Implementing Verified Permissions authorization, Application enforcement and user interface decisions ^[7]; Cedar, Cedar authorization decisions, Default deny, forbid overrides permit and skip on error ^[5].

Method. Original conceptual architecture synthesizing the cited documentation. It represents design relationships, not observed test results. Reviewed 2026-09-02.

Accessible table and figure data

Figure 2 accessible table

Component	Role
Client request	Untrusted object reference
Application boundary	Select tenant and resolve entities
Cedar decision	Policy result and diagnostics
Business operation	Enforce on the same resource

Figure 2 accessible table

Component	Role
Client request	Untrusted object reference
Application boundary	Select tenant and resolve entities
Cedar decision	Policy result and diagnostics
Business operation	Enforce on the same resource

Download imageDownload table CSV

Roll out schema and template changes deliberately

A policy change can be local to one rule, but a model change can alter the meaning of many rules at once. Treat schema versions, entity producers, request construction and policies as related release inputs. A new optional attribute may require different handling from a renamed required attribute. The deployment plan should say which combinations can coexist and what the application does when it encounters an unexpected version rather than relying on an optimistic rollout order.

Template-linked policies have a documented shared-change behavior. Updating a Verified Permissions policy template changes its linked policies, and the documentation describes eventual consistency. That can reduce repetitive editing, but it also means a template update is not equivalent to changing one isolated tenant grant. Inventory which linked policies and tenants depend on the template before deciding the review and rollout scope. ^[6][9]

Do not assume every request observes the new template simultaneously. Where mixed observations matter, define how the application and policy rollout tolerate the transition or constrain the affected operation. The appropriate response depends on the business rule and the supported service behavior. This guide does not infer a fixed convergence deadline from the words eventually consistent or provide an invented delay after which every request is guaranteed to use the new rule. ^[9]

Retain the previous approved model and its compatibility assumptions. A rollback that restores an old policy may not work if the entity producer has already stopped supplying an attribute that the old policy expects. Similarly, returning the schema to an earlier version does not prove that new application code constructs earlier-compatible requests. Define rollback across the relevant components, not only the policy text stored in the authorizer.

For per-tenant stores, the release record should identify the observed version in each affected store. For a shared store, it should identify which shared policy or template changed and which tenant assumptions were tested. Both designs need a way to distinguish intended exceptions from stores or policies accidentally missed by the rollout. The operating model chosen earlier determines what complete means for the change, rather than letting the deployment tool choose that definition implicitly. ^[2][6]

Keep administrative authority separate from application decision authority. A principal allowed to request an authorization decision should not automatically be allowed to alter the schema, templates or entity sources that govern future decisions. Review who can make those changes and how they are approved. This is especially important where a user-facing administration feature changes memberships or role relationships without editing a Cedar policy directly.

Keep a reviewable authorization record

The final design record should answer a concrete question for each protected operation: which principal may act on which resource under which trustworthy facts? Add the policy-store routing rule, the source of every decision-relevant attribute, the response-handling behavior and the server-side enforcement point. These are enough to expose many gaps that a long list of role names or a screenshot of valid policies would leave ambiguous.

Attach expected allow, deny and error cases to the record. The distinction between those outcomes matters because Cedar's skip-on-error semantics can leave another permit effective. Reviewers should be able to see the input conditions for a case, the intended business result and the application's handling of diagnostics. A test suite whose only assertion is that something failed cannot establish that the intended authorization control caused the failure. ^[5]

Assign ownership where the model crosses teams. Identity administrators may own principal claims, application teams may own resource state and platform teams may operate the policy service. A change in any one source can invalidate the other's assumptions. The record should identify who approves an attribute's meaning and who responds when it is missing or stale, rather than allowing the policy author to guess which input remains trustworthy during an outage.

Preserve the limits of the evidence. Documentation establishes Cedar and service behavior within their stated scope. A local test can establish outcomes for the supplied cases. An integration test can add evidence that the application uses and enforces those outcomes. None alone proves that every business rule, tenant and alternate execution path is correct. Claim the layer actually checked and keep the remaining acceptance work visible.

The value of Cedar is not that it removes the need to understand authorization. It gives a structured place to express and evaluate a model that the application must still own. When entity provenance, tenant boundaries, error semantics and enforcement are explicit, policy changes become easier to review and failures become easier to explain. Writing the first policy after those decisions is a practical way to make the resulting system more coherent.