What is the smallest test that would make you trust an RLS policy?

For multi-tenant apps, “RLS is enabled” is not evidence that rows are isolated. The failure I keep looking for is simple: user A can read or mutate a row owned by tenant B through a permissive relationship or missing ownership condition.

I built a tiny red/green fixture around that exact case. The broken policy fails the cross-tenant assertion; the one-file fix passes the same test suite. It runs locally without a Supabase project, credentials, Docker, or production data:

https://github.com/cekuu35/supabase-rls-leak-demo

My current minimum proof is: same-tenant access succeeds, cross-tenant read returns zero rows, cross-tenant write changes zero rows, and the assertions run under the application role rather than an admin role.

What additional case has caught a real RLS bug for you—joins, SECURITY DEFINER functions, storage objects, service-role leakage, or something else? I’d like to turn the strongest answer into the next reproducible fixture.If you prefer a human review of your own policies, the 24-hour three-table scope is here (sanitized SQL only, no secrets; $15.20 launch price, $7.60 deposit today): https://cengokurtoglu.gumroad.com/l/supabase-rls-3-table-review/LAUNCH20?utm_source=producthunt&utm_medium=forum&utm_campaign=rls_review