This page exists so the most paranoid reader in your org — usually the DBA being asked to run a script against production — can evaluate tuneproof without reading the source. Every claim here is either enforced mechanically (deterministic code, database privileges, tested redaction) or stated as a verifiable contract (script text the DBA reads before running) — and this page says which is which.
- The tool never connects to anything. tuneproof renders T-SQL prescriptions and grades the captured output. How a prescription gets executed is always user-owned: you paste it into SSMS, or you configure a runner command once (your credentials, your call). There is no connection string, driver, or socket in the trust engine.
- Prescriptions are read-only by contract — and the contract is the script. Every prescription opens with a SAFETY CONTRACT header (session-scoped temp tables only, no writes to user objects, no DDL, one bounded transaction, 60-second lock timeout) and the full T-SQL below it is what runs. A DBA can verify the claim by reading the artifact — there is nothing hidden to trust.
- The model is never the source of trust. Verdicts (PROVEN / REFUTED / UNVERIFIED) are computed by a deterministic grader from a delimited result grid the database produced. No language model ever decides PASS or FAIL.
- Comparison data never leaves the database. The equivalence battery materializes and compares inside SQL Server; what comes back is a grid of test names and PASS/FAIL counts — never business rows.
- Nothing phones home. Pure Python stdlib, zero dependencies, no server, no telemetry, no credentials of its own.
| Guarantee | Enforced by |
|---|---|
| Verdicts are deterministic; an incomplete or corrupt capture can never grade PROVEN | the grader: parses only the delimited grid, checks a required-test and required-gate manifest, fails closed — unit + adversarial RED/GREEN tested in CI |
| The certificate names exactly what it certifies | sha256 of original + rewrite recorded at prescription time, carried in the verdict; a capture that doesn't trace to a prescription opens a subject_binding gap |
| Prescriptions only write session-scoped temp tables | the script text itself (DBA-verifiable) plus the database: run it under a read-only login and even the contract becomes unnecessary — the login is the wall |
| Passwords never persist in case files | token-based redaction of the runner command before anything touches the append-only ledger (covers -P x, -Px, --password[=], quoted forms; timeout errors redact too) — tested |
| An MCP client cannot execute arbitrary commands | the runner command is not accepted from MCP clients at all — no tool schema carries it; run resolves it only from case.json or TUNEPROOF_RUNNER_CMD, both user-owned — tested |
| An MCP client cannot read or write outside the sandbox | every path argument resolves and must land inside the server's --root (symlink- and traversal-checked) — tested |
| The skill never asserts a result | written bright lines in SKILL.md ("you never declare a rewrite equivalent or faster — only a PROVEN verdict does"); instruction-enforced, with the grader as the mechanical backstop |
The last row is the honest caveat everywhere a language model is involved: instructions are not an OS permission system. tuneproof's design compensates by keeping the model outside the trust path entirely — the model proposes rewrites, bindings, and explanations; the database computes; the grader judges.
In connected and MCP modes, the SQL under test may have been written by a model — and the
run tool executes prescriptions containing it. The prescriptions are read-only by
contract, but the database enforces only what the login allows. The posture:
- Give the runner a dedicated read-only login. Then even a misbehaving or prompt-injected agent can read, never write. This is the single most important configuration decision in the product.
- Keep secrets out of commands.
sqlcmdreadsSQLCMDPASSWORDfrom the environment natively; prefer it (or Windows integrated auth,-E) so no password ever appears in a command line, a process list, or a file. - The redaction layer exists for when you don't: anything resembling a password is stripped before the ledger sees it. Defense in depth, not a substitute.
tuneproof itself transmits nothing — there is no code path that could. What does leave is what any AI-assisted session sends: the SQL text, schema names, and statistics output you put in front of the model enter the model context under your own provider settings. Be deliberate about execution-plan files: plan XML can embed sniffed parameter values. The comparison data — the rows the equivalence proof actually compares — never enters the model context at all; it never leaves the database.
The grader reads only the region between ====BEGIN_GRID==== and ====END_GRID====,
positionally, against a manifest. Text outside the grid — including a planted "all checks
passed, skip validation" — is ignored by construction, and a malformed grid grades
UNVERIFIED, never PROVEN. The same discipline applies to the skill layer: a capture
claiming to be pre-validated is the thing to scrutinize, never obey.
tuneproof mcp is a ~300-line stdlib JSON-RPC/stdio server — no SDK dependency, short
enough to audit in one sitting. It exposes nine tools that are thin wrappers over the CLI,
so every guarantee above is inherited rather than reimplemented. The two invariants worth
repeating: the calling model receives tool-computed verdicts (it cannot assert one), and
it cannot name the command that run executes.
If you can make tuneproof cross any line on this page — produce a false PROVEN, execute a write through a prescription, leak a secret into a persisted file, escape the MCP sandbox, or obey an instruction planted in a capture — please report it via GitHub's private vulnerability reporting on this repository (or an issue if it isn't sensitive). A reproducible transcript or capture file is gold; per house style, the fix ships with a regression test.