Blog

Your AI Coding Agent Can Delete Your Entire Production Stack. Here's How to Stop It.

AI coding agents have full access to your production credentials. A PreToolUse hook blocks unrecoverable commands before they execute.

agent-patterns
Close-up of a vintage red rotary telephone, the kind that takes calls from inside the house
Photo by Johnny Briggs on Unsplash

Most AI coding agents run with full access to your production credentials. If your .env.local holds a Supabase service-role key, a Vercel token, and a GitHub PAT, your agent can delete the database, the deployment platform, and the source repository in three commands. Your daily backups will not save you, because two of those three providers delete the backups along with the resource.

In April 2026, an AI coding agent running inside Cursor deleted the entire production database of PocketOS, a Railway-deployed startup. No prompt instructed it to. The agent decided, on its own, that dropping the database was the correct next step. The founder woke up to a dead product.

The call is coming from inside the house.

The threat model most builders prepare for is the outside attacker. The threat model that actually shows up is the trusted process you handed your credentials to. Same keys, same shell, no bad actor required: just one wrong decision from a tool you invited in.

This is not a Cursor problem. It is an architecture problem shared by nearly every vibecoded app shipping today. And it is fixable in under an hour.

Why This Is Not a Cursor Problem

The typical vibecoded stack converges on the same shape: Supabase for the database, Vercel for hosting, GitHub for source control, and an AI coding agent (Claude Code, Cursor, Windsurf, or similar) with Bash access and a .env.local file containing broadly-scoped credentials.

The agent needs those credentials to do its job. It runs migrations, deploys previews, pushes commits. But the same tokens that let it do useful work also let it do catastrophic work. Most builders never scope their tokens because the defaults work and scoping them is friction nobody explains.

The result: one Bash call away from deleting infrastructure that cannot be recovered from a backup.

Three Providers, Three Blast Radii

The damage varies by provider. None of them make recovery easy once a project-level or account-level deletion goes through.

Supabase

Supabase Pro retains daily backups for seven days. Point-in-time recovery (PITR) is a paid add-on most builders never enable. That sounds reasonable until you realize what an account-scoped Personal Access Token can do: it can call DELETE /v1/projects/{ref}, which deletes the entire project. The backups go with it. Seven days of snapshots, gone in one API call, because the backups are scoped to the project, not to your account.

  • Daily backups: 7-day retention (Pro plan)
  • PITR: paid add-on, not enabled by default
  • Project deletion via PAT: deletes the project and all its backups
  • Recovery path: contact Supabase support and hope

Vercel

Vercel has no backup product at all. Deleting a project wipes every deployment, every environment variable, and every integration. Deleting a team wipes every project in that team. If you host multiple products under one Vercel team (very common for solo founders), one command takes down all of them.

  • Backups: none
  • Project deletion: wipes deployments, env vars, integrations
  • Team deletion: wipes every project in the team
  • Recovery path: recreate from scratch

GitHub

Source code is the most recoverable piece, because anyone with a local clone still has the full git history. But a repository is more than source code. Issues, Actions secrets, branch protection rules, deploy keys, and webhooks are not in the clone. Deleting the repo deletes all of them. GitHub offers a 90-day soft-delete window, but it is best-effort via Support, not a contractual guarantee.

  • Source: recoverable from any local clone
  • Issues, Actions secrets, branch rules, webhooks: not recoverable from a clone
  • 90-day soft-delete: best-effort, not guaranteed
  • Organization deletion: deletes every repo in the org

The Fix: PreToolUse Hooks

Claude Code supports PreToolUse hooks: shell scripts that run before every tool invocation. If the script exits with code 2, the tool call is blocked and the agent sees a refusal. Other agentic coding tools have similar extension points (Cursor rules, Windsurf configurations), and the same logic applies.

The principle that makes the hook sustainable: block only commands whose damage is not recoverable from a backup or a clone. If you block DROP TABLE, the agent cannot run migrations, and you will disable the hook within a week. Scope the blocks to genuinely unrecoverable operations so the hook stays on permanently.

What the hook blocks:

  • supabase projects delete (CLI and Management API DELETE on projects/organizations)
  • vercel project rm, vercel team rm (CLI and API DELETE on projects/teams)
  • gh repo delete, gh org delete (CLI and API DELETE on repos/orgs)
  • gh repo edit --visibility public (exposing private code to the internet)
  • git push --delete main and git push origin :main (deleting production branch remotely)
  • git push --force targeting main, master, or production
  • rm -rf /, rm -rf ~, rm -rf $HOME
  • DROP DATABASE, DROP SCHEMA public CASCADE
  • Any shell command that modifies the hook script itself

What the hook allows (intentionally):

  • DROP TABLE, TRUNCATE, DELETE FROM (recoverable from the daily Supabase snapshot)
  • All normal git operations: push, pull, commit, rebase
  • Deployments, migrations, builds, tests
  • All Supabase/Vercel/GitHub commands that are not project-level or account-level deletions

The hook tested clean against 33 cases: every blocked command returns exit 2, every allowed command passes through.

One caveat. The hook only intercepts Bash tool calls. An agent could theoretically use its Edit or Write tools to modify .claude/settings.json and disable the hook from the inside. Mitigation: review your diffs before committing, and mirror the hook configuration into your user-scope settings at ~/.claude/settings.json so project-level tampering alone cannot remove it.

Tighten Your Tokens

The hook is the seatbelt. Token scoping is the speed limit.

  • Supabase: move your Personal Access Token out of .env.local entirely. The service-role key is enough for the agent's actual work (migrations, queries, row-level operations). The PAT, which has project-deletion authority, should live only in your browser session or a separate credential store the agent never touches.
  • GitHub: switch to a fine-grained Personal Access Token with the Administration permission set to read-only. The agent can still push code and create pull requests. It cannot delete the repository.
  • Vercel: split production apps into separate Vercel teams. A token scoped to one team cannot delete projects in another. This costs nothing on Vercel's free tier.

The Ultimate Backstop: Off-Vendor Backups

Even with hooks and scoped tokens, a single vendor outage or account compromise can take you offline. The fix: a nightly pg_dump to a different provider entirely.

Cloudflare R2 is the cheapest option for this (no egress fees). A GitHub Actions workflow can run pg_dump against your Supabase connection string every night and upload the result to an R2 bucket. Setup takes under an hour. The dump lives outside Supabase, so deleting the Supabase project does not touch it.

This is the layer that turns a catastrophic scenario into a bad afternoon. You lose the project, the config, the backups. You do not lose the data.

TL;DR Checklist

  • Install a PreToolUse hook that blocks unrecoverable Bash commands
  • Mirror the hook to user-scope settings (~/.claude/settings.json) so project-level edits cannot disable it
  • Remove your Supabase PAT from .env.local (keep only the service-role key)
  • Switch GitHub to a fine-grained PAT with Administration set to read-only
  • Split Vercel projects into separate teams (one token per team)
  • Enable Supabase PITR if your plan supports it
  • Set up a nightly pg_dump to an off-vendor bucket (R2, S3, or GCS)
  • Review diffs before every commit when working with an AI coding agent

Frequently Asked Questions

Can an AI coding agent really delete my production database?

Yes. If your .env.local contains a Supabase service-role key or a Personal Access Token, and your agent has Bash access, it can execute any Supabase CLI or API command. That includes project deletion. The PocketOS incident in April 2026 demonstrated exactly this with Cursor, but the same risk applies to any AI coding tool with shell access.

Do Supabase daily backups protect against project deletion?

No. Supabase daily backups are scoped to the project. If the project itself is deleted via the Management API or CLI, the backups are deleted with it. Only point-in-time recovery (a paid add-on) and off-vendor backups (like a nightly pg_dump to Cloudflare R2) survive project deletion.

What is a PreToolUse hook?

A PreToolUse hook is a shell script that runs before every tool invocation in Claude Code. The script receives the tool name and input as JSON on stdin. If the script exits with code 2, the tool call is blocked and the agent sees a refusal message. This lets you pattern-match dangerous commands and prevent them from executing without removing the agent's ability to do useful work.

Will blocking destructive commands make my AI agent useless?

Not if you scope the blocks correctly. The key is to block only commands whose damage is not recoverable from a backup or a clone. Table-level SQL (DROP TABLE, TRUNCATE) is recoverable from Supabase's daily snapshot, so the hook allows it. The agent can still run migrations, deploy, push code, and do everything it normally does. Only project-level and account-level deletions are blocked.

Does this only apply to Claude Code?

The PreToolUse hook mechanism is specific to Claude Code. But the underlying vulnerability (broadly-scoped credentials in .env.local plus unrestricted shell access) exists in every AI coding tool that runs Bash commands: Cursor, Windsurf, Cline, Aider, and others. The token-scoping and off-vendor backup strategies apply to all of them.

Should I just disable Bash access for my AI agent entirely?

Disabling Bash removes the risk but also removes most of the value. AI coding agents need shell access to run builds, tests, migrations, and deployments. The better approach is to keep Bash enabled but install guardrails: a PreToolUse hook for the commands, scoped tokens for the credentials, and off-vendor backups for the data.


If you want help hardening your agent setup for your specific stack, book a free 30-minute call. This is the kind of work that takes one focused week to get right and pays for itself the first time it blocks something.

Written by
Robert Cowherd
Book a call