AI coding agents write a clean create table , add a foreign key, and move on. They skip row-level security because the query works from the SQL editor and the type generator is happy. That table is then reachable through the Data API by any role that has a grant. The Supabase API security guide is blunt: tables exposed without RLS can be accessed by any role with matching grants.

This post is the RLS rule itself: enable it in the same migration, write policies, and never turn it off to “make it work”. For the rest of a Next.js + Supabase Cursor setup (auth helpers, env, Stripe), use Cursor rules for Next.js + Supabase .

Why agents leave RLS off

Tables created in the Supabase Dashboard have RLS enabled by default. Tables created in a migration, the SQL Editor, or an ORM dump do not. Agents almost always use SQL. Postgres also starts a new table with RLS disabled, so “it works” is the default until someone adds enable row level security .

The happy path hides it.…