I released a small open-source CLI called TenantProof for a narrow Supabase security question:
Can Tenant A read, change, or delete Tenant B's records after the latest database change?
A working UI and configured RLS policies do not prove that boundary. TenantProof turns intended access rules into owner, teammate, other-tenant, and anonymous REST checks against a disposable local or staging project.
It also checks for missing RLS, permissive policies, risky grants, and exposed service-role material.
I am looking for three Supabase-backed apps for free research audits. I will provide a plain-English report and reproducible checks that can be rerun after future changes.
No production credentials. No claim that this replaces a professional security review. The goal is to make one important boundary easier to test repeatedly.
Project: https://samuelpeterson22.github.io/tenantproof/
GitHub: https://github.com/SamuelPeterson22/tenantproof
I would also value blunt feedback from anyone already testing tenant isolation another way.
A user introduced an open-source CLI tool, TenantProof, aimed at testing tenant isolation in Supabase apps. The tool checks if tenants can access each other's data despite configured RLS policies. The user seeks feedback and offers free audits for Supabase-backed apps.
RLS is a filter not isolation. You can check our blog here:
https://tenantsdb.com/blog/why-we-stopped-using-row-level-security