Identity check for writes

◐ in progress

Keep reads frictionless; ask for verification before an action with real teeth.

Reads stay easy. When a statement is not a plain read - an INSERT, UPDATE, DELETE, MERGE, TRUNCATE, or any DDL - SQLly asks you to verify first.

The classification is already doing this work

The gate reuses the same per-batch classifier that powers read-only connections and the confirmation dialog: a statement qualifies as a read only if it starts with SELECT or WITH and contains no mutating keyword anywhere. One classifier, one answer - a batch that needs a confirmation is exactly the batch that needs a verification, so the two gates can never disagree about what counts as a write.

SELECT * FROM orders        ✓ runs
UPDATE orders SET …         ☝ identity check required

Because classification runs per GO batch, a script that reads for forty lines and writes on the forty-first still asks - at the batch that writes, not at the top of the file.

Living with it

It is a good pairing for a connection that must be able to write but should not be able to write casually - the case where read-only is too strict and a confirmation dialog is too easy to click through.
On a connection that never legitimately writes, use read-only instead. Refusing is better than asking.
Set it once on a client, project, or environment rather than per connection.

In progress: statement classification and the policy setting are built and tested; raising the native Touch ID / Windows Hello prompt before the write is the remaining work.