What this check looks for
LeakScan connects with a read-only database role you create yourself and reads the catalog: the list of tables, policies, functions and settings. It never reads your rows.
- Tables in an exposed schema with row-level security turned off
- Policies that let anyone read or write, such as using (true)
- Tables with row-level security on but no policy, which often means a broken feature or a workaround that disabled it
- Views and functions that run with elevated rights and bypass row-level security
- Sensitive columns such as passwords, tokens and card numbers in exposed tables
Why AI builders get this wrong
When a builder hits a permissions error, the quickest way to make the screen work is to switch row-level security off or add a policy that allows everyone. The app works, the error goes away, and the table is now public. Nobody notices until someone else does.
What the fix looks like
For each table, the report names the problem in plain English and writes a fix prompt that turns row-level security on and adds a policy so each signed-in user sees only their own rows. If you prefer to make the change yourself, our guide shows the SQL.
Common questions
Why do you need a database role at all?
Policies and settings live in the database catalog, which the public API does not expose. The role you create can read the catalog only, and the report includes the one line of SQL that drops it.
Can the role see my customers' data?
The role is read-only and the check reads catalog metadata, not table rows. You can review the SQL snippet before you run it.