Supabase "permission denied for table" since 30 October? Don't let your AI fix it with GRANT ALL

Since 30 October 2026, new Supabase tables aren't granted to the Data API automatically. So the first time your app touches a new table, supabase-js returns:

code: "42501"
message: "permission denied for table notes"

It's not a bug. Your app talks to Supabase as anon (logged out) or authenticated (signed in), and a role needs a Postgres GRANT before it can touch a table at all. Older tables got those grants for free. New ones don't.

The fix is one line. The problem is which line your AI tool picks.

Two errors, same code

Both of these come back as 42501, but they mean different things:

If you paste either one into Lovable, Bolt or Cursor, check which one it is first. They need different fixes.

The safe fix for "permission denied"

RLS and a policy first, then grant only what the app needs, only to the role that needs it:

alter table public.notes enable row level security;

create policy "Users manage their own notes"
on public.notes for all
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

grant select, insert, update, delete on public.notes to authenticated;

For data everyone may read but nobody may change from the browser (products, blog posts):

alter table public.products enable row level security;

create policy "Anyone can read products"
on public.products for select
using (true);

grant select on public.products to anon, authenticated;

The fixes that make the error go away and open your table

Your anon key is in your app's JavaScript, so anyone can use it. Watch for these:

• grant all on public.notes to anon: logged-out visitors get insert, update, delete and TRUNCATE, which RLS doesn't cover at all.
• Granting to anon on user data. Logged-out visitors never need your users' rows.
• Granting before RLS is on. Until the policy exists, every row is public. If the AI forgets the policy, it stays that way.
• disable row level security or using (true) on user data.
• The service_role key in the frontend. It skips RLS completely.

A prompt that works

My Supabase table is giving error 42501 "permission denied for table".
Fix it safely:
1. Enable Row Level Security on the table first, with policies so users
   only read and change their own rows (auth.uid() = user_id), including
   WITH CHECK on insert and update.
2. Then grant only the needed privileges (select, insert, update, delete),
   only to the authenticated role. Do not grant to anon unless the data is
   meant to be public, and never use GRANT ALL.
3. Do not disable RLS, do not use using (true) on user data, and do not
   use the service_role key in the frontend.
Show me the SQL before running it.

The last line matters most. Read the SQL before you click run.

Your old tables didn't change

The 30 October change only affects new tables. A table that was readable with your anon key last week still is. Two queries to check:

select tablename, rowsecurity from pg_tables where schemaname = 'public';

select table_name, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
group by table_name;

Any table with rowsecurity = false that anon can select from is readable by anyone.

Checking a live app

I build LeakPatrol, a free read-only scanner for apps built with Lovable, Bolt, v0 and Cursor. It checks your live site from the outside for leaked keys and public files in about a minute. There's also a free RLS policy generator that writes the grants and policies for common table types.

Full guide with an FAQ: Supabase error 42501, the safe fix. And if you're seeing the other one, here's the RLS error guide.