Row Level Security (RLS) is a database feature that controls which rows each request is allowed to read or write, enforced by the database itself. Instead of trusting your application code to filter data, you write policies on each table so a user can only ever touch the rows they are permitted to, no matter how the request arrives.
Why it exists
Application code that filters data can be bypassed if someone talks to the database directly, for example with a public API key. RLS moves the rule down into the database, so the restriction holds even when the request does not come through your app. It is the difference between a lock on the door and a sign asking people not to enter.
How it works in practice
You enable RLS on a table, then add policies such as allow a user to select rows where the row's user_id equals their authenticated id. With no policy, an enabled table denies everything; with a permissive allow-all policy, it is the same as having RLS off, which is a common mistake.
What this means for AI-generated code
This matters for AI-built apps because tools like Lovable and Bolt ship a public Supabase key in the client, and that key is only safe if RLS is configured. AI builders almost never set it up, so the default is a public key in front of an unprotected database. That single gap drives a large share of the flaws we find.