Your AI agent will eventually delete your database. Here's the seat-belt.

2026 has been a brutal year for vibe-coded Supabase projects. The same failure mode keeps eating production: an AI agent did a thing the human didn't fully understand, and by the time anyone noticed, the data was either on the public internet or gone.

I built Agent Sentry on top of Suparbaseas a direct response: a continuous security watchdog plus a per-agent safety net. This post walks through the incident pattern that motivated it, why the existing tools miss it, and how Sentry catches both halves.

Three 2026 incidents, one shape#

These three are public. There are dozens more in private Slack post-mortems.

• Moltbook (January): launched the 28th, leaked 1.5M API keys and every user record by the 31st. The AI built tables without RLS; the anon key worked as a master key against the REST surface. Post-mortem.
• Lovable CVE-2025-48757 (February): a scan of 1,764 vibe-coded apps found 453 with critical vulnerabilities. 170 had inverted RLS, “if you're logged in, you can read every row.” 80% of vibe-coded apps share that exact mistake. Scan write-up.
• PocketOS (April): Cursor's Claude Opus 4.6 agent hit a credential mismatch, found a Railway token in an unrelated file, and deleted the volume. Database and backups, gone in 9 seconds. Tom's Hardware.

Why existing tools miss them#

There's a whole cottage industry of Supabase scanners now, and every single one shares the same shape. They're point-in-time scans, or they're loggers, or they're both. None of them combine continuous probing with the kill-switch.

• AuditYourApp, SupaSec, the open-source supabase-security-skill: all do one-shot scans. Great for a baseline. Useless once the AI edits the schema an hour later.
• Supabase's own Security Advisors (Splinter): weekly emails. Better than nothing. By the time you read it, the breach has been live for days.
• PGAudit, Postgres logs: record everything. Tell you nothing about which agent did what or how to undo it.
• Replit checkpoints: actually work for project-state rollback. Only inside Replit. Don't help when Cursor / Claude Code / Lovable / v0 / your own MCP server are the agents.

What Agent Sentry does#

Two halves. Together they cover both incident classes, the RLS-leak class (Moltbook, Lovable) and the agent-nuke class (PocketOS).

The probe loop#

For every table in the public schema, Sentry fires a single unauthenticated GET /rest/v1/<table>?limit=3 with the stored anon key. A 200 with rows means anon can read it. A 200 with an empty array means RLS is correctly hiding the rows (no false positive). 401/403 means RLS is doing its job.

When the connection has the Direct Postgres URL set, Sentry also reads pg_class.relrowsecurity + pg_policy to catch tables where RLS is off outright, tables with zero policies, and policies whose USING clause is just true, the inverted-logic mistake from CVE-2025-48757.

SELECT n.nspname, c.relname, c.relrowsecurity,
       jsonb_agg(json_build_object('policy', p.polname,
                                    'qual', pg_get_expr(p.polqual, p.polrelid)))
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_policy p ON p.polrelid = c.oid
WHERE c.relkind = 'r' AND n.nspname = 'public'
GROUP BY n.nspname, c.relname, c.relrowsecurity;

Anon-readable tables get matched against a conservative PII column-name pattern: password, secret, api_key, refresh_token, ssn, credit_card, phone, email, address, dob, passport. Hits jump from warn to critical. When a critical finding lands, the Quarantine button applies a temporary RESTRICTIVE policy:

ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;
CREATE POLICY suparbase_sentry_<id>
  ON public.users AS RESTRICTIVE
  FOR ALL TO anon, authenticated
  USING (false);

The bleeding stops. The Lift button drops the policy when you've fixed the underlying issue.

Agent attribution#

Suparbase's PostgREST proxy already touched every authenticated write. v3.1 adds a fingerprinter that reads the User-Agent and buckets the request into an agent_session row. Cursor, Claude Code, Replit Agent, Lovable, v0, the Vercel AI SDK, and OpenRouter are all recognised by their UA. Anything that mentions an LLM-related term but doesn't match a specific vendor falls into ai_unknown. Real browser sessions and CLI tools fall into browser / cli so you can spot human curl traffic vs. agent fetch traffic.

Sessions extend on a 5-minute rolling window per (user, connection, agent_kind). One agent “refactor” doing 47 mutations across 3 tables lands in one session row, not 47.

One-click session undo#

Every audit-log row now links back to its session. Undo walks those rows newest-first and builds reverse SQL per verb:

• INSERT → DELETE FROM ... WHERE pk = ...
• UPDATE → UPDATE ... SET (beforeRow cols) WHERE pk = ...
• DELETE → INSERT INTO ... VALUES (beforeRow)

All of them run in one Postgres transaction via the Direct Postgres URL. Either every reversal succeeds, or none does. PocketOS would have had a button.

Wire it up#

1. Connect your Supabase project at Suparbase and add the API key.
2. Add the optional Direct Postgres URL on the connection page - Sentry's pg_policies inspector and the undo engine both use it.
3. Open /c/<id>/sentry, hit Scan now. Baseline your exposure today.
4. Open /c/<id>/agents. Every AI write your team ships through Suparbase from now on lands in a session you can undo.

Suparbase has a free hosted tier for solo projects, no credit card required. The full Sentry feature page has the FAQ + a side-by-side with the existing scanner cottage industry.