The Policy Evaluation Engine
Every administrator can inspect why a specific permission is, or isn't, granted to a specific user. This module walks through how that answer is actually computed.
The 6-Step Evaluation Order
Computing whether a specific action is allowed follows the same order every time:
Start from nothing
By default, an action is denied. It has to be explicitly granted by something below for the answer to become Allow.
Union the identity's grants
Combine everything granted by every policy attached directly to the user, through every group they belong to, and through every role they hold. If the user is currently operating under an assumed role, this step uses only that role's grants in place of their everyday access, not in addition to it.
Check for an explicit deny
If any policy in that union explicitly denies the action, the answer is Deny, regardless of how many other policies would have allowed it.
Check the organization guardrail
If a guardrail denies the action, the answer is Deny. A guardrail can only take permissions away; it never overrides step 3 by granting anything.
Check the personal permission ceiling
If the user (or their role) has a ceiling attached and it denies the action, the answer is Deny. Same rule as the guardrail: restrict only, never grant.
Match the resource and scope
For an action with resource and/or scope restrictions, the specific target has to fall within what was granted on both axes. Only then does the answer become Allow.
Guardrail vs. ceiling order isn't fixed
Explicit Deny Always Wins
An explicit deny in any attached policy overrides any allow from anywhere else in the union, no matter how many other policies, groups, or roles would have granted the action.
One deny beats every allow
siem:loganalysis:read is still fully blocked from that action if even one attached policy carries an explicit Deny on it.Guardrail & Ceiling Checks
Both layers are deny-only. Neither can grant an action the identity's own policies didn't already allow:
| Identity Grants | Guardrail | Ceiling | Final Decision |
|---|---|---|---|
| Not granted | Doesn't apply | Doesn't apply | Denied |
| Granted | Denies it | Doesn't matter | Denied |
| Granted | Doesn't apply | Denies it | Denied |
| Granted | Doesn't apply | Doesn't apply | Allowed |
Identity Grants Union
Step 2's union combines three sources: policies attached directly to the user, policies inherited from every group the user belongs to, and policies granted by every standard role the user holds. When an assumed role is active, that role's policies replace the union entirely for the duration of the session, on top of which the organization's guardrails still apply.
Two-Axis Target Match
Once an action clears steps 1 through 5, an action that supports resource and/or scope restriction still has to match the specific thing being acted on: the target (an asset, a case) has to fall within what was granted on the resource axis, and the caller's own context has to satisfy the scope axis, before the answer is Allow.
The Effective Permissions Panel
A user's detail page includes an Effective Permissions panel showing, module by module, exactly what that person can and can't do, and the specific reason for each result:
- Granted - which policy (direct, group, or role) granted it.
- Denied - which policy carried the explicit deny.
- Blocked - which guardrail or ceiling blocked it.
If the user holds any assumable roles, the panel can also simulate what their permissions would look like while one of those roles is active, without actually having to assume it.