Free tool

Which of your tables can anyone read?

In Postgres, a table is only isolated once row-level security is switched on for it and a policy is written against it. Both steps are per table, and a table that missed them answers to anyone holding the anon key. Paste a schema to see which of yours did.

Paste your schema

A pg_dump --schema-only output, or anything containing your create table statements.

create table public.tenants (
  id uuid primary key default gen_random_uuid(),
  name text not null
);

create table public.profiles (
  id uuid primary key,
  tenant_id uuid references public.tenants(id),
  email text
);
alter table public.profiles enable row level security;
create policy tenant_isolation on public.profiles
  for all using (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid);

create table public.orders (
  id bigserial primary key,
  tenant_id uuid references public.tenants(id),
  total numeric
);

create table public.audit_log (
  id bigserial primary key,
  event text
);
alter table public.audit_log enable row level security;

create table public.invoices (
  id bigserial primary key,
  tenant_id uuid
);
alter table public.invoices enable row level security;
create policy invoices_readable on public.invoices
  for select using (true);

Result

3 of 5 tables are reachable by anyone with the anon key.

tenantsNo RLS
Row-level security was never enabled. Anyone holding the anon key can read this table through the API.
profilesVerify
RLS is on and at least one policy exists. This check can't tell whether the policy is correct — read it yourself.
ordersNo RLS
Row-level security was never enabled. Anyone holding the anon key can read this table through the API.
audit_logNo policy
RLS is on with no policy attached, so every request is denied — including your own app's. Usually half-finished rather than intentional.
invoicesOpen policy
RLS is on, but a policy matches every row — using (true) isolates nothing.

This runs entirely in your browser — nothing is uploaded, stored, or sent anywhere, and there is no credential to give it. It reads DDL only, so it can tell you a policy exists but never whether it is correct. A table marked “Verify” has not been cleared — it has been handed back to you to read.

Why this keeps happening

Nothing about a missing policy fails loudly. The table works, the app works, the tests pass. The only signal is a customer reading another customer's data, and by then it has already happened.

That is survivable when a human adds a table every few weeks and reviews the migration. It is much less survivable when an agent adds one on request, several times a day. Creating the table is one call; enabling RLS and writing a correct policy against the right claim is a second thing that has to not be skipped, and skipping it looks exactly like success.

None of that is an argument against row-level security. It is a mature mechanism and it expresses rules far finer than tenant-level isolation. It is an argument about which layer should hold a guarantee this important.

On Aaly, this check has nothing to find.

Tenant isolation is a property of the project, applied by the platform on every request before your code is reached. There is no per-entity step to forget, because there is no per-entity step, which also means no policy for an agent to write incorrectly.

Start building free How this compares to Supabase, fairly →