Vericto Proxy mode (local, PostgreSQL)

Vericto Proxy

Stops destructive SQL before it reaches your database, whether it comes from AI

agents, scripts or people, with no code changes.

AI agents, scripts and people all run SQL against production with real credentials. Nobody reads each statement before it runs, and a database role decides what a user may touch, not whether this particular statement should run. One DELETE without a WHERE empties a table. A SELECT of the wrong columns copies emails or card numbers to wherever the result goes.

vericto-proxy sits between your clients and the database, on the database's own wire protocol. It parses every query with the vericto-engine AST parser, checks it against your rules, and either forwards it to the real database or blocks it with a normal SQL error. Your application only changes the host and port in its connection string.

License. Open source under the AGPL-3.0-only, or under a

commercial license from Vericto S.A.S. You can self-host it and use it for free,

including in production at a for-profit company. Distributing it, or offering a

modified version over a network, requires providing the source under the AGPL;

anyone who cannot do that can ask for the commercial license. Versions up to

4.23.0 keep the license they were released with.

LICENSING.md answers the common questions.

One proxy instance fronts one database and speaks exactly one wire protocol, chosen at deploy time with VERICTO_WIRE_PROTOCOL:

Everything else — configuration, evaluation, telemetry — is the same across engines. Only the value above and (optionally) the default ports change.

No AI, no stochastic heuristics — the same input always produces the same result.

Other dialects (Oracle, SQL Server, Snowflake, SQLite): evaluate via the

HTTP API, the CLI or MCP;

there is no wire proxy for them. Snowflake has no TCP wire protocol at all, so

VERICTO_WIRE_PROTOCOL=snowflake stops the proxy at startup with an error.

SQLite is a library linked into the application, with no wire protocol either:

its SQL is checked in the application, before it runs.

---

Try it with Docker

All you need is Docker: no account, no API key, no build. This starts a throwaway Postgres, puts the proxy in front of it with the built-in ruleset, and sends a few queries through it with the psql that ships in the Postgres image. The password demo is only for this disposable database.

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:5.0.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"

The image comes from Docker Hub; ghcr.io/vericto/vericto-proxy:5.0.0 serves the same digest (see Docker).

The DELETE without a WHERE never reaches the database; the one with a WHERE does:

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)

docker logs vericto-demo-proxy shows the decision. To put the proxy in front of your own database, see Docker and Connection strings. Clean up with:

docker rm -f vericto-demo-db vericto-demo-proxy && docker network rm vericto-demo

For assertion-based coverage of the article's extended protocol, pipelines, prepared-policy refresh, TLS/SCRAM, cancellation, COPY and PostgreSQL 18 cases, run examples/postgres-wire-article/run.sh.

---

Architecture position

Your app / ORM

│ │ SQL wire protocol (proxy listen port, default 5433) ▼ vericto-proxy ──── vericto-engine (lib) ────► ALLOWED / BLOCKED │ │ (if ALLOWED) forwards query ▼ Real database upstream

Point your DATABASE_URL host at vericto-proxy instead of your real database. No code changes required — your ORM/driver is unaware of the proxy.

---

What it blocks

With the built-in ruleset, these never reach the database:

• DELETE / UPDATE without WHERE
• DROP TABLE, DROP SCHEMA, TRUNCATE
• OR-tautology SQL injection (WHERE id = $1 OR 1=1)
• ALTER TABLE DROP COLUMN / RENAME
• … full rule list →

Lower-severity findings — SELECT * without WHERE, SELECT without LIMIT, INSERT without an explicit column list — are forwarded and recorded rather than blocked. With the control-plane link on, the workspace policy decides the action for each severity.

Bounded reads (4.17.0). To cap what an agent reads instead of only flagging it, a business policy with action: { rewrite_limit: n } (the LIMIT cap template in rewrite mode) makes the proxy forward the statement with LIMIT n added, or a larger LIMIT lowered, on Postgres and MySQL, simple and prepared statements. It needs VERICTO_POLICY_RULES=enforce; see docs/CONFIGURATION.md.

