Building AI Guardrails for Critical Database Operations

Guardrails Are Engineering, Not Policy

A prompt that says “be careful with destructive operations” is not a guardrail. It is a wish. A guardrail is a mechanism that makes the bad outcome impossible, or at least impossible to reach by accident, and it lives in the code rather than in the instructions.

These are the ones that matter when software can execute against a production database.

1. Allowlist the Operations

The assistant cannot run arbitrary SQL. It can invoke a fixed set of named operations — assess, plan, transpile, migrate a table, validate — each with a typed signature. There is no general execute_sql tool, because a general tool makes every other guardrail decorative.

2. Classify by Consequence

Every operation is marked destructive or not, at definition time, in code. Reads are free; anything that writes, drops, or truncates carries the flag and cannot be invoked without passing the confirmation gate. The classification is a property of the tool, not a judgement the model makes per call — models are not the right place to store a safety invariant.

3. Confirm Per Action

Every destructive call stops and names what it is about to do, to which object, on which target. Approval never generalises from a previous yes — the point of the gate is that the fifth action is not the one you agreed to.

4. Bound the Blast Radius

• Read-only by default. Assessment connects with credentials that cannot write. The safest guarantee is the one the database enforces, not the one the application promises.
• Target confirmation. Destructive operations name the host and database in the prompt. “Wrong environment” is a far more common failure than “wrong statement”.
• Transactional where possible. PostgreSQL has transactional DDL — use it, so a failed step rolls back rather than leaving a half-built schema.
• Idempotence. Re-running a step should converge, not duplicate. This is what makes recovery from a partial failure safe.

5. Log Everything, Append-Only

Every invocation: what was called, with what arguments, what came back, and whether a human approved it. Without this you cannot answer the only question that matters after an incident — what actually ran — and “the tool did it” stays an argument instead of a fact.

6. Make Refusal a First-Class Outcome

The system must be able to produce nothing. A tool that always emits something will emit something wrong when it doesn’t know, and wrong output is more expensive than absent output — it consumes review attention and it looks finished.

Test the Guardrails Like Features

The failure mode of safety work is that nobody exercises it until it is needed. So the gates carry tests the same as anything else: a destructive call without approval must fail, an unknown operation must be rejected, a refused conversion must produce a gap entry rather than output. A guardrail without a test is a comment.