How We Guarantee Read-Only: The Validation Layer Behind Every Query
An AI that writes SQL against your production database is only safe if it physically cannot write to it. Here's the layer that enforces that, before any query executes.
The single scariest sentence in AI-over-databases is "the model generates SQL and we run it." An LLM that can write SELECT can, in principle, write DELETE. The question every serious buyer asks, and should ask, is: what stops it?
For Cazper, the answer is a validation layer that sits between generation and execution and treats every query as guilty until proven read-only.
Generation and execution are not the same step
A naive pipeline does one thing: prompt the model, take its output, execute it. That's a straight wire from a probabilistic system to your production data. No amount of "we told the model to only write SELECTs" makes that safe, because instructions are not guarantees.
Cazper splits the pipeline. The SQL-generation agent produces a candidate query. That candidate does not touch your database until it passes validation. Generation is where the AI has freedom. Validation is where it doesn't.
What validation actually checks
The validation layer parses the generated SQL and enforces read-only by construction:
- Statement type must be
SELECT. The query is parsed structurally rather than string-matched, so the intent is read, not guessed. - A keyword blocklist rejects mutation and DDL.
INSERT,UPDATE,DELETE,DROP,ALTER,TRUNCATE, stored-procedure calls: anything that could change state or schema is refused outright. - Anything ambiguous fails closed. If a query can't be cleanly parsed and confirmed as a single read, it doesn't run. The default is no, not maybe.
Only a query that passes all of this reaches execution.
Execution has its own guardrails
Read-only isn't the only way a query can hurt you. A perfectly valid SELECT can still scan a billion rows and pin your database. So execution is bounded too:
- Statement timeouts stop a runaway query from monopolizing the connection.
- Row caps keep result sets from ballooning into memory. The answer you need doesn't require dragging back the whole table.
These bounds mean a worst-case query is slow and stopped, not catastrophic.
Why "just prompt it nicely" isn't enough
You'll see tools that rely on the model's good behavior, with a system prompt saying "only generate read queries." That works until it doesn't: a cleverly phrased question, an edge case in the model, a prompt-injection attempt buried in data. Behavioral safety degrades under adversarial pressure. Structural safety doesn't.
The validation layer doesn't trust the model to be well-behaved. It assumes the model might, someday, produce something it shouldn't, and it makes sure that something can't execute. That assumption is the whole point. Safety you can reason about comes from the query that can't run, not the prompt that asked it not to.
The guarantee, stated plainly
Connect Cazper to a production database and the exposure is bounded by design. It can read what the connection permits, and it cannot write, alter, or drop anything, because non-read queries are rejected before execution, every time. That's not a policy. It's a gate.