DEV Community: Ohad Krispin

16,326 Supabase databases are readable by anyone. Here's how to check yours in two minutes

Ohad Krispin — Fri, 02 Oct 2026 19:12:20 +0000

UpGuard Research looked at about 300,000 domains that use Supabase and found 16,326 databases exposing tables that anyone could read. Over half had signs of personal data. Some had passwords or authentication tokens.

These weren't abstract records. A US valet service exposed over 100,000 customers, about 78,000 of them with license plate numbers. A Canadian immigration coaching service had 884 passwords stored in plain text. A consulate exposed 25,000 people with their home addresses.

Supabase itself wasn't breached. Every one of these was a configuration problem in the app.

Why this keeps happening with AI-built apps

The line in UpGuard's report that matters most for anyone building with Lovable, Bolt, Cursor or Claude Code:

"Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default."

When you create a table in the Supabase dashboard, row level security is switched on for you. When your coding agent creates it through a migration or the API, it isn't. Your frontend ships the anon key to every visitor, and with RLS off, that key can read and change the whole table through the Data API.

The second pattern is the service role key. It bypasses RLS completely, and agents sometimes put it in a variable like NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. Anything with NEXT_PUBLIC_ ends up in the browser bundle.

Check 1: in the database (free, 30 seconds)

Open the SQL editor in your Supabase project and run:

select schemaname, tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Every row it returns is a public table without RLS. If any of them hold user data, enable RLS and add policies before anything else:

alter table public.your_table enable row level security;

Then add a policy for who can actually read it. Enabling RLS with no policy blocks everyone, which is safe but will break your app until you add one.

One trap this query misses: views. Supabase's own docs say "Views bypass RLS by default because they are usually created with the postgres user." A view over a protected table can hand out every row. On Postgres 15 and above, create views like this so they follow the table's policies:

create view public.your_view
with (security_invoker = true)
as select ...;

Check 2: in the repo (free, before you deploy)

The SQL check sees today's database. It doesn't see the migration your agent is about to push, or a key sitting in a client file.

I built a free command line check for this, VibeRaven. It runs on your machine and reads the repo: migrations, env files and client code. It never asks for your database credentials.

npx -y viberaven@1.6.1 check

Here's what it prints on a small Next.js + Supabase test app with two common mistakes:

🔴 No RLS policy proof in migrations  (rls_disabled)
   1 public table without row level security: public.profiles
   (supabase/migrations/0001_init.sql:1). Anyone holding the anon key your
   frontend ships can read and change those rows through the Data API.
🔴 Service role key in a client-prefixed env variable  (service_role_key_in_client_env)
   .env.example:3: NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY names a service role
   or secret key under the NEXT_PUBLIC_ prefix. NEXT_PUBLIC_* variables are
   exposed to client code by Next.js, so anyone who loads the app can read it
   and skip RLS entirely. Rename it without the prefix, read it only in server
   code, and rotate the key.
🟡 A policy lets anyone read every row  (rls_policy_allows_all_read)
   Policy "anyone can read notes" on public.notes lets anyone, signed in or
   not, read every row: using (true). Fine for truly public content; wrong for
   anything per-user.

Each finding names the file and line, so you can hand it straight to your agent.

What it can't do: it reads files, so a policy someone changed by hand in the dashboard is invisible to it. Use the SQL check above for that. It's advice for you to act on, not a security audit.

The short version

Run the SQL query. Any table it lists with user data needs RLS today.
Search your env files for NEXT_PUBLIC_ next to anything called service role or secret. If you find one, move it server side and rotate the key.
Before your agent's next migration ships, check the repo too.

And one date to know: Supabase is changing how new tables reach the Data API. From October 30, new tables in existing projects stop being exposed automatically. That helps, but it doesn't fix the tables you already have.

UpGuard's full report: https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps

Your AI agent has amnesia. Your logs are the cure.

Ohad Krispin — Mon, 13 Jul 2026 21:58:02 +0000

I'm going to show you what's hiding in your AI coding logs, and how I turned nine months of mine into a file my agent reads before every task.

Every agent starts cold

Every Claude Code or Codex session you run gets written to disk. Full transcripts. Nobody ever opens them.

And every new session, the agent meets you for the first time again. You re-explain how you work, what you want, what you never want. Every single time.

Your logs already know you

I had nine months of those logs. 1,870 sessions, just sitting in a folder doing nothing.

At some point it clicked that they were the most honest record of how I actually work. More honest than my rules file, my docs, anything I wrote down on purpose.

Rules files are aspirational. Logs are behavioral.

Your CLAUDE.md is who you think you are on a good day.

Your logs are who you actually are. Every time you stopped the agent. Every "no, just fix the one thing." Every time you refused to accept "done" without proof. You never wrote those rules down. You enforced them, hundreds of times, without noticing.

What's actually in there

Raw logs are mostly noise: tool output, file dumps, pasted errors. Nine months of mine boiled down to about 3M tokens of just my own typed words.

That corpus knows things like:

what "done" means to you
what you reject on sight
when you demand proof instead of trusting the agent
how you actually talk when you're working
the behaviors that make you kill a task

The mine

So I built Ditto. Open source. It reads the local logs, keeps only your words, redacts secrets, splits your history into slices, and has agents read each slice for repeated patterns. A rule only survives if it shows up across multiple distinct sessions, and every rule keeps dated quotes as receipts.

Then it installs the result as a skill your agent loads before every task.

What changed

Same model. It just stopped guessing.

