Who can do what — whether every sensitive action and record checks the caller's permission, not just that they are logged in.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge whether the app enforces authorization — that every sensitive action and record verifies both who the caller is and whether they are allowed, on the server, by default.
Read-only pass. Trace routes, middleware, and data access; run read-only checks; change nothing. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
logged-in treated as allowed; endpoints behind auth with no permission check
an id taken from the request and trusted without an ownership check
admin or privileged actions reachable by ordinary roles
one customer's data reachable from another's session in a multi-tenant app
checks done only in the UI, bypassable by calling the API directly
new routes and resources default to open rather than deny-by-default
role changes, impersonation, or token scopes that let a user climb
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List the roles/permissions the system recognizes and where they are checked.
Cite the route, handler, or query for every finding.
Rank by what a finding unlocks.
Create ACCESS.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:access-control-audit.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-access-control-audit:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=82 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/82.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Access-Control & Authorization Audit You are working inside this repo. Mission: judge whether the app enforces authorization — that every sensitive action and record verifies both who the caller is and whether they are allowed, on the server, by default. Read-only pass. Trace routes, middleware, and data access; run read-only checks; change nothing. Your only write is the report file. ## Phase 1 — Map the access model - List the roles/permissions the system recognizes and where they are checked. - Enumerate sensitive resources and actions: records, admin functions, money movement, data export. - Trace one request end to end: where is identity established, and where is permission decided. ## Phase 2 — Audit through 7 lenses Cite the route, handler, or query for every finding. 1. **Authn ≠ authz** — logged-in treated as allowed; endpoints behind auth with no permission check 2. **Object-level access (IDOR)** — an id taken from the request and trusted without an ownership check 3. **Function-level access** — admin or privileged actions reachable by ordinary roles 4. **Tenant isolation** — one customer's data reachable from another's session in a multi-tenant app 5. **Server-side enforcement** — checks done only in the UI, bypassable by calling the API directly 6. **Default posture** — new routes and resources default to open rather than deny-by-default 7. **Escalation paths** — role changes, impersonation, or token scopes that let a user climb ## Phase 3 — Curate - Rank by what a finding unlocks: cross-tenant data or admin access outranks a self-scoped leak. - For each gap, name the exact check missing and where it belongs in the request path. - Prefer one enforced choke point over a check sprinkled per handler. ## Phase 4 — Report Create `ACCESS.md` at repo root: 1. **Access map** — role × resource × action, with where each is enforced 2. **Findings** — each: severity S1–S3 · location · who can reach what · the missing check · fix 3. **Deny-by-default gaps** — resources that should be closed until explicitly opened 4. **Proof cases** — the request each fix should now reject, ready to turn into a test Start the report with today's date. If `ACCESS.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Identity is not permission; every sensitive path needs both - Enforce on the server; the client is a convenience, not a control - No authentication or authorization in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which authorization gaps to close first
reports/ directory exists at the repo root, write the report there instead of the root.A defensive review of your own codebase — auth gaps, injection surfaces, exposed secrets, and data leaks, ranked by exploitability.
Vulnerable, abandoned, oversized, or duplicated packages — the full health check on every dependency this project stands on, with removal candidates named.
Keyboard navigation, contrast, labels, and screen-reader flow — audited end-to-end along the core user journey.
Hardcoded strings, locale-blind number and date formatting, and layouts that break in translation — every gap between you and a non-default-locale user.
Runs inside these playbooks — curated sequences you can launch with one paste: