Your agent writes the SQL. Vericto checks it before it runs.

Start a throwaway Postgres, put the proxy in front of it with the built-in rules, and send a few queries with the image's own psql. All you need is Docker.

docker network create vericto-demo
docker run -d --name vericto-demo-db --network vericto-demo \
  -e POSTGRES_PASSWORD=demo postgres:17
docker run -d --name vericto-demo-proxy --network vericto-demo \
  -e UPSTREAM_HOST=vericto-demo-db vericto/vericto-proxy:4.20.0
until docker exec vericto-demo-db pg_isready -q -h localhost -U postgres; do sleep 1; done

docker run --rm --network vericto-demo postgres:17 \
  psql postgresql://postgres:demo@vericto-demo-proxy:5433/postgres \
  -c "CREATE TABLE users (id int PRIMARY KEY, email text)" \
  -c "INSERT INTO users VALUES (1, 'ana@example.com'), (42, 'bo@example.com')" \
  -c "DELETE FROM users" \
  -c "DELETE FROM users WHERE id = 42" \
  -c "SELECT id, email FROM users"

CREATE TABLE
INSERT 0 2
ERROR:  Vericto blocked this query [VERICTO-001] — AST node: DeleteStmt > WhereClause = NULL. Suggestion: DELETE FROM users WHERE id = $1
DELETE 1
 id |      email
----+-----------------
  1 | ana@example.com
(1 row)

The DELETE with a WHERE does run. docker logs vericto-demo-proxy shows the decision. Clean up with docker rm -f vericto-demo-db vericto-demo-proxy && docker network rm vericto-demo. Next: the proxy in front of your database.

The CLI ships with the engine inside. With --offline it checks SQL on your machine against the 42 standard rules: it makes no request, and the SQL never leaves your computer. It works the same in a pre-commit hook or a CI step.

echo "UPDATE users SET role = 'admin';" > roles.sql
npx @vericto/vericto-cli@latest check --offline roles.sql

note: offline mode: 42 standard rules at default severities, engine 4.3.0. Custom rules, overrides, sensitive columns, allowlists and the audit trail apply online only.
✖ roles.sql  BLOCKED  VERICTO-030 critical
    UpdateStmt > WhereClause = NULL
    fix: UPDATE users SET {col} = $1 WHERE id = $2
1 blocked · 0 allowed · 0 flagged · 0 monitored   (ruleset standard@engine-4.3.0 · mode: offline (engine 4.3.0, 42 standard rules, no workspace policy))

Also with brew install vericto/tap/vericto, winget, Scoop or Docker. Next: the CLI in your pipeline.

Connect your agent to the remote MCP server and call check_sql before it runs anything. It gets the verdict, the fix and what to do next. It is advisory: to make the block mandatory, route the agent's connection through the proxy.

claude mcp add --scope user --transport http vericto https://mcp.vericto.com/mcp \
  --header 'Authorization: Bearer ${VERICTO_API_KEY}'

{
  "passed": false,
  "findings": [{
    "line": 1,
    "status": "BLOCKED",
    "rule_code": "VERICTO-010",
    "severity": "critical",
    "ast_node_path": "DropStmt",
    "suggested_fix": "Use a versioned migration tool (Flyway, Prisma Migrate, Alembic, Rails migrations)",
    "next_action": "apply_fix_and_recheck"
  }],
  "next_steps": [{
    "action": "apply_fix_and_recheck",
    "message": "do not run it as written; apply the suggested fix, then call check_sql again with the corrected SQL."
  }]
}

Published in the MCP Registry as com.vericto/sql-firewall. Cursor, Codex, VS Code and other clients: setup per client.

The vericto/check-sql action checks the .sql files each pull request changes against your workspace's rules. Findings show up as annotations on the PR, and a blocked statement fails the job. It authenticates with an API key or with GitHub OIDC, with no stored secret.

name: Vericto SQL check
on:
  pull_request:
    paths: ["**/*.sql"]
permissions:
  contents: read
  security-events: write
  actions: read
jobs:
  vericto:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: vericto/check-sql@v1
        with:
          api-key: ${{ secrets.VERICTO_API_KEY }}

No account yet? A step with npx @vericto/vericto-cli@latest check --offline works on any runner. Next: safe SQL in CI/CD.