It quit suggesting the rewrites I always reject. It shows me proof before it says done, because my own history told it I never accept done without one.

Not a smarter agent. The same agent, finally briefed on who it's working for.

The red part

When the mine finishes it renders a card: your archetype, your top laws ranked by how many real sessions back them, and one line it calls the uncomfortable truth. The thing your history proves that you'd never say about yourself out loud.

Run it and read your own.

The card

your logs are the most honest record of how you work
rules files are aspirational, logs are behavioral
a rule only counts with receipts from multiple real sessions
everything stays on your machine
your agent reads it before every task

One command:

npx skills add ohad6k/ditto

ohad6k / ditto

Mine your Claude Code and Codex logs into a local you.md agent profile.

Ditto

Your AI agents act like they just met you. Ditto fixes that.

Your real coding-agent sessions already contain the rules you never wrote down: what “done” means, what you reject on sight, how you debug, how you design UI, and how you write when you are actually working.

Ditto mines selected evidence from those sessions — Claude Code, Codex, Copilot CLI, and OpenCode logs out of the box — into a private working profile your agent reads before every task. Separate layers for work, design, and writing mean the right part of you loads for the right task.

Not memory

Memory is what you explicitly told the model.

Ditto mines what your work already proved about you: what you reject, what "done" means, when you ask for proof, how you talk when you're actually working, and the agent behaviors that make you stop the task.

That's why it reads…

View on GitHub

Your AI coding agent starts every session like it just met you

Ohad Krispin — Fri, 10 Jul 2026 10:26:51 +0000

Your AI coding agent starts every session like it just met you

I have eight months of Claude Code and Codex logs sitting on my disk. Roughly 1,600 sessions, close to 3 million tokens of me actually working. Every argument about whether something was "done," every time I rejected a design, every "no, do it this way." It is the most honest record that exists of how I think when I build.

And every new session, my agent reads none of it. It starts from zero. Polite, capable, and with no idea who it's talking to.

So I built a small tool to fix that. It's called Ditto, it's one Python file, and it's open source.

Memory is what you told the model. This is what your work proved.

Most "memory" for agents is a file where you write down facts about yourself. Your stack, your preferences, your rules. That's fine, but it has a problem: it's you performing for the agent. You write the version of yourself you think you should be.

Your session logs are the opposite. Nobody performs in a debugging session at 1am. The logs hold what you actually reject, what "done" actually means to you, when you actually stop and ask for proof, how you actually talk when you're heads-down. That's the raw material Ditto reads. Not your CLAUDE.md. The real transcripts.

It mines those into a you.md your agent loads before every task.

How it works (the whole thing is auditable)

There's no service, no account, no magic. It's a stdlib Python script you can read top to bottom:

It finds your local session logs (~/.claude, ~/.codex, Copilot) and pulls out the messages you typed. Not the agent's replies. You.
It redacts secrets and PII before anything is written to disk. Keys, tokens, emails, the usual. This happens first, not as a cleanup pass.
It dedupes the long repeated blocks (the same spec pasted 40 times) so you're not mining noise.
It writes the redacted corpus into chunks sized for an agent to actually read.
You point your coding agent at those chunks with the included mining prompt, and it compiles a you.md: your working laws, your taste, the agent behaviors that make you stop the task, with real quotes as evidence.

The extractor itself makes zero network calls. The only text that reaches a model is the redacted chunks you hand to your own agent, in your own tool. On a local model, the whole thing stays on your machine.

What actually changes

Here's a real run. I asked an agent to help me launch this repo. One line: "help me post ditto on reddit." Same model, once cold, once with my Ditto profile loaded.

Cold, it gave me the confident generic thing: a title with a colon in it, three bullet points about "key features," an emoji, a call to action. The kind of post that reads like every other launch and gets scrolled past.

With my profile loaded, it wrote the way I actually post. Lowercase, no hype, led with the uncomfortable part instead of the feature list, and stopped trying to sell. Because the logs had taught it that I reject exactly that kind of launch copy, every time.

That's the difference. Not "the agent knows my name." The agent makes the same taste calls I would have made, so I'm editing instead of rewriting.

What it doesn't do yet

Being honest, because this is early open source:

It samples your history, it doesn't read every token of it. A rare habit you only showed once might not make the cut. That's a deliberate tradeoff against cost, and I'm calibrating where the line sits.
The profile is only as good as your logs. If you've done two weeks of coding with an agent, there isn't much to mine yet.
It reads how you work, not what you know. It won't replace your notes or your docs. It sits next to them.

Try it and tell me the weird one

If you run it, the interesting moment is when it surfaces something true about you that you never wrote down. When that happens, post the single weirdest trait it found. Not your whole you.md, just the one line that got you.

Repo: github.com/ohad6k/ditto

If it breaks, or it misses something about how you work that it should have caught, open an issue. Every real history I get to test it against makes the mining sharper.

AI Can Build the Prototype. Production Is Still the Hard Part.

Ohad Krispin — Thu, 18 Jun 2026 16:02:07 +0000

AI coding tools make it very easy to get an app running.

But getting from “it works locally” to “real users can depend on this” is still where things get messy:

auth providers
environment variables
Supabase/RLS
webhooks
billing
deployment settings
provider dashboards
monitoring
version control hygiene

I built VibeRaven as an open-source tool to help with that gap.

Instead of treating production readiness as a vague checklist, it scans the repo and creates a mission map of what exists, what is missing, what needs provider action, and what should be verified before launch.

GitHub:
https://github.com/ohad6k/VibeRaven

Run it with:


bash
npx -y viberaven