Vibe Coding Broke Your RLS — What CHROs Should Ask Before the Breach Email

Bottom line: UpGuard told TechCrunch it found around 16,000 Supabase-hosted databases exposing some degree of personal data — names, addresses, phones, and in smaller volumes passwords and login tokens. Supabase's CISO framed it as shared responsibility: projects are "secure by default," customers control the settings. That framing is fair for a platform. It is fatal for a CHRO who just learned a quickly built internal tool or vendor demo was shipping customer personal data with the data lock off — or with a lock that always opens for everyone. Before the breach email, ask the questions below. After it, you will wish you had.

One term, once: RLS (row-level security) is a lock that decides which rows of data each person can see. Turn it off — or write a lock that always says "yes" — and anyone who can reach the database can often read everything.

This is not a hit piece on Supabase. It is an operator checklist for the wave of AI-assisted shipping that outruns access control.

What actually happened — context, not panic

TechCrunch's September 25 report is the clean public summary: Some Supabase customers are publicly exposing reams of people's data to the web. Independent coverage put the exposed-readable table count near 16,326, with more than half showing signs of personal information.

Important distinctions for executives:

• This is largely customer misconfiguration, not a claimed platform breach of Supabase itself.
• Browser apps ship a public "guest key" on purpose. Safety depends on the RLS lock (and who is allowed in) on every exposed table.
• AI "vibe coding" — building fast with AI helpers — shortens the path from idea to live URL. It does not shorten the path from live URL to correct "deny by default" locks.
• Coding agents that scaffold simple apps often create the tables and leave the hard part — who may read which row — as a TODO that never ships.

If your company has a hackathon culture, a no-code internal tools habit, or vendors who demo on Supabase in a weekend, you are in the blast radius. That is most Series A–C companies I work with.

Why CHROs own a piece of this

Security owns the technical control. CHROs own three things that decide whether the control survives contact with humans:

1. Who is allowed to ship. If any employee can stand up a customer-facing or employee-data app overnight, your access-control policy is theater.
2. What "done" means in performance. If demos and speed are rewarded and RLS review is optional, you will get demos.
3. What happens when people leave. Offboarding that closes single sign-on but leaves master database keys in old repos and agent memories is how yesterday's intern becomes tomorrow's incident.

Pair this post with the stop-line work in The Agent Stop Line Playbook: agents that write code and agents that read data need the same authority discipline.

The 60-second mental model

Path	What happens	Business translation
🌐 App → guest key → 🔓 RLS off or always-open	Anyone with the key reads every row	A stranger downloads your users table
🌐 App → guest key → 🔒 RLS on + real rules	Only the intended rows	Customers see their own data; not everyone else's
🔑 Master "full-access" key leaks to browser, repo, or agent chat	Bypasses every lock you wrote	A stranger ignores your policies entirely

In plain English: the guest key is public on purpose; the lock (RLS) is what stops strangers. The master key must never leave the server.

Two failure modes dominate. Both showed up in the UpGuard findings at scale.

Supabase's own docs are blunt: a table left open without RLS is readable or writable by anyone with a grant. Turning RLS on without testing real rules is how teams get a green badge and an open barn door.

The CHRO / CEO question list — ask before the breach email

Use these in the next weekly with your CTO / Head of Security. Demand proof, not vibes.

Talent and shipping authority

1. Who may create a production database project? Named roles only, or anyone with a company card?
2. Is there a mandatory security review before any app that stores employee or customer personal data goes past a private URL? What is the turnaround time?
3. Do hackathon and vibe-coded prototypes get a kill-by date? Or do they quietly become "the system of record"?
4. Are AI coding agents allowed to change database structure? If yes, who reviews the RLS locks in the same change?

Configuration evidence

5. Can we show, for every Supabase (or similar) project, that RLS is on for every exposed table? Screenshot or query output — not a slide.
6. Have locks been tested as a guest and as a signed-in user from the real app (not only from an admin console that can bypass the real path)?
7. Where do master full-access keys live? Secret vault only? Any in mobile apps, browsers, build logs, agent memory, or Notion?
8. Is there continuous scanning for publicly readable tables — or only hope?

People, vendors, and process

9. Which vendors and contractors host personal data on shared cloud database projects? Contract language for breach notice and config standards?
10. Does offboarding revoke database keys and agent connectors the same day as single sign-on?
11. Is "shipped with RLS verified" a promotion and bonus criterion for eng managers? If not, it will lose to "shipped fast."
12. Who is on-call when UpGuard (or a reporter) emails us next? Name, pager, runbook.

Forward the twelve questions. Require written answers in ten business days. That is a CHRO-grade intervention that does not require you to write SQL.

A 14-day fix sprint CEOs can sponsor

Day	Owner	Deliverable
1–2	Security + Eng	Inventory all cloud database projects (Supabase, Firebase, etc.) and tag what personal data each holds
3–5	Eng	Turn RLS on everywhere; remove excess guest/signed-in access; rotate any secrets that leaked to clients
3–5	Eng	Add an automatic check: fail any change that creates a public table without RLS + lock tests
6–8	Security	Scan for publicly readable endpoints; ticket every hit
6–8	CHRO + Legal	Draft the customer/employee notification decision tree before you need it
9–11	Eng	Re-test critical apps as an anonymous stranger with only the published guest key
12–14	CEO review	One-page status: projects inventoried, critical findings closed, leftover risk accepted in writing

If day 14 still has "we think it's fine," you do not have a program. You have optimism.

How this connects to AI coding agents

Coding agents are accelerants. They will happily generate a working app, paste the guest key into the client, and open a change titled "MVP." Without a stop line on database changes and secrets, they recreate the UpGuard findings at company scale.

Practical pairing rules:

• Agents may draft RLS locks and tests.
• Humans approve anything that changes who can see data, or where secrets live.
• Never let an agent store a master full-access key in chat memory, IM, or a repo "just for local testing" that later becomes shared.
• Treat a green "RLS enabled" badge as necessary, not enough — locks that always say yes look secure in the dashboard and open on the internet.

Same staffing instinct as Grok Bot and QoderWake: prepare freely, promote carefully, never on delete / spend / secrets.

What to tell the board in one paragraph

Third-party research reported ~16k Supabase customer databases with publicly exposed personal data, driven primarily by customer settings (RLS locks and access grants), not a claimed platform compromise. Our exposure depends on whether internal and vendor apps that store personal data enforce tested row-level locks and keep privileged keys on the server. We are inventorying projects, enforcing automatic lock tests, rotating suspect secrets, and tying shipping authority to security review. CHRO and Security share ownership of who may ship and how offboarding revokes data access.

That paragraph is forwardable. Use it.

Bottom line, again

Vibe coding did not invent bad database permissions. It industrialised them.

CHROs who wait for the breach email will spend the quarter on notification letters and trust repair. CHROs who ask the twelve questions this month will still have tense meetings — with their own CTOs, on purpose, while the blast radius is still measurable.

Ask now. Ship the 14-day sprint. Make RLS verification part of how you reward engineering managers. Then go back to the AI roadmap with a straight face.

References

• Some Supabase customers are publicly exposing reams of people's data to the web — TechCrunch
• Supabase Row Level Security docs
• Related: The Agent Stop Line Playbook
• Related: The Age of Proactive AI

---

CTA: Running People + AI with real production risk? Start with the free AI Readiness Scorecard, skim related posts on the blog, or bring me in for a CHRO/CEO workshop on shipping authority and agent governance. Podcast angle on month-four AI failures: guest brief.