---
title: "The Cerbos Hub effect matrix: read your authorization policy at a glance"
description: "See how the Cerbos Hub effect matrix turns authorization policy files into a permissions grid of roles and actions, with allowed, denied, and conditional outcomes. Read what each role can do without parsing raw policy, drill into ABAC conditions, and spot over-permissive wildcard rules in review."
author: "Alex Olivier"
date: "2026-06-30T11:01:14.713Z"
canonical: "https://www.cerbos.dev/blog/cerbos-hub-effect-matrix-read-authorization-policy-at-a-glance"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/The_Cerbos_Hub_effect_matrix_read_your_authorization_policy_at_a_glance_33621a3f86.png"
tags: ["announcement","documentation","engineering","guide"]
source: "https://www.cerbos.dev/blog/cerbos-hub-effect-matrix-read-authorization-policy-at-a-glance"
---

# The Cerbos Hub effect matrix: read your authorization policy at a glance

Authorization policy is one of the few parts of an application that the whole business has an opinion on. Product owners decide who should be able to do what. Compliance teams need to confirm that an auditor role can read but never write. Support engineers get asked, on the spot, whether a given customer tier can actually reach a feature. All of those people are asking the same shape of question, and it's a simple one. For this role, on this resource, what actions are allowed?

The trouble is that the answer usually lives in policy files. A resource might have a dozen rules, a few derived roles, and conditions layered on top. Reading that fluently takes someone who works with policies every day. Everyone else ends up either trusting the engineer's summary or opening a ticket. Neither is great when the question is about who can touch sensitive data.

