Supabase's October 30, 2026 default stops new tables from being exposed to its APIs automatically. It does not close tables that are already readable, and it does not turn on row-level security for tables an AI coding agent created in SQL.
What happened
On September 25, 2026, UpGuard reported a scan of about 300,000 domains that found 16,326 Supabase databases with readable tables. More than half showed signs of personal data. TechCrunch covered the same findings that day. The primary write-up is UpGuard's account of systemic data exposure in Supabase apps.
The detail that matters for an AI-built app is how those tables were created. UpGuard says tables created in code, which is how AI coding agents typically create them, do not get row-level security by default. The table lands in the project, the API roles can reach it, and nobody turned RLS on. The anon key in the browser is then enough to read the rows those grants allow.
A separate 2026 scan by Reeve measured the same gap from the builder side. Of the Supabase-backed Lovable apps that could be checked, 57% had at least one table readable without login. Reeve labels the figure as vendor research in its 2026 report on vibe-coded app security. The figure describes that build pattern.
What the October 30 change fixes and what it does not
Supabase's new default is that tables are not automatically exposed to its APIs. For projects that already exist, that default arrives on October 30, 2026. A summary of the UpGuard findings states the limit in plain terms: existing tables keep their current grants, so old exposures remain until they are fixed by hand.
What the change fixes is the next table, not the last one. After the default is in effect, creating a table does not by itself publish that table on the Data API. That removes a footgun for schemas created once the switch has flipped.
What it does not fix is any table already exposed. Grants stay as they are. Row-level security stays off if it was off. A policy that allows every row stays wide open. A service-role key copied into client code stays in the bundle. October 30 does not revoke, rewrite, or scan any of that. If an agent generated the schema before the cutoff, assume those tables are untouched until you change them.
A five-step self-check
You can run this on the project you are about to ship. Use the Supabase dashboard and the anon key from the client. Stay logged out for the read test. October 30 will not clear a failed step.
- List API-reachable tables. Note every table the Data API can see, including tables a migration or an agent added. The list that matters is the one the API exposes, not the one you remember designing in the editor.
- Confirm RLS is enabled on each. Open those tables and check that row-level security is on. A table with RLS off and a grant to the anon or authenticated role is readable with the key that ships in the frontend. That is the gap UpGuard describes for tables created in code.
- Test with the anon key while logged out. In a private window or a REST client, request the table with only the anon key and no user session. If rows come back, anyone who has that public key can read them too.
- Check policies for
trueor a missing WITH CHECK. A policy that usestrueas its expression, includingUSING (true), returns every row for that role. An insert or update policy with noWITH CHECKcan accept writes the read rule never intended. RLS that is enabled and wide open is not a control. - Look for service-role keys or secrets in client code. Search the frontend, bundled env files, and any agent-written config for the service-role key, a database connection string, or another secret. The service role bypasses RLS. It belongs on a server you control, not in an app the browser downloads.
Get a written fix list
The check is short. The repair is specific: which grants to revoke, which tables need RLS, which policies are too wide, and which keys have to leave the client.
The MVP Rescue Audit includes a fixed-scope Supabase RLS and data-exposure check. You get a written fix list covering API-reachable tables, whether RLS is on, what the anon key can read while logged out, policies, and secrets in client code. If you want those fixes applied, an optional fix sprint follows the audit.
Book the MVP Rescue Audit, or ask for the Supabase RLS and data-exposure check and we will scope it as part of the rescue.