SaaS authorization: who may do what, and the threats every app has

How a multi-tenant app decides who may act on what, and the classes of threat every such app has whatever it does. The rules were learned building several products with coding agents on Next.js (App Router) + Supabase Postgres + Clerk + Netlify. Among them were a live Q&A product with an anonymous audience and a monitoring product with API tokens and background workers. Each rule carries the date and the incident that produced it. They appear here only as examples, named by kind.

Every principle is stated first so that it holds on any stack. The Clerk, Supabase or Next mechanism comes second; a reader on another stack keeps the principle and substitutes their own mechanism. The vendor mechanics in depth are in clerk-production and supabase-production.

What binds, in order

1. The product's declared shape. What a workspace is (an organization, or one user), whether it bills, whether it has an anonymous public, whether it embeds agents. Everything below reads through it. Write it down before the first migration, in the product's agent instructions, where every session reads it.
2. This skill: the model and the threat classes.
3. The product's permissions doc, the capability × actor matrix (references/documents-and-tests.md). It is the intent an audit compares the code against (intended-vs-implemented, security-audit-static). Beside it sit the architecture doc (what exists: routes, ownership, invariants, known risks), the flows doc (the journeys where permissions, money or personal data are exercised) and the backlog (deferred work, each with the trigger that reopens it). What each must say about authorization is in the same file; shipping-artifacts defines the core set.
4. The vendors' own agent skills, for the API only, never for the access model. Where their defaults contradict this skill, this skill wins. Examples: RLS policies written to match an access model, @supabase/ssr and a browser key, a middleware path list deciding who may see a page.

The model on one page

The full rule, its reason and its receipt for each is in references/model.md.