Stop Your AI Coding Assistant From Deleting Your Data (Free Template)

If you're using an AI coding assistant to build or maintain your product—Claude Code, Cursor, GitHub Copilot, Windsurf, whatever's in your stack—it will eventually reach for a destructive command. A dropped database, a force push, an rm -rf in the wrong directory. Not out of malice. Out of a chain of reasonable-sounding assumptions that end somewhere you didn't want it to go.

The pattern is almost always the same: something errors, the assistant infers the data is "probably already gone" or "no longer needed," and it acts on that inference instead of checking with you first. That's a judgment call it shouldn't be making alone, and most AI coding tools don't stop it by default.

Why This Happens

AI coding assistants are optimized to be helpful and to keep moving. When they hit an obstacle, the instinct is to resolve it and continue—not to pause and ask permission. That's usually a good trait. It's a dangerous one the moment the "fix" is irreversible.

The fix isn't a smarter model. It's a written rule the assistant has to follow before it's allowed to touch anything destructive—one that removes the judgment call entirely and replaces it with a checklist.

The Template

Drop this into your project as a rules file—CLAUDE.md, AGENTS.md, or whatever config your tool reads—and fill in the brackets. For Cursor, save it as .cursor/rules/safety-guardrails.mdc with alwaysApply: true in the frontmatter, since Cursor only loads .mdc files that have it. Otherwise it's just plain instructions the assistant reads before acting.

# Critical Safety Instructions for [Your Project Name]

## DESTRUCTIVE COMMANDS — ABSOLUTE BLOCKS

Never execute these without explicit user confirmation in chat:

- DROP DATABASE / dropdb
- DELETE FROM (entire tables or large, unfiltered data operations)
- TRUNCATE
- DROP TABLE
- rm -rf
- git reset --hard
- git push --force
- Deleting or overwriting cloud storage buckets/objects
- Revoking API keys, credentials, or access
- Any command that permanently deletes data or is not easily reversible

## Pre-Execution Checklist (Mandatory)

Before executing ANY destructive operation:

1. Ask the user explicitly — state the exact operation, what will be
   affected, and ask for confirmation.
2. Wait for explicit confirmation — the user must say "yes",
   "confirmed", or "proceed" (not just "ok" or silence).
3. Never rationalize away safety. Watch for these thought patterns —
   they are the moment to stop and ask, not proceed:
   - "The error says it doesn't exist, so it's probably safe to delete."
   - "I checked and couldn't find the data, so deletion is safe."
   - "The connection failed, so the data must already be gone."
4. Verify first — always inspect before you delete.
5. Back up second — if data exists, back it up before touching it.
6. Delete third — only after confirmation and backup, proceed.

## Application

These rules apply to database operations, file system operations on
critical directories, git history rewriting, cloud infrastructure and
deployment, and any environment/configuration change that affects a
running system. When in doubt, ask the user first.

The full version—with a pattern example and a section for logging your own near-misses—is available as a free download below.

Download the full safety guardrails template (.md)

The One Section Worth Customizing

The template has a spot for you to record what actually happened, once something does happen. That section matters more than any other line in the file. A generic rule reads as boilerplate to an assistant weighing a decision under pressure. A rule attached to a real, specific incident—the exact command, the wrong assumption that led to it, what was lost—reads as a hard boundary. If you've already had a near-miss, write it down there. If you haven't yet, leave the placeholder and fill it in the first time you do. The file is meant to get sharper over time, not stay static.

Where to Put It

Most AI coding tools look for a specific file automatically:

• Claude Code: CLAUDE.md (project root) or .claude/CLAUDE.md
• Cursor: .cursor/rules/safety-guardrails.mdc with alwaysApply: true in the frontmatter (or AGENTS.md, no frontmatter needed)
• GitHub Copilot: .github/copilot-instructions.md
• Windsurf: .windsurfrules

If your tool doesn't auto-load a rules file, paste the template at the start of any session where the assistant will have access to a database, production files, or git history.

This costs five minutes to set up. Compare that to the time it takes to rebuild a database from a backup that doesn't exist. When we build and maintain automations for clients, this kind of guardrail goes into every project by default—not because the AI is untrustworthy, but because a five-minute checklist is cheaper than any afternoon spent recovering from a command that should have asked first.