How to remove anon from supabase_admin-owned default privileges on schema public?

[123miguelmartins]

Goal: we have deliberately removed all anon access from schema public and rely only on authenticated and service_role. We want new objects to not be created with anon grants.

Problem: pg_default_acl has entries owned by supabase_admin for schema public that grant anon on every future object. Because they are owned by supabase_admin, our postgres role cannot revoke them (ALTER DEFAULT PRIVILEGES FOR ROLE supabase_admin ... requires membership of that role).

Reproduction (read-only):

SELECT n.nspname AS schema, pg_get_userbyid(d.defaclrole) AS owner_role,
       d.defaclobjtype AS obj_type, pg_get_userbyid((a).grantee) AS grantee,
       (a).privilege_type AS priv
FROM pg_default_acl d
JOIN pg_namespace n ON n.oid = d.defaclnamespace
CROSS JOIN LATERAL aclexplode(d.defaclacl) a
WHERE n.nspname = 'public' AND pg_get_userbyid((a).grantee) = 'anon';

Result (owner supabase_admin):

• tables: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, MAINTAIN
• sequences: SELECT, UPDATE, USAGE
• functions: EXECUTE

What we have already done: revoked every existing anon grant on tables, functions and sequences in public (confirmed zero), and we revoke anon on each object we create. The residual is objects created by platform operations under supabase_admin, which are born open again.

What we already know: the usual guidance is "rely on RLS, don't worry about anon grants." We have made the stricter choice of removing anon entirely from public, so that answer does not fit our model. We are not asking about the graphql, graphql_public or storage schemas, which we understand are platform-managed.

Questions:

1. Is there a supported way for a project owner to remove the anon grants from the supabase_admin-owned default ACLs on schema public?
2. If not, is this default intentional, and is the per-object REVOKE the intended workaround?
3. After provisioning, does anything Supabase runs (extension installs, platform migrations) actually create objects in public under supabase_admin that would hit this default? Or is the surface in practice limited to objects we create ourselves?

Postgres 17.6, single project. Happy to share the project ref privately if a Supabase engineer needs it.

[GaryAustin1]

I'm pretty sure Supabase creates tables as Postgres. The dashboard calls an admin API for creating tables and they are all owned by postgres not supabase_admin.
I don't find any public tables owned by supabase_admin in public schema. This is for hosted supabase.

https://supabase.com/docs/guides/api/securing-your-api#default-privileges-for-new-tables-and-functions

Also make sure you are up to speed on this:
https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically

[harrysun2006]

You're right that you can't touch the supabase_admin-owned default-privilege entries — ALTER DEFAULT PRIVILEGES FOR ROLE supabase_admin ... needs membership in that role, which you don't get on hosted. So chasing the pg_default_acl rows is a dead end.

The cleaner lever is one level up: revoke schema USAGE from anon instead of trying to keep every future object's grants clean.

revoke usage on schema public from anon;
revoke create on schema public from anon;

anon needs USAGE on the schema to touch anything inside it, regardless of per-object grants. Once that's gone, it doesn't matter that new tables/functions are born with anon privileges — anon can't reach them, because it can't use the schema at all. That gives you exactly the posture you want (only authenticated + service_role) without fighting the default ACLs object-by-object.

Two caveats:

• This nukes anon access to public entirely, so make sure nothing legitimately relies on the anon/PostgREST-unauthenticated role for public (sounds like that's your intent).
• If you ever do want a specific object reachable by anon, you'd re-grant usage on the schema, which reopens the general path — at which point RLS becomes your gate again.

If you'd rather keep schema USAGE for some reason, the belt-and-suspenders alternative is a DDL event trigger (ddl_command_end on CREATE TABLE/FUNCTION/SEQUENCE) running a SECURITY DEFINER function that REVOKEs anon on each newly created object — but honestly the schema-level revoke is simpler and closes the hole completely.