Threads
Loading user profile...
We see the same boundary on another hosted Supabase project (PostgreSQL 17.6). Adding our verified case here rather than opening a duplicate Question. Our customer-controlled change is applied and verified: - Automatic `anon`/`authenticated` grants were removed for future tables/views created by `postgres` in `public` using `ALTER DEFAULT PRIVILEGES ... ON TABLES`. - Existing object ACLs were unchanged. - `service_role` defaults and function/sequence defaults were preserved. This was table-default hardening, not removal of every default grant. - Current public tables/views are owned by `postgres`; our project administrator cannot assume `supabase_admin`. The remaining `supabase_admin`-owned default ACLs still grant client privileges for future objects. The [official role documentation](https://supabase.com/docs/guides/database/postgres/roles) identifies this as an internal platform role, while the [documented default-privilege procedure](https://supabase.com/docs/guides/api/securing-your-api) targets `postgres`. The replies above are helpful. Could the Supabase team confirm the supported boundary, ideally with a documentation reference? 1. Can supported platform upgrades, maintenance, automations or managed services create objects in `public` as `supabase_admin`? If so, which object types/workflows? 2. If such objects can inherit client grants and become reachable through the Data API, what supported mitigation should project owners use? 3. What should owners recheck after upgrades, restores or schema changes, including tables AND views, to verify this boundary? We are seeking platform clarification, not a way to assume or modify a managed role.