Why Every Tech CEO Needs to Understand Row-Level Security

A founder I spoke with this year built her entire booking platform in a weekend using Lovable, connected it to Supabase, and had paying salons on it by Tuesday. Six weeks later a customer emailed to say he could see another salon's client list, phone numbers, appointment notes, all of it, just by changing a number in his browser's address bar. Nobody had written the code that allowed that. It was never written. The database table was simply open, the way Postgres leaves it until a human tells it otherwise, and no human ever had.

That's the realisation underneath this whole piece: the leak wasn't a bug. It was the absence of a decision. Row-level security is off by default, the AI builder never asks you about it, and most chief executives have never heard the term. That gap is where customer data is leaking right now, quietly, inside a growing number of companies that shipped fast and never went back to check the locks.

Why AI-Built Apps Keep Leaking Data Across Customers

Tools like Lovable, Bolt, and their competitors are extraordinary at one job: turning a prompt into a working application with a database, an interface, and user accounts, in an afternoon. What they are not built to do is ask you, mid-generation, whether Salon A should ever be able to query Salon B's rows. That question sits outside the "does it work" test every demo passes. An app can look completely finished, log users in correctly, save their data, and still let any authenticated user read every other user's data, because working and walled-off are two separate properties, and only one of them shows up on screen.

What Is Row-Level Security?

Row-level security is a rule enforced inside the database itself that filters which rows a given user is allowed to see or change, based on who they are, rather than trusting the application code above it to ask nicely. Postgres supports it natively. It does nothing at all until a developer writes a policy and switches it on, table by table.

The OWASP Top 10 has ranked broken access control as the single most common category of web application risk since its 2021 revision, ahead of injection attacks, ahead of misconfiguration, ahead of everything else on the list. That ranking predates the current wave of AI builders by years. What has changed is not the nature of the risk. It's who is now capable of shipping it without knowing they did.

Why "We'll Add Security Later" Never Actually Happens

For years I called this a tooling problem. It is not. It is a sequencing problem, and no tool was ever going to fix it on its own. The advice engineers give founders, "ship first, harden later," assumes there is a later. In practice, later is the week after the seed round closes, or the week before the enterprise deal that needed a security questionnaire answered honestly, or never, because the product works and nobody wants to touch a database that's making money.

Default-open access control is invisible from the outside. A founder testing her own app sees her own data, correctly, every time, because she's usually the only user in the system when she's checking. The failure only surfaces once there are two tenants with something to hide from each other, and by then the product has customers, contracts, and a support inbox that is about to get a very uncomfortable email.

The Three-Question Framework Every CEO Can Run Without Reading Code

You do not need to read a line of SQL to hold your team accountable for this. You need three questions, asked in a room, with a demonstration required, not a verbal reassurance.

First: does this application store more than one customer's, or one user's, data in the same table? Almost every SaaS product does, by design, because separate databases per customer don't scale economically. Second: is row-level security, or an equivalent tenant-isolation check, turned on for every table that holds that data, not just the ones someone remembered? Third, and this is the one that actually catches leaks: who on the team tried, deliberately, to view another tenant's data using a normal customer account, and what happened when they tried?

A database that trusts every request by default isn't a database. It's a filing cabinet with the lock removed and a sign asking people not to look.

The table below is the version I hand to non-technical founders, because "default-open" and "default-closed" sound like the same phrase with an antonym swapped in, and they are not remotely the same posture.

What This Looks Like Inside a Company That Gets It Right

In the code reviews our engineering teams have run this year on AI-generated products handed to us mid-fundraise, the same missing checkbox turns up often enough that we now ask about tenant isolation before we read a single line. One client had built a genuinely good product on Bolt, raised a strong seed round on the strength of the demo, and had never once tested what a second customer account could see. We found it in an afternoon. Fixing it took a day. Finding it after their first enterprise customer's security team found it instead would have cost the deal, and probably the round after it.

I regret not building this question into our own intake checklist earlier. We treated it, for longer than I'll admit, as something the platform handled for you if you used a modern stack like Supabase. Supabase's own documentation is direct about this: row-level security is a feature the platform makes easy to turn on, not a default it turns on for you. The distinction between "available" and "automatic" is exactly the distance most leaks travel through.

Who Is Responsible When an AI Tool Leaves Data Exposed?

The company whose product it is, always, regardless of which tool generated the code or which vendor's database it runs on. Obligations under GDPR-style data protection law and most enforcement actions attach liability to the data controller, not the AI coding assistant it used to build the system.

This is the part boards underestimate. A missing row-level security policy doesn't read as a technical debt item on a roadmap. It reads, to a regulator or a plaintiff's lawyer, as a decision the company made not to protect its customers, because from the outside a default setting and a deliberate choice look identical. The IBM Cost of a Data Breach Report tracks how much of that cost lands in legal fees, customer churn, and lost deals long after the patch ships, and none of that spend distinguishes between "we chose this" and "we never thought about it."

Multi-tenant isolation isn't a new discipline invented for the AI era. AWS has published guidance on tenant isolation for shared Postgres databases for years, aimed at engineers who were already building this deliberately. What's new is the number of people shipping multi-tenant products who never made a conscious decision to be multi-tenant at all. The AI builder made that decision for them, silently, the moment it put two customers in one table.

Frequently asked questions

What is row-level security in simple terms?

Row-level security is a rule set inside a database that controls which rows of data a specific user is allowed to see or change, enforced by the database itself rather than by trusting the application built on top of it. Without an active policy, most databases show every row to any authenticated request.

Why do AI coding tools like Lovable and Bolt create this risk?

These tools generate working applications quickly, including the database schema and user accounts, but they do not automatically configure row-level security or ask whether one customer's data should be hidden from another's. The application looks complete and functions correctly while the access control layer stays unset.

How can a non-technical CEO check for this problem?

Ask your engineering team to demonstrate, using two separate customer accounts, that one cannot see the other's data anywhere in the product, including through the API directly. Request this before every major launch and after every AI-assisted build, not as a one-time audit.

Here is the concrete move: before you close your laptop today, message whoever owns your engineering, ask them to create two test accounts, and ask them to show you, on a screen share, that account one cannot see one single row belonging to account two. If they can't show you within the hour, you have your answer about where this sits on tomorrow's priority list.