Introduction.

Quick Start

Vericto protects your databases by evaluating every SQL query against security rules before it reaches your data. Three integration modes: they combine, choose based on your environment:

Option A: TCP Proxy (runtime, PostgreSQL and MySQL)

Deploy a lightweight container in your infrastructure. Your application connects to the proxy instead of connecting directly to the database: same credentials, different host. It blocks unsafe queries in real time. Available for PostgreSQL and MySQL, whose wire protocols the proxy speaks. For Oracle and SQL Server, use the CLI or the HTTP API (all dialects).

Option B: CLI (shift-left: pre-commit and CI/CD, all dialects)

The vericto CLI validates SQL against your workspace rules before it runs, in pre-commit hooks and CI pipelines. It is a lightweight client that sends the SQL to your workspace and reflects the verdict as the process exit code (the SQL is parsed, never executed). It works with all four dialects and is available on every plan.

Option C: HTTP API (custom integrations, all dialects)

Evaluate queries via REST from your own tools: no proxy, no CLI. It works for all dialects: PostgreSQL, MySQL, Oracle and SQL Server. It is the same endpoint the CLI uses; reach for it only when the CLI does not fit your workflow.

Ready to connect? The Integration Guide has the step-by-step for all three modes: proxy deployment (Docker, Kubernetes, ECS), installing and using the CLI, and HTTP API examples.

Architecture

Vericto uses deterministic AST (abstract syntax tree) analysis to evaluate SQL queries. No AI, no probabilistic models, no false positives: the same input always produces the same result.

How it works

Your App → Vericto Proxy (your infrastructure, port 5433)
               │
               ├─ Parse SQL into full AST (pg_query for Postgres, sqlparser-rs for MySQL/Oracle/SQL Server)
               ├─ Evaluate AST against active security rules
               ├─ Resolve enforcement action (BLOCK / FLAG / MONITOR)
               │
               ├── SAFE? → Forward to your real database → relay response
               └── DESTRUCTIVE? → Return SQLSTATE 42501 (query never reaches DB)

Components

TCP Proxy (PostgreSQL and MySQL wire protocol)

The TCP proxy is a transparent interception layer. Any driver that uses the PostgreSQL or MySQL wire protocol works with no code changes. Your database credentials never leave your infrastructure.

Zero credentials stored

Vericto never stores your database credentials nor transmits them to Vericto Cloud. The proxy runs in your infrastructure and relays the PostgreSQL authentication exchange —the Authentication / PasswordMessage flow that follows the StartupMessage— directly to your database. Your application connects to the proxy with the same username/password it would use to connect directly, and credentials are verified by your database, not by Vericto. With SCRAM-SHA-256 (PostgreSQL's modern default) the password is never transmitted in plaintext; the proxy only relays the challenge-response.

Wire-protocol compatibility

Vericto operates as a fully transparent layer inside the PostgreSQL wire protocol. The proxy automatically detects and evaluates SQL from both protocol modes, with no configuration or driver changes required:

The proxy handles both modes transparently within the same connection. All other protocol traffic (authentication handshake, query results, server notifications, COPY operations) passes through unmodified. No configuration is needed to select between modes: Vericto inspects the type byte of each message and only intercepts the frames that carry SQL.

What Vericto evaluates (not just the obvious cases)

Because Vericto walks the full PostgreSQL AST (via libpg_query, the same parser the database uses), it detects destructive statements that shallow or regex-based inspection misses:

• Multi-statement queries: every statement in a batch is parsed and evaluated, and the highest-severity violation wins. A destructive tail cannot hide behind a benign head: SELECT 1; DROP TABLE users; is blocked on the DROP.
• Data-modifying CTEs and subqueries: destructive operations nested inside WITH clauses or subqueries are detected, e.g. WITH x AS (DELETE FROM users RETURNING id) SELECT * FROM x.
• Parameterized statements: prepared statements are evaluated at Parse time on the query structure, so protection is deterministic regardless of the bound values.
• Injection tautologies: always-true predicates such as OR 1=1 in a WHERE clause are flagged as SQL injection patterns.
• Multi-dialect: PostgreSQL, MySQL, Oracle and SQL Server are parsed with dialect-aware rules (e.g. in MySQL DELETE … LIMIT is valid; Postgres has no such form). PostgreSQL and MySQL can go through the transparent proxy; Oracle and SQL Server are evaluated via the HTTP API.

Decisions & Actions

Vericto separates severity (how dangerous it is: Critical / High / Medium / Low / Informational) from the enforcement action (what to do: BLOCK / FLAG / MONITOR). The action is resolved by the workspace enforcement policy.

Default enforcement policy

Query telemetry and privacy

For every query it evaluates, the proxy emits a telemetry event to the Vericto API (status, severity, rule code, latency and the query text). This feeds the dashboard, metrics and audit log. Your database credentials are never part of the telemetry, but the query text may contain sensitive values in its literals (e.g. WHERE email = 'alice@acme.com').

The query telemetry mode is configurable per workspace (Dashboard → Settings → Telemetry privacy):

How structural AST sanitization works, examples, and the recommendation by data type (GDPR, HIPAA, Ley 1581 de 2012) are in Telemetry privacy.

Authentication and HTTP integration

CI/CD programmatic access to Vericto (query evaluation, rule sync, telemetry) uses API keys. Create an API key from the dashboard (API Keys page) and include it in every request in the X-API-Key header. The dashboard REST API (custom rules, audit trail) uses the session token with Authorization: Bearer.

X-API-Key: vtro_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

API keys are scoped to a workspace and inherit the workspace plan limits. You can create multiple keys with different names for different environments (CI, staging, production).

Query evaluation endpoint

The request and response shape, cURL/Node.js/Python examples, and the response codes are in the Integration Guide.

Security rules

Vericto ships a catalogue of standard rules (VERICTO-*) that detect destructive and injection patterns, grouped by severity:

• CRITICAL Large-scale irreversible operations: DELETE/UPDATE without WHERE, DROP, TRUNCATE, and injection tautologies (OR 1=1). Blocked by default.
• HIGH Schema changes and dangerous patterns: ALTER TABLE DROP COLUMN, DROP INDEX, unfiltered INSERT … SELECT, SLEEP().
• MEDIUM Performance risks or best practices: SELECT without LIMIT, SELECT * without WHERE, INSERT without explicit columns.

See the full catalogue, with every rule, its severity, the dialects it covers, and its AST condition, in the AST Rules Reference. You can tune each rule's action or create your own in Custom rules.

Error codes

Plans and limits

Vericto has four plans. All include the standard rules and the three connection modes (TCP, HTTP API, and CLI); they differ in quotas, retention, and enterprise features:

• Free: 500K queries/month, 1 database, 1K CLI validations/month, 7-day audit retention.
• Builder: 5M queries/month, 3 databases, custom rules (YAML), Slack/webhook alerts, 30-day retention.
• Team: unlimited queries, 10 databases, audit export (CSV/JSON), 90-day retention, SOC2/ISO 27001 compliance.
• Enterprise: custom databases and retention, SSO (SAML/OIDC), dedicated deployment, and a guaranteed SLA.

See the full feature comparison and pricing on the pricing page.