So we built a view in [Cerbos Hub](https://hub.cerbos.cloud/) that answers the question in the form people actually ask it.

## A permissions grid, not a pile of policy rules

On the Policies tab of a deployment there's now a toggle between *Source* and *Effect matrix*. Source is what you'd expect, the policy files as they were compiled into the bundle. The effect matrix takes the same compiled policy and lays it out as a grid. Roles down one axis, actions across the other, and every cell tells you the outcome for that combination. Allowed, denied, or conditional.

That small reframe changes who can read the policy.

A product manager doesn't need to know how rules are structured to scan a row and see exactly what an editor can do. A compliance reviewer can look down the delete column and confirm that only the roles that should have it, have it. 

The policy stops being something you take on trust and becomes something you can read at a glance, which is roughly the goal we had when we wrote about mapping [business requirements to authorization policy](https://www.cerbos.dev/blog/mapping-business-requirements-to-authorization-policy) in the first place.

![cerbos-hub-effect-matrix-policy-grid.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/cerbos_hub_effect_matrix_policy_grid_369b2e9a17.png)

## The conditional cell that says "it depends"

Most real policies aren't a clean yes or no. An owner can edit a document, but only inside their own tenant. A reviewer can approve a claim, but only under a certain value. That conditional logic is where [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) earns its keep, and it's also where a flat permissions table would normally fall down, because the honest answer to "can this role do this" is "it depends on the request".

The matrix doesn't paper over that. A cell whose outcome depends on a [condition](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) is marked as conditional rather than forced into an allow or a deny. Select it and you drill into the rules behind it, including the condition itself, so you can see precisely what has to be true at request time for access to be granted. 

The business reader gets the at-a-glance answer, and the person who needs the detail gets the detail, without switching back to reading raw files.

![cerbos-hub-effect-matrix-conditional-abac-rule.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/cerbos_hub_effect_matrix_conditional_abac_rule_d825b73bfe.png)

## When a wildcard rule quietly widens access

There's one more thing the grid surfaces that's easy to miss in source. Wildcards. A rule written against `*` or a pattern like `documents:*` quietly widens what a more specific cell allows, and that breadth is exactly the kind of thing you want to catch in review rather than in production. 

The matrix flags the cells a wildcard rule reaches into, so a broad grant shows up as a broad grant instead of hiding inside a pattern. It's an indication of which rules match a cell, not a full evaluation, but it's enough to make an over-permissive rule obvious.

## Why a policy matrix matters beyond the demo

Authorization tends to [drift](https://www.cerbos.dev/blog/authorization-failure-patterns#:~:text=tooling%20to%20detect-,drift,-%E2%80%94the%20gap%20between). A role picks up an action for a one-off launch, a wildcard gets added to unblock a release, and six months later nobody is quite sure what the policy actually grants. The usual answer is an [audit log](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) review after the fact. 

The matrix gives you a way to look at the current state of a deployment and check that what's allowed still matches what you intended, in a format you can put in front of someone who doesn't write policy.

That's the point of moving authorization out of application code and into a [shared policy layer](https://www.cerbos.dev/blog/why-external-authorization). Once the rules live in one place, you can build views on top of them that serve more than just the engineers who wrote them. The effect matrix is one of those views, and it's live now for any deployment in Cerbos Hub.

[**Try Cerbos Hub**](https://hub.cerbos.cloud) to see the effect matrix against your own policies, or [**book a call**](https://www.cerbos.dev/workshop) to walk through it with the team.

## FAQ

### What is a permission matrix?  

A permission matrix is a grid that maps roles or users against actions and resources, where each cell shows whether that combination is allowed, denied, or conditional. It gives you a single centralized view of who can do what, rather than reading permissions one rule at a time. Teams use it to define, validate, and document access logic so the policy is clear to people who do not work in it every day. In Cerbos Hub, the effect matrix renders your live authorization policy as exactly this kind of grid, roles down one axis and actions across the other.

### How does a permission matrix help with security audits and compliance? 

A permission matrix helps with security audits and compliance by giving reviewers a clear, centralized view of access that they can check against intent without reading code. A compliance reviewer can look down the delete column and confirm only the roles that should have it do, and an auditor can see at a glance where access is broad. It also surfaces drift, since roles pick up actions and wildcards get added over time, and a [wildcard](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits) grant that widens access shows up plainly in the grid. Used alongside [audit logs](https://www.cerbos.dev/blog/why-audit-logs-are-important), the Cerbos Hub effect matrix lets you confirm the current state still matches what you intended.

### What is the effect matrix in Cerbos Hub?  

The effect matrix in Cerbos Hub is a view that lays your compiled authorization policy out as a grid, with roles down one axis and actions across the other. Every cell shows the outcome for that role and action combination, marked as allowed, denied, or conditional. It takes the same policy that compiled into your bundle and reframes it so you can read who can do what without parsing raw policy files. It is live now for any deployment in Cerbos Hub.

### How is the effect matrix different from reading authorization policy source files? 

The effect matrix differs from reading source files by reframing the same compiled policy as a permissions grid instead of a list of rules. On the Policies tab of a deployment you toggle between Source, which shows the policy files as they were compiled into the bundle, and Effect matrix, which lays that policy out as roles by actions. A product manager or compliance reviewer can scan a row or a column to see exactly what a role can do, rather than needing to read a dozen rules, derived roles, and layered conditions fluently.

### How does a permissions matrix help catch authorization drift?  

A permissions matrix helps catch authorization drift by showing the current state of a deployment in a format you can check against what you originally intended. Authorization tends to drift as a role picks up an action for a one-off launch or a wildcard gets added to unblock a release, and six months later nobody is sure what the policy actually grants. Instead of relying only on an [audit log](https://www.cerbos.dev/blog/why-audit-logs-are-important) review after the fact, the effect matrix lets you confirm that what is allowed still matches what you intended, in a view you can put in front of someone who does not write policy.

### Who can read the Cerbos Hub effect matrix without writing policy?  

The Cerbos Hub effect matrix can be read by anyone who needs to understand access without writing policy, including product managers, compliance reviewers, and support engineers. Because authorization lives in a shared policy layer rather than buried in application code, Cerbos can build views on top of the rules that serve more than the engineers who wrote them. A product manager scans a row to see what an editor can do, and a compliance reviewer looks down the delete column to confirm that only the right roles have it, all from the same [externalized authorization](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits) policy.