A blocked query is returned as a native error for the active protocol (see the table above), so no special handling is needed in your application.

PostgreSQL pipelines and prepared statements (4.17.3). Local block and session-context replies are ordered at the exact position of their upstream response cycle, after every earlier pipelined result. Backend messages are framed, so even a large row or COPY message is never split by a synthetic reply. Named and unnamed prepared SQL is checked again at Bind and Execute after a rules, policy, principal or session-context refresh; business policies that may read the time (time.*) are checked on every Execute, the others keep the verdict reached under the same rules, policy, bundle and session context (see docs/CONFIGURATION.md). If a mask or rewrite_limit would now require different SQL, the proxy returns VERICTO-PREPARED-STALE and the client must close and prepare the statement again. Portals retain the plan they bound even after their source statement is closed or replaced. PostgreSQL COPY BOTH/replication is rejected by closing the session rather than risk response mis-ordering. A FunctionCall denied by an agent-access policy also closes, because a Query-based ordering marker would change unnamed-statement state. MySQL behavior is unchanged in this patch: a MySQL prepared statement is still checked when prepared, not refreshed when it is later executed.

---

Sensitive columns

Columns can be tagged as sensitive per database in the Vericto dashboard (Team and Enterprise plans). The tags reach the proxy with the ruleset (/sync/rules, so the control-plane link and VERICTO_DATABASE_ID are required) and are enforced on the wire, before the database sees the query. When a query reads several tagged columns the strictest policy wins (block > mask > flag). The proxy enforces: unlike the Validation API or the CLI, which only advise, what the proxy decides is what the database receives.

If a rewrite does not hold together, the proxy blocks with VERICTO-085 rather than forward the original. SELECT * over a table with a masked or blocked column is blocked; list the columns. The full behaviour (both protocols, prepared statements, fail-safe cases, parse errors, telemetry, known limits) is in docs/SENSITIVE_COLUMNS.md.

---

Agent access

An allowlist per database user (Team and Enterprise plans), set in the Vericto dashboard: which tables and columns that user may read, and which it may write. Everything else is denied (VERICTO-087). The policies reach the proxy with the ruleset (/sync/rules, so the control-plane link and VERICTO_DATABASE_ID are required), keyed by database user, with an optional "*" default for every user not listed.

The identity of a session is the database user it authenticated as, so give each agent its own database user and a policy for that user. Under a policy, every reference counts (WHERE, JOIN, subqueries, RETURNING, not only what the query returns), DDL is always denied, and the identity cannot be changed from inside the session (SET ROLE, USE, COM_CHANGE_USER and the like are denied). A policy in observe mode records what it would deny and forwards the query.

The full behaviour (name resolution, writes and locks, policy changes on open sessions, telemetry, known limits) is in docs/AGENT_ACCESS.md.

Kill switch (4.18.0). When an owner or admin blocks an agent (or every agent of the workspace) from the dashboard's Incident response panel, the proxy refuses every statement of that database user from its next rule sync with VERICTO-105 and the kill-switch message the Runtime API returns, before anything is evaluated and in every mode: SELECT 1, SET and BEGIN included, and statements prepared before the block. Lifting the block restores the session at the following sync. See docs/AGENT_ACCESS.md.

---

MCP: an agent runs SQL through Vericto (Proxy mode)

vericto-proxy mcp (4.21.0) is an MCP server for AI agents: Claude Code, Cursor, Codex or any MCP client gets an execute_sql tool and no database credential. Each statement is evaluated first, and the server runs exactly what it evaluated (or the policy's rewrite of it) on PostgreSQL, read-only, in a transaction that always rolls back, with row, size and time caps. describe_schema, a local check_sql and whoami come with it. Over stdio for a developer's machine, or Streamable HTTP for a team.

Try it without an account. With no control plane configured it runs locally on the built-in ruleset (the rules the TCP proxy runs standalone) and reports nothing:

claude mcp add vericto-db -- \

docker run -i --rm --user "$(id -u):$(id -g)" \ -v ~/.config/vericto/shop.u