Engineering

Permission Matrix Prompt

Make access auditable — a roles-by-actions matrix that shows exactly who can do what, exposes the gaps and over-grants, and becomes the spec the code is checked against.

Overview

Authorization that lives only in code is impossible to audit — no one can answer 'who can delete this?' without grepping. This prompt builds a permission matrix: roles across the top, actions/resources down the side, allow/deny in every cell, with the over-grants and missing denies flagged. It's the artifact that turns access control into something you can review and the code into something you can check against.

Why This Works

A matrix makes over-grants visible that code review can't see
Forcing every sensitive cell to be explicit removes silent default-allow
It becomes the spec the implementation is checked against

Best for

Systems where access mistakes are costly
Compliance or security reviews needing an access map
Teams that can't currently answer 'who can do X?'

Not for

Designing the roles themselves — use the RBAC Design Prompt
Reviewing the implementation — use the Authorization Review Prompt

Use cases

Documenting who can do what across roles
Auditing access control for over-grants
Producing the spec authorization code is reviewed against

Customize This Resource

Opens this resource in the related tool with the fields pre-filled. Customize role, tone, and behavior rules — then generate your prompt.

Prompt Template

ROLE
You are building a permission matrix that makes a system's access control auditable.

INPUT
Roles and operations:
[The roles in the system and the sensitive actions/resources]

BUILD THE MATRIX
1. AXES: roles across the top; actions (verb + resource) down the side.
2. CELLS: ALLOW / DENY / CONDITIONAL for every role-action pair. Conditional cells name the condition (e.g. 'own records only').
3. SCOPE COLUMN: for each action, whether allow means all records or only owned/scoped ones.
4. FINDINGS: flag the over-grants (a role with more than its job needs), the missing denies (sensitive actions with no explicit deny), and any action no role can perform (orphaned).
5. SENSITIVE ROWS: call out the highest-risk actions (delete, export, impersonate, change-permissions) and confirm each is tightly scoped.

RULES
- Every sensitive action must be explicit for every role — no blank cells.
- Least privilege: justify any ALLOW on a high-risk action.

OUTPUT
The full matrix, then a findings list (over-grants, missing denies, orphaned actions) ranked by risk.

Related Resources

Explore more resources that work well with this one.

Related Tools

Multi-Step Prompt Builder

Part of these Blueprints

End-to-end build journeys that use this resource.

Build an API Backend with AI Blueprint · 9 stages Build a Marketplace with AI Blueprint · 9 stages

Used in Playbooks

Complete workflows that include this resource as a step.

AI Auth & Identity Workflow Workflow · 4 steps

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources