AI-Generated Destructive SQL Requires Human Review Before Execution

# AI-Generated Destructive SQL Requires Human Review Before Execution ## Claim Any AI-generated destructive SQL statement (DELETE, DROP, TRUNCATE) needs a manual scope check before it runs, because an unbounded or mis-scoped WHERE clause turns a targeted cleanup into full data loss — and this holds regardless of how confident or well-tested the AI's other output has been in the same session.  ## Evidence [[3. Resources/Literature Notes/Cleaning WordPress Malware Infections With AI]] reports this as Step 7 of Hasin Hayder's incident-response process: after an AI model scans a `wp db export` SQL dump and identifies spam/malicious rows by ID, the same model is asked to generate one DELETE statement targeting those IDs — but Hayder is explicit that this must be manually verified before running, warning that a bare `DELETE FROM` without a scoped WHERE clause wipes the entire table. He frames this with a deliberately memorable caution to slow down and check rather than trust the automation, precisely because the earlier steps in the same workflow (the multi-model malware scan that found a real backdoor — the [[3. Resources/Literature Notes/Cleaning WordPress Malware Infections With AI#Multi-model AI scan finds a real backdoor cheaply|H3 atom]]) had just demonstrated the AI's output could be trusted for detection. ## Scope & conditions - Holds for any AI-agent-assisted remediation workflow, not just WordPress malware cleanup — applies equally to AI-suggested database migrations, cache-clearing scripts, or file-deletion commands in any codebase. - The risk is specifically execution-safety, not general trust in AI output — a model can be reliably accurate at *detection* (as in the same workflow's earlier steps) while still needing a scope check on the *remediation* command it drafts, because detection accuracy and command scoping are different failure modes. - Doesn't require distrusting the model's judgment about *what* to delete, only verifying *how narrowly* the resulting command is scoped before it runs. ## Links - [[3. Resources/Permanent Notes/Human Review Capacity Sets the Agent WIP Limit]] — because applies-in: a destructive-command review step is exactly the kind of checkpoint that caps how much unattended agent work can safely run in parallel. - [[3. Resources/Permanent Notes/Automated Guard Rails Should Match Mechanical Verifiability]] — because extends: a destructive SQL statement's scope is mechanically verifiable (read the WHERE clause) before execution, making it a natural place to enforce a hard gate rather than relying on trust. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — because applies-in: a concrete safety gate for any AI-assisted WordPress incident-response runbook. - [[3. Resources/MOCs/AI Agent Safety MOC]] — applies-in: Joins the agent failure-mode and human-review cluster. ## Maintenance - Last tended: 2026-08-19 - Next review: 2026-11-19