The table your coding agent created does not have row level security on it.

UpGuard published a census rather than an incident report. It says it "gathered ~300,000 unique domains with indicators of Supabase usage" and, across that candidate set, "identified 16,326 databases exposing readable tables". Over half showed indicators of some PII, and a smaller share included passwords or authentication tokens.

It is worth being precise about whose problem this is, because the aggregator headlines were not. UpGuard attributes the exposure to how application owners configured their own projects, not to a flaw in Supabase. It also credits Supabase with having "made product changes to implement RLS by default for tables created in the Table Editor UI". Supabase's chief information security officer told TechCrunch that the company provides "secure defaults and tooling, and customers control how their own projects are configured".

So this is not a breach of Supabase, and nobody should read it that way. It is a measurement of how often a particular configuration mistake occurs in the wild, and the number is large enough to be worth ten minutes of your time.

The sentence in the research that should make you check your own projects is this one: "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default."

Read that twice. Supabase closed this for tables you create by hand in the dashboard. It remains open for tables created through the API. And creating tables through the API is exactly what happens when you ask a coding agent to add a feature that needs a new table.

That produces an uncomfortable asymmetry: the tables you made deliberately, while thinking about the schema, are protected. The tables that appeared because you asked for a feature, which you may not have reviewed line by line, are not. The second category is growing much faster than the first.

UpGuard names two further causes worth checking at the same time: policies that exist but do not adequately restrict access, and public keys used in client-side code as though they were secret keys.

There are three states, and only one of them is safe. Teams routinely confuse the middle one with the last.

Row level security disabled means the table is readable by whatever role reaches it. Row level security enabled with no policy means Postgres denies everything, which is safe but usually means the feature is quietly broken rather than correctly locked down. Row level security enabled with a policy that correctly scopes rows to the requesting user is the state you want.

The failure mode that produces exposure is a fourth case: RLS enabled with a policy that looks restrictive but is not, for example one that checks that a user is authenticated without checking that the row belongs to them. Every authenticated user, including one who just signed themselves up, then reads everything.

So an audit that only asks "is RLS on" will give you a clean bill of health you have not earned. You need to look at the policies.

Run this against every project, including the staging one and the prototype nobody uses, because exposure does not care how seriously you take the environment.

There is a related change already scheduled, and it will turn some of these quiet exposures into loud breakages. Supabase has said that new tables in the public schema will no longer be exposed to the Data API by default, "enforced on all projects on 2026-10-30". The dashboard control is called "Automatically expose new tables and functions".

Crucially, the mechanism is grants rather than RLS. The changelog is explicit: "Without an explicit GRANT, a role will not have access to the created table." That means a migration which creates a table and enables RLS and adds a policy, which is the responsible thing to do, will still produce a table your client cannot read after 30 October unless you also grant.

The failure will present as an empty result rather than a permissions error, which is the worst kind. Add the grant statements to your migration boilerplate now, alongside the RLS and policy statements, and if you create tables at runtime, that code path needs an explicit exposure step.

This is not really a story about Supabase. It is a story about what happens when the thing that writes your schema is not the thing that thinks about your threat model.

A coding agent asked to add a feature will create the table the feature needs, and it will be right about the columns. Whether that table should be readable by an unauthenticated visitor is not a question the feature request contains, so it does not get answered.

The durable fix is to make the safe thing the default in your own repository rather than relying on remembering: a migration template that includes RLS, a policy and a grant; a test that fails if any table in the public schema has RLS disabled; a review step on schema changes specifically. Any of those three turns this from a recurring risk into a solved one.