Authorize is not lint.

This distinction gets blurred because both controls happen before execution. A linter inspects the shape of SQL. It might flag DELETE without a WHERE, an unexpected DDL operation, or a statement outside a local policy. That is useful work.

Authorization answers a different question: did the right authority approve this particular statement, for this scope, before it reached the database?

Confirmation is a moment; a receipt is evidence

A confirmation prompt is often the right interface. The 2026 MCP elicitation work makes that interaction more natural: a tool can pause, request input, and resume instead of inventing its own approval chat. But the prompt itself does not have to be the control record.

For a production write, we want the durable artifact to bind the decision to the statement. In our implementation, an Authorization Receipt carries the SQL hash, policy, scope, expiry, and decision, then receives an Ed25519 signature. The executor verifies that receipt before it proceeds.

The statement-sized boundary

The narrowest useful gate sits immediately before execution:

propose exact SQL
→ decide: ALLOW | DENY | REQUIRE_APPROVAL
→ issue a short-lived, signed receipt
→ verify the receipt
→ execute or stop

A changed statement needs a changed receipt. A payment can fund the authorization path, but payment alone is not permission to modify a database. And a verified receipt still is not a warranty that the business decision is wise; it is evidence that the defined permission check happened.

Where this helps

Read-only remains a sensible default. The interesting case is a useful agent workflow that really does need to write: applying a migration, updating a customer record, or running a remediation. That is where authentication and lint stop answering the full audit question.

Can your trail answer not only “who ran this?” but “who approved this exact write?” If this overlaps with your MCP or database write path, we are happy to compare implementation notes.