Resource
Markdown Output Prompt — Lock the Document Structure
The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.
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.
How to use this resource
-
Define the roles and actions
List the roles in the system and the sensitive actions and resources they might touch. The matrix is built from these two axes.
-
Open this resource in Markdown Output Builder
Load the prompt into Markdown Output Builder and fill in your roles and actions. It returns the allow/deny matrix as a clean Markdown table you can drop into your docs.
-
Review the matrix and findings
Walk the allow, deny, and conditional cells, then read the flagged over-grants, missing denies, and orphaned actions, ranked by risk.
-
Close the gaps before you build
Resolve the over-grants and missing denies the matrix exposes, then use it as the spec your authorization code is checked 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
FAQ
What exactly does this prompt produce for each role-action pair?
One cell marked ALLOW, DENY, or CONDITIONAL, where conditional cells name the condition (e.g. 'own records only'), plus a scope column stating whether allow means all records or only owned/scoped ones. The markdown-output-builder returns this as a clean Markdown table. It's a documented spec to review against your code — a plan, not a validated check of what your system actually enforces.
How does this matrix surface access problems I can't see in code review?
The FINDINGS step flags over-grants (a role with more than its job needs), missing denies (sensitive actions with no explicit deny), and orphaned actions no role can perform, ranked by risk. The RULES force every sensitive action explicit for every role — "no blank cells" — removing silent default-allow. Treat the flagged findings as items to resolve and confirm in code, not as a security certification.
Will this prompt design my roles or audit my authorization implementation?
Neither — it maps existing roles against actions. notFor is explicit: designing the roles is the RBAC Design Prompt, and reviewing the implementation is the Authorization Review Prompt. This one takes roles and sensitive actions you supply and builds the allow/deny matrix, calling out high-risk rows like delete, export, impersonate, and change-permissions to confirm each is tightly scoped.
More resources from Markdown Output Builder
Resource
README Prompt Template
Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.
Resource
API Documentation Prompt
Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.
Resources that pair well
Resource
Executive Summary Prompt
Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.
Resource
Force JSON Output from AI
Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.
Resource
Fix Invalid JSON from AI
The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.
Related tools
Tool
Markdown Output Builder
Build prompts that produce documents in a fixed structure — headings, sections, and tables.
Projects that use this resource
Project
Build an API Backend with AI
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.
Project
Build a Marketplace with AI
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
Workflows that use this resource
Workflow
AI Auth & Identity Workflow
Design access control before you build it, not after a breach — choose the authentication approach, model the roles and permissions, review the design for gaps, then document the identity model.
Guides for this resource
Guide
How to Design an Access-Control Model (RBAC) With AI
Both of them logged in successfully. One of them is looking at a ticket from another company's workspace. Here's how to turn your real actors, resources and actions into a reviewable RBAC model and a permission matrix where every cell says allow, deny, or on what condition.