Supabase RLS Launch Gate (Pre-Launch Security Check)

The problem\n\nThe most common Supabase breach is simple: a table in public with Row Level Security off, or a policy written as using (true). Anyone holding the public anon key can then read or write every row. It is easy to miss across dozens of migrations.\n\n## What it does\n\nYour agent replays your supabase/migrations in order (so a later DROP POLICY or DISABLE ROW LEVEL SECURITY counts) and returns a PASS / BLOCK verdict with a per-table status and file:line evidence for each finding.\n\nBlockers\n- public table with RLS off\n- Write policy (insert/update/delete) that is true for anon or authenticated\n- Policy that trusts user_metadata, which the signed-in user can edit\n\nWarnings\n- Public read of all rows (fine if intended, but check for private columns)\n- Policy that only checks auth.role() = 'authenticated' (every signed-up user can act on every row)\n- UPDATE WITH CHECK that does not tie the row to its owner\n- Views without security_invoker = true (they skip RLS)\n- SECURITY DEFINER functions without a pinned search_path, and ones exposed in public\n\nEvery finding includes the fix, written as a migration for you to review, such as owner-scoped policies using (select auth.uid()) = owner.\n\n## Safe by design\n\nIt only reads .sql files. It never connects to your database, never runs SQL and never applies fixes. Works on migrations or on a schema dump you make yourself with supabase db dump.\n\n## Checked against a real database\n\nThe bundled test fixtures were applied to a real PostgreSQL 16 server with Supabase-style anon and authenticated roles, and then actual reads and writes were attempted as each role. All 8 verdicts matched what the database really allowed. 17 further tests cover parsing edge cases (dollar-quoted function bodies, quoted identifiers from db dump, replaced policies, views and functions).\n\n## Requirements\n\nPython 3.8+ standard library only. No network, no packages.\n\n## Limits\n\nStatic analysis of SQL text: dashboard edits not in your migrations are invisible (use a dump). Column-level grants, Storage (storage.objects) policies, Edge Functions and service-role key usage are not analysed. Policy conditions are classified by pattern, not evaluated, so a PASS is not a full security audit.