The Access Explorer (under Authorization → Analyze) answers one question: "Can X do Y on Z?" — and shows the full reasoning trail so you can see exactly why the answer came out that way. It's the page you open when a user reports "I can't do this thing I should be able to do."
Subject: user_01h7p3n6t8y2qrv4xkc5jbqe7w (alice@acme.com)
Permission: invoices:update
Tenant: tenant_acme
→ Allowed
├─ Role: Member (global)
│ └─ Policy: Invoices Writer
│ └─ Permission: invoices:update ✓
└─ Direct grant: editor on invoices/inv_2024_03 ✓
The form on the page mirrors this output — pick the user, the permission, optionally a tenant or a specific resource ID, hit Check, see the verdict and the trace.
A successful check shows the path that granted the permission. Each step has a checkmark; missing checkmarks mean the path didn't contribute. A typical "yes" looks like:
✓ Allowed (1.2 ms)
User: alice@acme.com → invoices:update in tenant_acme
Roles assigned:
✓ Member (global)
Policies attached: 2
✓ Invoices Writer
Permissions: invoices:create, invoices:read, invoices:update, invoices:send
└─ matched: invoices:update
• Reports Viewer
(no matching permission)
• Viewer (tenant_initech)
(different tenant — not considered)
Direct grants on this resource: none.
A denial trace lists every place the permission could have come from but didn't:
✗ Denied (0.9 ms)
User: alice@acme.com → invoices:delete in tenant_acme
Roles assigned:
• Member (global)
Policies attached: 2
• Invoices Writer (no matching permission — closest: invoices:update)
• Reports Viewer (no matching permission)
• Viewer (tenant_acme)
Policies attached: 1
• Invoices Reader (no matching permission — read-only)
Direct grants on this resource: none.
Suggestion: attach a policy with `invoices:delete` to one of Alice's roles,
or grant her `owner` on this specific invoice via a direct relationship.
The "closest match" hint and the suggestion are heuristics — they don't always identify the exact fix, but they typically point at the right policy.
/explain is heavier than /check — it loads every role, every policy, and every relevant relationship, not just enough to short-circuit. Use it for debugging and audit UIs, not for hot-path checks.
"This user should have access — why doesn't it work?"
Open Access Explorer with their user ID and the permission they need. The denial trace usually points at the missing policy or the wrong tenant.
"This user shouldn't have access — why do they?"
Same form, the verdict is "Allowed", scan the trace for the role or direct grant that's responsible. If it's a role you didn't expect, check the role's assignments page.
"Did the recent role change break anything?"
Check a few representative users for the permissions you cared about, both before and after the change. Saves emergencies after a Friday refactor.
"My API call returns Forbidden but the user is in the right group."
Compare the request — Bearer token, tenant context, resource ID — against the explorer's check. Half the time it's a missing tenantId in the API call, not a permissions issue.
