Confirming the security boundary for supabase_admin default privileges on hosted Supabase

[cytrusai-cmd]

Hosted Supabase, PostgreSQL 17.6.

We removed automatic anon/authenticated grants for future tables and views created by postgres in public, using ALTER DEFAULT PRIVILEGES ... ON TABLES.

The change was applied and verified:

• Automatic client grants for that table/view creation scope were removed.
• Existing object ACLs were unchanged.
• service_role defaults and function/sequence defaults were preserved.
• Current public tables/views are owned by postgres; our project administrator cannot assume supabase_admin.

Default ACLs owned by the internal supabase_admin role still grant client privileges for future objects. The role documentation identifies it as an internal platform role, while the documented default-privilege procedure targets postgres.

Could the Supabase team confirm the intended hosted-platform boundary, ideally with a documentation reference?

1. Can supported platform upgrades, maintenance, automations or managed services create tables, views, functions or sequences in public as supabase_admin?
2. If so, could the inherited client grants make those objects reachable through the Data API?
3. What is the officially supported mitigation for project owners if that can happen?
4. If not, is it appropriate to treat these remaining defaults as a managed-platform boundary, separate from customer-created objects?
5. What should project owners recheck after upgrades, restores or schema changes, including tables and views?

We are seeking clarification of the supported security posture, not a way to assume or modify a managed role.

Related discussion: https://github.com/orgs/supabase/discussions/48259

[k1ng-arthur]

If there are no docs to answer these questions then it's unlikely a team member will stumble upon this to answer these questions. I would file a ticket to Supabase support if you haven't yet