Stop destructive agent SQL: hold DROP, TRUNCATE and WHERE-less updates

Not every write is dangerous, so gate precisely. The clear destructive patterns are the irreversible or wide-blast ones: DROP TABLE and DROP DATABASE, TRUNCATE, DELETE without a WHERE clause, UPDATE without a WHERE clause (the classic that rewrites every row), and schema-altering statements like ALTER and the various DDL commands. These are the queries where a mistake isn't a bad row, it's a lost table.

Scoped writes — an INSERT, an UPDATE or DELETE that targets specific rows by id — are usually routine and shouldn't be held, or your queue fills with noise and reviewers stop reading. The art is gating the shape that signals danger (the missing WHERE, the DROP, the TRUNCATE) rather than the operation type wholesale. That keeps human attention on the queries that can actually wreck the database.

agent·shield sits as a transparent proxy in the path between the agent and the database's HTTP-accessible endpoint. Because the SQL lives in the request body, agent·shield can inspect it: its policies are regex over method, path, and body, so a policy can match "DROP TABLE" anywhere in a query body, or an UPDATE/DELETE that lacks a WHERE clause. A match holds the query; no match forwards it instantly.

A held query is parked, not run — the database never receives it until a person approves. The reviewer sees the actual SQL, so the decision is concrete: this DELETE has a WHERE targeting one record, approve; this one would hit the whole table, deny. And because it's a proxy, there's no SDK and no change to the agent or its ORM — you point the agent's database traffic at agent·shield and the inspection happens in the middle.

The whole design depends on safe queries not being slowed down. Reads and scoped writes are forwarded instantly, so the agent queries at full speed for almost everything it does; only the destructive patterns pause. If you find a routine query keeps getting held, that's a signal to tighten the policy so it stops matching the safe case — the goal is a queue that only contains queries genuinely worth a human's look.

Every query decision is written to the append-only audit log: the full query, the policy it matched, who approved or denied a held one, and when. After an incident or a near-miss, you can see exactly which destructive queries the agent attempted and what was caught — which is also how you justify giving an agent database access in the first place. To be precise: the protection covers the database traffic you route through agent·shield, so point the agent's queries at the proxy and that's the surface it guards. It governs query intent; it's not a replacement for the database's own permissions.