Case file · Safety and privacy
Safety is the core of the design, and it is never paywalled. Everything on this page works the same in Free. Where a safeguard has a limit, the limit is stated next to it.
Every statement that reaches SQL Server goes through one execution path and gets a row in the local command log: typed queries, grid saves, designer scripts and the app’s own catalog queries. The log row is saved before the result is shown. Statements the app blocks are logged too.
What is not kept: parameter values are never stored in the log.
Every statement SQL Sleuth sends on its own starts with a /* sqleuth:… */ comment, so it is easy to spot in server-side traces.
Grid saves, designers and object operations show the exact script first. You can copy it instead of running it. The script that runs is the script you reviewed.
Passwords and other secrets are kept in macOS Keychain or Windows Credential Manager. They never go into the app’s files or the log, the UI can never read them back, and connection exports never include them.
A saved secret is bound to its server: if you change the host, port or auth method, the secret is deleted.
A read-only connection refuses anything the app cannot prove is a pure read, and the check fails closed.
The limit: this is a local safeguard inside the app. For production, a reader login on the server is still recommended.
A per-connection policy, turned on by default for Prod connections. With it on, drops, truncates and grid saves that delete rows or change 100 or more rows ask for confirmation.
Prod connections get a red rail, a PROD badge and a banner that screen readers announce. Editing tabs on prod start locked behind “Enable editing”. Enter never executes on prod, and the biggest drops require typing the object’s name.
Local rules hide sensitive columns in grids, copies, exports and query results, for screen sharing and demos. There is no reveal button and no unmasked export.
The limit: masking is a local safety feature, not access control.
Launching the app never logs in to any server. There is no telemetry or usage analytics.
Auto-update and crash reporting are still in development. This is how they will work when they arrive; they follow the same rules as everything above.
Coming soon
The update check will be a plain request for a static file. It will carry no version, machine ID or other identifier, and an update will never install without a click.
Coming soon
Crash reports will be opt-in per report; the default will be “Ask each time”. You will see the exact redacted report before it is sent (no SQL, server names, data, user name or IP), and you will be able to save it to a file instead.
The crash-report processor is named in the privacy policy{{PRIVACY_URL}}.
| What | Where it goes | When |
|---|---|---|
| Your SQL Server connections | The servers you connect to | When you open a connection. Never at launch. |
| Microsoft Entra sign-in | Microsoft | When you sign in with an Entra method. |
| Update check Coming soon | A static file. No identifiers. | When checking for updates. |
| Crash reports Coming soon | The processor named in the privacy policy | Only if you choose to send one. |
License activation Coming soon is offline and contacts nobody.
Read the privacy policy for the legal detail.