The readable users table is not a finished access desk

A readable table is not unsupervised access ownership

The fastest way to confuse a security research headline with a finished access desk is to treat "we heard about 16,000 exposed databases" like the whole job. Someone sees a public PostgREST surface, a users table that answers without a login, or a changelog that will stop auto-exposing new public-schema tables, and the loop feels closed. The quieter questions arrive when an agent created a table without a human reviewing the diff, when grants look fine but RLS is still off, or when October 30 approaches and nobody named who owns the audit.

What UpGuard and TechCrunch reported

On September 25, 2026, Greg Pollock wrote for UpGuard that the firm fingerprinted roughly 300,000 domains and found about 16,326 Supabase databases exposing readable tables. Over half of those databases showed PII indicators. UpGuard's write-up notes that tables created through the API or agent tooling often lack the RLS-by-default behavior that the Table Editor applies, and it walks through defensive case studies (including valet and immigration-adjacent examples) without turning the piece into an exploit cookbook. The point for operators is blunt: a project can look modern and still leave tables readable to the wrong audience.

Zack Whittaker's TechCrunch story the same day put the figure near 16,000 databases and quoted Supabase CISO Bil Harmer. Harmer said projects are "secure by default," framed the situation as shared responsibility, and said security at Supabase is never finished. That is a clear vendor posture. It is still not a finished access desk for who reviews your anon and authenticated grants, who enables RLS, and who writes the policies that actually decide what a role can see.

The Data API change is a timeline, not a finished desk

Supabase's changelog on the breaking change is specific. New tables in the public schema are no longer automatically exposed to the Data API and GraphQL API. The shift was opt-in April 28, became the default for new projects May 30, and will be enforced for existing projects October 30, 2026. Existing tables keep their current grants. The docs and changelog separate two layers operators keep mixing up: database grants (who may access a table through the API roles) and row level security (which rows those roles may see once they have a grant). Supabase's securing-your-API guide treats grants and RLS as stacked controls. The Dashboard Table Editor turns RLS on by default for new tables. SQL migrations and agent or CLI creation often do not. Agents can create tables without a human reviewing the migration diff. The three-step unit Supabase keeps repeating is GRANT, enable RLS, then write policies.

Grants are not RLS, and agents are not reviewers

Treat "the table exists" as a finished access desk and you will get the demo that works in a sandbox and the production morning that discovers anon can still read rows nobody meant to publish. Grants answer whether a role can reach the table. RLS answers which rows that role may see. You need both. If an agent or CLI created the table, assume the Table Editor's RLS-by-default path did not run until someone proves otherwise.

None of that automatically answers who owns the inventory of public-schema tables, who re-checks grants before the October 30 enforcement date, or who reviews agent-created schema the way they would review a human PR. Useful plumbing. Still a desk to staff.

Stopping auto-exposure of new public-schema tables is useful. Naming who owns GRANT plus RLS plus policies before October 30 is still the access desk.

Local risk tooling is not that stamp either

Tampa Bay is a useful place to hold that checklist against a different kind of "SI expands into real ops" story.

On September 24, 2026, Anastasia Dawson reported in Business Observer that St. Petersburg-based CCI Insurance, which joined national brokerage Higginbotham in 2025, is taking its proprietary risk-management technology to a wider market. CCI renamed CompCorrect to RiskCorrect, reflecting a move from workers' compensation claims management into a broader commercial risk-management tool. The program uses AI to analyze large volumes of claims and incident data, identify patterns, and help companies decide what needs to change. Earlier in September, CCI made RiskCorrect available as a standalone product for companies with significant claims exposure and complex risk profiles.

Managing Director and Regional Sales Director Tobin Robeck said CompCorrect was the right name when the focus was primarily workers' compensation, and that RiskCorrect reflects a platform that helps companies see what is driving losses, connect claims and incidents, decide what needs to change, and prove those changes are working. Robeck, who co-founded the platform, also said the technology takes a tremendous amount of routine analysis and administrative work off people and surfaces things people might miss. For construction and other high-risk businesses, claims records can influence whether they qualify to compete for contracts.

