Identity gates

Use your operating system's identity check where a mistake would be expensive, and leave routine work alone.

Use the identity check your operating system already knows how to do - Touch ID on macOS and Windows Hello on Windows - only where an extra pause is worthwhile, and nowhere else.

Why a separate layer

The other guardrails answer “is this statement safe?”. An identity gate answers a different question: is the person at the keyboard still you? A laptop left unlocked for two minutes in a shared office passes every SQL check in the app. That is the gap this closes, and it is why the gate is a hardware prompt rather than another dialog with a button on it.

Two gates, set independently

Verify to connect

The check happens before the connection opens - nothing is reachable until you pass it.

Verify to write

Reads stay frictionless; anything that is not a plain SELECT asks first.

Both are stored per client, project, or environment and edited in the same place as the rest of connection safety, so “every production database for this customer” is one switch rather than fifty.

Honest status

The policy layer is real today: the two flags exist on every client, project, and environment, they are edited in the connection-management dialog, and they travel with an exported connection set. The SQL side is real too - SQLly already classifies which statements are writes and already gates them for confirmation. What is still being built is the last step: raising the native Touch ID / Windows Hello prompt and holding its result.

Nothing about the gate is a secret store. An identity check controls whether an action proceeds; it never becomes the key to your credentials. Those stay in the OS keychain, where the operating system can protect them properly.

In this section

Verify to connect — Require an OS-native identity check before SQLly opens a connection that deserves extra care.
Identity check for writes — Keep reads frictionless; ask for verification before an action with real teeth.
Set once, inherit everywhere — Set identity rules at the level that makes sense and let them follow the connection hierarchy.
Configurable re-auth window — Decide whether verification happens for every statement, every session, or somewhere comfortably in between.
Tamper-evident verification log — Keep a local, tamper-evident record of who verified a gated action, where, and when.
Watchdog & passcode fallback — Use the device passcode or OS sign-in when biometric hardware is unavailable or simply not your thing.