No ABAC rule grants the permission (no_matching_rules)
A denied decision with the code no_matching_rules means the user matched at least one user set and the resource matched at least one resource set, but no attribute-based access control (ABAC) rule grants the checked action between them. This page is for developers who find this code in a decision log and need to fix the ABAC policy or the check.
What the no_matching_rules reason means
The policy decision point (PDP) writes this code in the ABAC part of the decision log's debug details (debug.abac). The debug details appear when Debug Mode is on.
| Field | Value |
|---|---|
code | no_matching_rules |
reason | user '<user-key>' does not match any rule that grants him the '<action>' permission on the given resource of type '<resource-type>' |
matching_usersets | The user sets the user matched |
matching_resourcesets | The resource sets the resource matched |
support_link | A link to /errors/no_matching_rules on docs.permit.io |
The PDP runs its ABAC checks in a fixed order and reports the first one that fails. When you see no_matching_rules, the earlier checks passed:
- The user matched at least one user set. Otherwise the code is no_matching_usersets.
- The resource matched at least one resource set. Otherwise the code is no_matching_resourcesets.
Only the last step failed: no rule grants the action from any of the matching_usersets on any of the matching_resourcesets.
A role-based access control (RBAC) denial has a different code. For a user whose roles don't grant the action, see No role grants the permission (no_permission).
Causes of no_matching_rules
| Cause | How to confirm | Fix |
|---|---|---|
| No rule connects the matched user set and resource set for this action. | In the Policy Editor, the checkbox for the action is clear where the user set row meets the resource set column. | Grant the action to the user set. |
| The rule grants the action on a different resource set than the one the resource matched. | The granted resource set is missing from matching_resourcesets. | Grant the action on a resource set in matching_resourcesets, or change the resource attributes so the resource matches the granted resource set. |
| The rule grants the action to a different user set than the one the user matched. | The granted user set is missing from matching_usersets. | Grant the action to a user set in matching_usersets, or change the user attributes so the user matches the granted user set. |
| The check uses a different action key than the one the rule grants. | The action in the reason differs from the action you granted. | Send the action key the rule grants in permit.check(). |
Fix no_matching_rules
Grant the action to the user set in the Policy Editor
- Open the Policy Editor in the Permit dashboard.
- Find the row for a user set from
matching_usersets. - In the column of a resource set from
matching_resourcesets, select the action from thereason. - Click Save.
For a full walkthrough, see Grant permissions in Building your first ABAC policy.
Grant the action to the user set with the API
Create a condition set rule with the Assign set permissions endpoint. The body names the user_set, the permission in the <resource-type>:<action> form, and the resource_set. For a complete request, see Assign condition set rules with the API.
Confirm the fix
- Run the same
permit.check()call again with the same user, attributes, action, and resource. To run the check from a terminal, usepermit pdp check. - Open the Audit Log and select the new decision.
The decision is allowed, and debug.abac has the code allow.