Policy Designer - Policy Analysis

Policy Analysis

Agama Lab provides a policy analysis tool built on top of the Cedar Analysis Tool (symbolic compilation). It helps identify duplicate policies, policies that accept the same request and response, or policies that allow and deny all requests.

A few things worth knowing before you start:

• Analysis is schema-relative. The checks are performed against the schema of your policy store, so make sure your schema is up to date.
• true is not always good news. Each check answers a yes/no question. For checks like Always Allows, a true answer is exactly what you want to know. Read the message next to the result; don’t just look for a green icon.
• Run it before you release. The best time to analyse your store and policies is before you release the policy store to GitHub and Cedarling consumes it.

Agama Lab exposes the analyzer in two places:

1. Store Analysis, for the policy store as a whole
2. Policy Analysis, for a single policy compared against the rest of the store.

Store Analysis

Store Analysis looks at all the policies in your store. You will find the Analysis button at the top of the store management page.

When the dialog opens, it presents six reports as tabs.

• The first three — Never Errors, Always Allows and Always Denies — run automatically as soon as the dialog opens on all available policies.
• The last three — Equivalent, Implies and Disjoint — compare two policy sets that you build by drag and drop, so you run them on demand.

1. Never Errors

Never Errors checks whether a policy can ever throw an error during evaluation. Cedar policies can fail at runtime — for example, when an expression reads an attribute that an entity does not have, or performs an operation on a value of the wrong type. A policy that errors is neither allow nor deny; it is simply skipped, and the decision quietly falls through to whatever else applies.

The report lists every policy in the store with its Severity, the analyzer’s Message, and the Result. Click a policy name to inspect its content without leaving the dialog.

2. Always Allows

Checks whether your policies allow every authorization request the schema can express.

• Result true — the policy set allows all requests. Effectively, this is an open door: a potential security risk that deserves a second look.
• Result false — the policy set does not allow all requests. This is the normal, expected outcome.

Common cause: a permit policy with unconstrained scope and no conditions, such as permit(principal, action, resource);, which is convenient during development and dangerous in production.

3. Always Denies

The mirror image of the Always allows checks: it verifies whether your policies deny every authorization request.

• Result true — nothing is ever allowed; double-check your policy and policy conditions.
• Result false — at least some requests are allowed, as expected.

Comparing two policy sets

The remaining three reports compare Policy set 1 against Policy set 2. Drag and drop policies from the store into the two sections to build the sets, then click the Run … Analysis button. The same two sets are reused across the Equivalent, Implies and Disjoint tabs, so you can build them once and ask all three questions.

4. Equivalent

Checks whether policy set 1 and policy set 2 allow exactly the same set of authorization requests.

• Result true — in this case, the two sets are interchangeable. One of them is redundant, and you can safely remove either set.
• Result false — there is at least one request the two sets treat differently.

Typical use: you want to replace three overlapping policies with one cleaner policy. Put the old three in set 1, the new one in set 2, and confirm the result is true before deleting anything.

5. Implies

Checks whether every authorization request allowed by policy set 1 is also allowed by policy set 2 — in other words, whether set 2 is at least as permissive as set 1.

• Result true — set 1 grants nothing that set 2 does not already grant. Set 1 adds no new access on top of set 2, so it may be redundant.
• Result false — set 1 allows something set 2 does not, so it genuinely widens access.

Typical use: proving that a change does not expand access. Put the new version in set 1 and the current version in set 2; a true result means the change grants nothing new.

6. Disjoint

Checks whether policy set 1 and policy set 2 allow completely separate sets of authorization requests.

• Result true — the two sets never both allow the same request; there is no overlap at all.
• Result false — the sets overlap, and at least one request is allowed by both.

Typical use: confirming that responsibilities are cleanly separated — for example that your “customer” policies and your “back-office admin” policies really do cover different ground.

Policy Analysis

The store analysis tool helps you analyse your custom policy sets, but the policy analysis tool shows how does this one policy relates to everything else already in a store.

In the policy list grid, each row has an analysis icon next to the edit and delete actions.

Click it to open the analysis dialog. The run starts immediately and compares the selected policy against all the other policies of the store; the selected policy itself is excluded from the comparison set, since a policy is always equivalent to itself.

The result comes in two parts:

Policy Store Analysis — the selected policy against all other policies taken together as a single set. This is the high-level verdict, shown as Always Allows, Always Denies, Implies, Equivalent and Disjoint. Hover over any result to see what that outcome means for this policy.

Policy Comparison Analysis — the same policy against each other policy individually, one row per policy, with the Implies, Equivalent and Disjoint columns. This is where you find out which policy your new one duplicates, not merely that it duplicates something. Click a policy name to read its content.

How to read the outcomes:

Two details worth remembering:

• If the store contains no other policy — for example when you add the very first one — there is nothing to compare against, so only the checks that apply to the policy on its own (Always Allows and Always Denies) are reported.
• Use Re-check to run the analysis again, for instance after editing a policy in another tab.

Analysis while writing a policy

You do not have to wait until a policy is saved. In the policy editor, the Analyze & Check button runs the same comparison analysis on the policy you are drafting, and shows the results inline below the editor.

The editor deliberately puts the analysis on the path to saving:

1. Write your policy in the editor.
2. Click Analyze & Check. The results appear under the editor, and the Save button becomes available.
3. Review the findings. If you change the policy afterwards, the previous results no longer apply and are cleared — click Re-check to analyze the new version.
4. Save once you are satisfied with what the analysis reports.

The results are informational: a warning never blocks you from saving. An Implies or Equivalent finding may be perfectly intentional, and only you know the intent. What the flow guarantees is that you have seen the findings before the policy lands in your store.