Available for PostgreSQL

Prove your database actually isolates tenants.

Row-Level Security and careful function logic keep tenant A from seeing tenant B. Two layers, each needing its own proof, every release.

How to do it

Two layers, two commands. Use both.

  1. Policy layer, free. Prove every RLS policy, per table, command and identity.
pip install rlsautotest
rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html
# or emit a committable pgTAP suite:
rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/
  1. Code layer, Enterprise. Prove the functions, views and triggers that bypass RLS.
unitautogen seccover --schema public --out sec_out --sec-html sec.html --sec-json sec.json --sec-gate

Two layers where tenant data leaks. One tool for each. Use both.

A test at one layer says nothing about the other.

rlsautotest

Policy layer
  • Proves each RLS policy, per table, per command and per identity
  • Fails CI on a reachable table with no policy
  • Names every SECURITY DEFINER function, view and trigger as a suspect

It cannot judge the suspects; it sees that code bypasses RLS, not whether it leaks.

rlsautotest, free and open source →

UnitAutogen seccover

Code layer
  • Runs each suspect as two tenants with generated data on both sides
  • A verdict per routine, enforced or leaking, with the table, command and channel
  • A PII pass for personal data escaping through error messages

It cannot stand in for the policies; direct table access is rlsautotest's job.

seccover, in the UnitAutogen engine →

Complete leakage detection needs both.

What platforms suggest

Both layers of isolation, and testing them, come straight from the platforms' docs.