Row-Level Security is the kind of thing that looks done. The policies are there, the app works, your tests are green. So you move on. The problem is that your tests test your code — they never test the policies. And RLS is remarkably easy to get subtly wrong:
a USING clause with no matching WITH CHECK, so reads are locked down but writes aren't
a FOR ALL where you meant FOR SELECT
a forgotten ENABLE ROW LEVEL SECURITY on one table out of forty
a service_role key that quietly bypasses everything from the client
None of these throw an error. They just leak.
Don't review policies — attack them
Reading a policy and convincing yourself it's correct is exactly the failure mode. So instead of reviewing, I wrote a tool that attacks the database: it seeds two synthetic tenants, then from tenant A's session actually tries to SELECT, INSERT, UPDATE and DELETE tenant B's rows. Anything that succeeds is, by definition, a real cross-tenant leak — not a theoretical one.
That tool is rlsgrid (MIT). It does three things:
Maps every role × table × operation as allow / deny / conditional / unrestricted, so you can see the whole surface at once.
Fuzzes isolation by really executing cross-tenant operations against a live database.
Emits a pgTAP suite you run in CI, so a regression in a policy breaks the build instead of leaking in prod.
pip install rlsgrid
export DATABASE_URL=postgresql://...@staging/db # it refuses prod-looking URLs
rlsgrid plan # the map
rlsgrid fuzz # the leak hunt
rlsgrid gen pgtap # the CI suite
What I actually found
On my own app — the one with green tests — fuzz turned up a table where a FOR ALL policy let one tenant update another's rows. It had been there for weeks. The map made it obvious in hindsight; the fuzzer made it impossible to ignore.
Honest limits
It's alpha. seed/fuzz write to the database, so run it against staging or a throwaway DB (it hard-refuses URLs that look like prod). It complements pgTAP/supabase-test-helpers rather than replacing them — keep your business-rule tests, let rlsgrid watch the floor.
If you run multi-tenant Postgres or Supabase: how do you test your RLS today? Genuinely curious — most answers I get are "we review them carefully."