Marked as helpful by the asker
A tenant_id column with filtering in application code is not isolation, it is a convention that holds until one query forgets. With nine firms you want the database to refuse, not your code to remember.
Put RLS on every table with membership as the condition, not a claim you pass in:
create policy tenant_isolation on invoices for all
using (tenant_id in (select tenant_id from memberships where user_id = auth.uid()))
with check (tenant_id in (select tenant_id from memberships where user_id = auth.uid()));Three things that bite people after this. Index memberships (user_id, tenant_id) or every query pays for the subquery. Views do not inherit RLS unless you create them with security_invoker = true. And any code path using the service role key bypasses all of it, so audit those routes specifically, they are where the real leak will come from.
RLS with the tenant looked up from a membership table is live. Two queries I'd forgotten to filter suddenly returned nothing, which was the point. 
priya_ships
priya_ships Put the tenant lookup in a security definer function with a fixed search_path. It keeps the policies short and fast. 
hannah_reyes
hannah_reyes 
tenant_idcome from on insert? If the client sends it, that's the first thing to fix.