"Write the RLS policy for my users table": three prompts, three outcomes

Row Level Security is the guardrail that most vibe-coded Supabase apps are missing, and it's the direct cause of the breaches you read about. The good news: it's just SQL, and an AI writes it well when you're specific. The bad news: a vague ask can produce SQL that either locks out your real users or, far worse, exposes all of them.

Here's "write the RLS policy for my users table" three ways to Claude via Claude Code, with the real SQL each produced. RLS is one of the few places a wrong policy is silently catastrophic, so the specificity really earns its keep.

The same request, three ways

add RLS to my users table

alter table users enable row level security;

write RLS on the users table so each user can read and update only their own row

alter table users enable row level security;

create policy "read own row"
  on users for select
  using (auth.uid() = id);

create policy "update own row"
  on users for update
  using (auth.uid() = id);

same policies, but deny insert and delete by default, and make sure a user can't update their row to impersonate another user; add a comment warning against using (true)

alter table users enable row level security;
-- No insert/delete policy = those are denied by default. That's intended.

create policy "read own row"
  on users for select
  using (auth.uid() = id);

create policy "update own profile"
  on users for update
  using (auth.uid() = id)
  with check (auth.uid() = id);
-- ⚠ Never write  using (true)  — it exposes every row to everyone.

The vague result is instructive precisely because it looks like nothing. Enabling RLS with no policy is a valid, complete SQL statement — it just denies everyone, so your app quietly stops returning data and you assume something else broke. The specific prompt adds the policies that let the right rows through.

The constrained version adds the two things a careful reviewer always checks: that insert and delete are denied unless you truly meant to allow them (deny-by-default handles that), and that with check prevents a user from writing a row that claims another user's identity. The warning comment is there because using (true) is the one-liner that turns a locked table back into an open one, and it slips into AI output more often than you'd like.

RLS rewards a precise prompt more than almost anything else because its failure mode is invisible. A broken login throws an error you'll notice; a too-open policy just serves data, cheerfully, to the wrong people, with no stack trace and nothing in the logs. That's why the only real test is behavioural: log in as two different users and as a logged-out visitor, and confirm each one sees exactly their own rows and nothing else.

Before you ship it

A wrong RLS policy fails silently in the most dangerous direction: everything works, and everyone can see everything. Before you trust it:

• Learn the model interactively first — Row Level Security, explained has a toggle that shows the same query with RLS on and off.
• Test every policy as a logged-in user AND as a stranger (a different user, and no user). If a stranger gets rows, the policy is wrong.
• The Moltbook breach was exactly this gap — a public key with no RLS behind it. The Moltbook lesson.
• Back up before changing policies, and keep a separate test database — Backups, and losing everything.

Ask your AI tool to explain each policy line in plain English before you run it, then re-read it with the three questions from How to read AI code without coding. RLS is short enough that reading it is genuinely doable, and it's the highest-leverage code in your app.