database-safety

Baseline

Applies when: Any SQL execution, ORM write, schema operation, migration command, or query-string construction against a real database, especially prod/production/live/customer environments.

Always:

• Require a WHERE clause on every DELETE, UPDATE, or MERGE (and ORM equivalents) unless the user has explicitly confirmed "all rows."
• Run the matching SELECT COUNT(*) with the same predicate and show the count before any mutating statement; the count is what the user approves.
• Wrap every mutating statement in an explicit transaction (BEGIN/COMMIT) opened by the agent; never autocommit against a production-class database.
• Clear all three migration gates in order: dry-run on a staging clone, backup taken in the same maintenance window, and a tested reversible migration (or approved restore procedure).
• Parameterize every query through driver-level binding; never build SQL by concatenation, f-strings, or ORM raw-query helpers that bypass binding.
• Identify rows by primary key and redact sensitive columns when debugging; never log full rows or copy production data downstream.

Never:

• DELETE/UPDATE/MERGE without a WHERE clause, or ORM equivalents like Model.objects.all().delete() or prisma.model.deleteMany({}) with an empty where.
• A mutating statement run in autocommit mode against a production-class database.
• A migration run straight against production with no dry-run, no backup, no rollback.
• SQL built by string concatenation, f-strings, template literals, or raw-query ORM helpers.
• Copying production rows into development, staging, or any lower-controlled environment, "just for testing."

Open the full component before acting: it has the examples, the remediation steps, and the detection patterns.

Why

Database state is the asset that survives every deploy. Compute can be rebuilt from images in minutes; rows cannot be rebuilt from anywhere except the last backup. Most catastrophic AI-assisted incidents at the database layer follow the same three shapes: