Skip to content
suparbase
All articles
Articleaivibe-codingsafetydatabases

When AI Agents Shouldn't Touch Your Database

Vibe coding is great. There's a short list of operations where the human still needs to be in the loop. Here's the list, why each one, and the controls to enforce it.

10 min read

We're bullish on AI in the database loop. We've built it. We also have a list of operations where the agent stays in the seat-not-the-pilot. The list is short, the reasons are concrete, and the controls are simple enough to ship in a week.

The five operations

  1. Destructive operations: DROP, TRUNCATE, mass DELETE.
  2. Operations on compliance-tagged data (PII, PHI, billing).
  3. RLS policy changes in production.
  4. Service-role-key operations that affect many rows.
  5. Anything that can't be rolled back without backups.

Destructive operations

AI agents in 2026 still occasionally produce confident, wrong, and irreversible SQL. The cost of a wrong DROP TABLE on a production table is the cost of restoring from your most recent backup, which is always more than the cost of one human glance.

The rule: any DDL that drops or truncates a table or schema requires a human approval step, not just a code review.

Compliance-tagged data

Tables that carry PII, PHI, payment data, or anything regulated have a paper trail requirement. "An AI agent wrote this query" isn't an answer regulators love. Tag those tables and require a human-confirmed proposal for writes against them.

RLS policies in production

An AI-written RLS policy can look correct and be wrong. The failure mode is silent - a user sees a row they shouldn't, forever, until someone notices. Test policy changes with a real simulator (see our RLS guide); have a human review the test output.

Specifically: don't let the agent write or modify a policy in the same PR as a feature change. Policies get their own PR, their own review, and their own deployment.

Service-role writes at scale

Service-role keys bypass RLS. An agent given a service-role key can affect every row in every tenant. The corruption pattern: agent misreads the prompt, fires an UPDATE without the right WHERE, you're restoring from backup.

The rule: service-role operations are gated by a named function in your codebase, with the function's code reviewed by a human, with an audit-log entry per call.

How to enforce these

  1. Don't give the agent service-role keys in dev. Default to anon/authenticated. Service-role is opt-in per operation with a comment.
  2. CI check on DDL. Any PR with DROP or TRUNCATE in a migration file requires two human approvals.
  3. Tag your tables. A `compliance` column comment or a table in public.compliance_tags. Your AI review script reads it; PRs that touch tagged tables get a stricter checklist.
  4. Propose-then-execute for AI writes. The chat agent doesn't write; it drafts a proposal. The human clicks Apply. The server re-validates. Every step audit-logged.
  5. PR templates with the "agent involvement" checkbox. If the PR was written primarily by an AI, the template asks specific questions. Reviewers see it.

The point isn't to slow down vibe-coding. It's to make sure the small set of operations that can't be undone gets the small amount of friction it needs to stay safe. Everything else the agent can do at full speed.

Suparbase is an admin workspace for Supabase. Encrypted credentials, server-side proxy, RLS debugger, SQL playground, AI assistant with diff-confirmed writes. Free tier for solo projects.

Try Suparbase freeSee all features

Related articles