Why can AI-built apps leak data?

The most common cause is a misconfigured access policy. When the browser talks to the database directly, the only thing standing between a user and everyone else's data is a row-level security (RLS) policy. If the generated policy is missing, too broad, or applied to the wrong table, the data is exposed, and the app still looks like it works.

What is row-level security and why is it risky?

Row-level security is a database feature that filters which rows each user can read or write. It's powerful, but in AI-built apps it's often auto-generated and rarely reviewed line by line. Because the client connects to the database directly, a single weak policy can be enough to leak records. The safety of the whole app depends on every policy being correct.

How can an AI app builder avoid this risk entirely?

By keeping the database server-side. If the browser never holds database credentials and every write goes through a server-side function, there is no client-side query for an attacker to manipulate and no RLS policy to misconfigure. Access rules live in code that runs on the server, not in the browser.

Guide

Are AI-built apps secure? The hidden risk in client-side databases

Q: Does Pentoggle use this safer architecture?

Yes. In Pentoggle the generated app's front end has no direct database access. Reads are governed by declared policies and every write runs through a server-side function, so database credentials and business logic never reach the browser.

AI app builders can ship a working product in minutes. But the architecture most of them use can put your database one misconfigured policy away from leaking. Here's how that happens, and how to avoid it.

The short version

Most AI app builders connect the browser directly to the database and rely on row-level security (RLS) policies to decide who can see what. When those policies are auto-generated and never reviewed, a single weak rule can expose everyone's data, while the app keeps working normally, so nobody notices. The fix is architectural: keep the database server-side, so the browser never queries it at all.

How most AI app builders connect to data

The popular pattern, used by tools built on Supabase and similar back-ends, is to give the front end a database client. The browser ships a publishable key (public by design, not the secret one, which stays server-side) and queries the database directly: reads, writes, everything. That key isn't the weak point; it's meant to be in the page. The only thing stopping one user from reading another user's rows is row-level security (RLS): a set of policies the database checks on every query.

This is fast to build and works well when the policies are written carefully. The problem is the word "carefully." In an AI-generated app, those policies are produced by a model, scattered across tables, and almost never read line by line by the person shipping the app.

Why row-level security is so easy to get wrong

RLS is all-or-nothing in a dangerous way: if a policy is missing on a table, that table is wide open. If a policy is too broad, say it checks that a user is logged in but not that the row belongs to them, every logged-in user can read every row. If RLS is enabled on one table but forgotten on the new table added by a later feature, that new table leaks. None of these mistakes produce an error. The app looks fine.

This is why "my AI app leaked its database" has become a recurring story: the failure mode is silent, the surface area grows with every feature, and the only safeguard is a human catching a subtle policy gap in generated code.

What a leak actually looks like

Because the browser talks to the database directly, anyone can open the developer tools, read the publishable key and endpoint out of the page, both are public, and issue their own queries. If a policy is weak, they don't need to break anything: they just ask the database for rows it shouldn't return, and it returns them. User emails, private records, draft content, payment details: whatever the policy failed to protect.

A safer architecture: keep the database server-side

The risk disappears when the browser never touches the database. In a server-side model, the front end calls functions that run on the server; those functions hold the credentials, enforce access rules in code, and return only what the user is allowed to see. There is no database client in the browser, no API key to extract, and no row-level security policy to misconfigure, because there is no direct client query to police in the first place.

Reads can still be fast and declarative, but they run through policies enforced on the server rather than in the browser. Writes, the operations that actually change data, go through server functions where the logic is explicit and reviewable. The blast radius of a mistake shrinks from "the whole database" to "one function."

How Pentoggle applies this

Pentoggle generates apps on this server-side model by default. The generated front end has no direct database access: reads are governed by declared policies and every write runs through a server-side function. Database credentials and business logic never reach the browser, so an app can't leak data through a forgotten or over-broad RLS rule, because there isn't one. You still get a managed Postgres database, authentication, storage and more with zero setup; the security model just sits in a safer place.

See how this compares across tools in our AI app builder comparison, or read Pentoggle vs Lovable.

A checklist for any AI app builder

Before you trust an AI-built app with real user data, ask: Does the browser connect to the database directly? If so, what enforces access, and who reviewed those policies? What happens to security when a new feature adds a new table? Can someone read the API key out of the page source? If the answers depend on hand-checking generated policies, the safety of your data depends on catching a mistake that produces no error.