Connect via MCP
SQL Safety & Cost Oracle

The verdict before the query.

A deterministic safety & cost gate that vets every SQL statement your AI agent writes — before it runs.

deterministicno LLM in the loopnever connects to your DB
Connect via MCP →How it works
analyze_sql
# your agent wrote:
DELETE FROM users;
● block
{
  "verdict": "block",
  "findings": [{
    "id": "destructive.delete_without_where",
    "severity": "block",
    "recommendation": "Add a WHERE clause, or confirm a full-table delete is intended."
  }]
}
In the loop with Claude Claude Code Cursor Cursor PostgreSQL Postgres Model Context Protocol MCP GitHub Actions GitHub CI
How it works

Three steps. No LLM. No DB connection.

Veto sits between your agent and your database as a deterministic gate.

01

Agent writes SQL

Your agent calls analyze_sql over /mcp before executing anything.

02

Veto vets it

Deterministic rules + a cost estimate on a throwaway scratch Postgres. Your production DB is never touched.

03

Verdict returns

A structured ok / warn / block verdict with finding ids — before the query runs.

Three verdicts

One contract. Three states.

Traffic-light semantics your agent — and your CI — can branch on.

ok

SELECT … LIMIT 100

Safe to run. Ships without friction.

warn

ALTER TABLE orders …

Heavy-lock risk or a large sequential scan. You decide.

block

DELETE FROM users

Destructive without a guard. Stopped before it runs.

Demo

It blocked the migration. You never wrote the postmortem.

Same input, same verdict — every time. Deterministic findings with stable ids you can gate CI on.

Connect via MCP →
analyze_sql · response
# DROP TABLE invoices;
● block
{
  "verdict": "block",
  "findings": [{
    "id": "destructive.drop",
    "severity": "block",
    "recommendation": "Confirm the object is unused; consider renaming first as a safer rollback path."
  }]
}
Why Veto

The boring, reliable layer you bet on.

No magic. The core is deliberately not AI — that's the point.

Deterministic

Same statement, same verdict — every time. No model drift, fully reproducible.

No LLM in the loop

Rules + query planning, not a prompt. No tokens, no latency, no hallucinated approvals.

Never touches your DB

Cost estimates run on a scratch Postgres via BEGIN … ROLLBACK. Production is never connected.

Gated on golden evals

Stable finding ids and golden cases in CI — a contract you can trust over time.

FAQ

Questions, answered.

Does Veto connect to my database? +

No. Veto never connects to your production database. Cost and plan estimates run on a throwaway scratch Postgres inside a transaction that's always rolled back.

Is there an LLM making the decision? +

No. The verdict is produced by deterministic rules and query-plan analysis — not a model. Same input always yields the same verdict.

How does my agent call it? +

Connect via MCP at /mcp and expose the analyze_sql tool. Your agent asks for a verdict before it runs any statement.

What does it cover? +

Destructive statements (unscoped DELETE/UPDATE, DDL drops), and cost risks (large sequential scans, missing indexes). Scope is intentionally narrow and reliable rather than broad and fuzzy.

Your agent won't drop prod.

Add Veto to your MCP client — point it at the endpoint and expose analyze_sql.

{
  "mcpServers": {
    "veto": { "url": "https://vetosql.com/mcp" }
  }
}

shipped with a seatbelt