That is a serious local bet on SI for claims and risk workflows. It is not a finished access desk for your shop's Supabase grants, RLS policies, or October 30 readiness. An SI risk platform that surfaces patterns in claims data is not a substitute for naming who stamps human ownership when database tables are readable on the public Data API.

What Keel will and will not claim

I work at Keel Automation, a Tampa Bay automation agency. We build operations portals, SI (Super Intelligence) integrations, workflow automation, and phone systems. Cole Junck is the owner and founder. We are not going to invent a Supabase remediation win, a RiskCorrect implementation credit, or a customer metric tied to these posts, because we have not published one. What the public record already shows is enough: a readable users table is not a finished access owner, grants are not a finished RLS policy, and a local RiskCorrect rollout is not a named human stamp for your Data API desk.

A dull access-desk ownership checklist

The test I would run this week is intentionally dull. Write down every public-schema table that is exposed to the Data API today, and which ones were created via Dashboard Table Editor versus SQL, CLI, or agents. Write down whether each exposed table has an explicit GRANT review for anon and authenticated. Write down whether RLS is enabled and which policies exist (and whether they were reviewed by a person). Write down your October 30 readiness for the Supabase breaking change that stops auto-exposing new public-schema tables on existing projects, remembering existing tables keep current grants. Write down who owns the audit when UpGuard-style fingerprinting or an advisor scan finds readable tables. Write down, separately, how a St. Pete RiskCorrect story fits your own access desk so a research headline and a product rename do not get confused with a finished human ownership policy. If those answers are shrugs, you do not have a finished access desk. You have a readable table and a hope that the next agent migration reviews itself.

UpGuard and TechCrunch put the exposure numbers and the shared-responsibility language on the record. Supabase published a clear timeline and the GRANT plus RLS plus policies unit. CCI's RiskCorrect move keeps the local reminder loud that SI products are already expanding into real claims and risk ops in this market. The research path can still be useful. The useful question is whether anyone owns the table inventory, the grants, the RLS policies, and the October 30 stamp before the next readable users table pretends the desk closed itself.

Sources

1. UpGuard / Greg Pollock, "Everything Everywhere: Systemic Data Exposure in Supabase Apps," September 25, 2026, on fingerprinting roughly 300,000 domains; about 16,326 Supabase databases with readable tables; over half with PII indicators; tables created via API/agents often lacking Table Editor RLS-by-default; and defensive case studies. https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps
2. TechCrunch / Zack Whittaker, "Some Supabase customers are publicly exposing reams of people's data to the web," September 25, 2026, on roughly 16,000 databases and Supabase CISO Bil Harmer on projects "secure by default," shared responsibility, and security at Supabase never being finished. https://techcrunch.com/2026/09/25/some-supabase-customers-are-publicly-exposing-reams-of-peoples-data-to-the-web/
3. Supabase Changelog, "Breaking change: Tables not exposed to Data and GraphQL API automatically," on the April 28 opt-in / May 30 new-project default / October 30 existing-project enforcement timeline; existing tables keeping current grants; grants versus RLS; agents creating tables without human review of the diff; and the GRANT + enable RLS + policies unit. https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically
4. Supabase Docs, "Securing your API," on grants and RLS as layered controls, and Dashboard RLS defaults versus SQL/tool creation paths. https://supabase.com/docs/guides/api/securing-your-api
5. Business Observer / Anastasia Dawson, "St. Pete insurance firm brings AI-powered risk platform to wider market," September 24, 2026, on St. Petersburg CCI Insurance (joined Higginbotham in 2025) renaming CompCorrect to RiskCorrect; AI analysis of claims/incident data; Tobin Robeck on AI taking routine analysis off people and surfacing things people might miss; and standalone availability for companies with significant claims exposure. https://www.businessobserverfl.com/news/2026/sep/24/st-petersburg-insurance-firm-ai-risk-platform/