A web app talks to Postgres with a superuser-like role (BYPASSRLS), so row-level security policies never apply to its queries. Adding multi-user permissions (view/edit/delete scoped to own records, team records, or all, plus sharing) by sprinkling checks into each server action is fragile: one forgotten action, export, count, or search leaks or modifies data.

Multi-tenant Supabase apps often add `create policy ... on users for update using (id = auth.uid())` so people can edit their display name. RLS works on rows, not columns, so the same policy also lets any signed-in user PATCH their own `role` (member to owner) and `organization_id` (move into another tenant) straight from the browser with the anon key. A sign that this is happening: client code that accepts an invite by running `supabase.from('users').update({ organization_id, role })` itself.