Security

Vericto is built on the principle that security cannot depend on correct runtime decisions. AST parsing is deterministic. Encryption is mandatory. The audit trail is immutable. There is no insecure mode.

Zero-trust architecture

Vericto operates under the zero-trust principle: no query is trusted by default, regardless of its origin. Every query intercepted by the proxy is analyzed from scratch, with no prior state, no decision cache, and no implicit exceptions.

No implicit bypass

There is no silent bypass mode: every query that parses is evaluated against your rules. By default, a query that cannot be parsed is forwarded and recorded as PARSE_ERROR (fail-open), so Vericto never takes your database down. The workspace can switch to fail-closed under Settings → Unparseable queries (owner or admin), and with sensitive columns tagged block or mask an unparseable query is always blocked. VERICTO-086 always blocks MySQL text that MySQL and the engine would read differently, and it cannot be disabled (in observe mode it is only recorded, like any block).

Least privilege by default

The CRITICAL rules (among them DELETE and UPDATE without WHERE, DROP, TRUNCATE and COPY … PROGRAM) are active and block by default in every workspace. Disabling them or lowering their severity requires explicit action by the workspace owner. VERICTO-085 (sensitive columns) and VERICTO-086 cannot be disabled: the first is driven by each database's column tags and the second is always enforced.

Immutable audit trail

Every block or allow decision is recorded with a timestamp, full query (encrypted), AST node, triggered rule, and latency. Users cannot modify or delete records, not even by deleting a database: its events are kept until your plan's retention expires.

Administrative change log

Every access and configuration change (API keys, members and roles, SSO and OIDC, enforcement policy, sensitive columns, billing) is recorded with the actor, the IP, the outcome and the before and after of what changed, without secrets. The database rejects editing or deleting entries. How it works.

AWS us-east-1, multi-AZ

The Vericto platform runs in AWS us-east-1 (US), spread across several availability zones: if one zone goes down, the replicas in the others keep serving. The proxy runs in your infrastructure. The Enterprise Enhanced and Premium plans offer a dedicated deployment in the AWS region you choose, with data residency in that region.

How AST parsing works

Vericto's core is a deterministic AST (Abstract Syntax Tree) parser implemented in Rust. It uses two reference SQL parsing libraries:

  • pg_query: a binding for libpg_query, the official PostgreSQL parser. The same code the PostgreSQL engine uses internally to parse queries. Guarantees 100% compatibility with the Postgres dialect.
  • sqlparser-rs: a multi-dialect SQL parser in Rust. Vericto uses it for MySQL, Oracle and SQL Server (T-SQL). Actively maintained by the Apache Arrow community.

The query evaluation process occurs in three phases, all within the same Rust process with no network calls:

AST evaluation process: <2ms p99

1

Syntax tree parsing

The plain-text SQL query is parsed by pg_query or sqlparser-rs depending on the configured dialect. The result is a complete in-memory AST: a tree of typed nodes representing the semantic structure of the query.

2

Ruleset evaluation

The rule engine traverses the AST depth-first looking for nodes that violate the active workspace rules.

3

Decision and response

If no rule is violated, the query is forwarded to the real database. If at least one rule is violated, an error response is generated with the offending AST node, rule code, severity, and suggested safe query. The decision is recorded in the audit trail asynchronously.

TCP proxy data flow

The Vericto proxy operates at the TCP protocol level, below any ORM or driver. It intercepts the PostgreSQL and MySQL wire protocols directly.

Vericto never stores the results of your queries: only the query text, decision metadata, and the offending AST node (if applicable). Database response data passes directly to the client without being stored.

The complete data flow for an intercepted query:

  1. Your application's driver/ORM opens a TCP connection to the Vericto proxy (localhost:5433).
  2. The proxy, which runs in your infrastructure, opens the connection to your real database using the connection string you configure locally. Vericto does not receive or store that connection string.
  3. Every query sent by your application is intercepted at the wire protocol level. The query text is extracted and sent to the AST parser.
  4. The AST parser evaluates the query in <2ms. If safe, the query is forwarded to the real database without modification. If destructive, an error response is generated.
  5. The event (query, decision, metadata) is recorded in the audit trail asynchronously, outside the critical path.

Encryption and storage

All sensitive data in Vericto is encrypted at rest and in transit:

  • Connection strings: Vericto does not receive or store them: they are configured in the proxy, inside your infrastructure.
  • Query text in the audit trail: encrypted with AES-256-GCM. The query’s SHA-256 hash is used for indexing and deduplication without exposing the content.
  • Webhook signing secrets: encrypted with per-workspace scoped keys.
  • API keys: stored as a SHA-256 hash of a 256-bit random key; the plaintext is shown once at creation. Passwords are stored with bcrypt.
  • In transit: HTTPS required, with TLS 1.2 or higher on every HTTP connection (TLS 1.3 with any modern client) and TLS 1.2+ on the proxy’s TCP connections. HSTS with includeSubDomains on every Vericto domain.

Authentication and authorization

Vericto uses a two-layer authentication model:

  • Dashboard and REST API: JWT with a 24h expiry stored in an httpOnly cookie. Refresh token rotated on every use. All sessions are revoked when the password changes.
  • CLI and CI/CD: scoped API keys (ci_dryrun:execute), sent in the X-API-Key header over TLS. Keys are issued and revoked from the dashboard; in CI we recommend injecting them as secrets, or using OIDC (GitHub Actions) to exchange a short-lived token.

The authorisation model is RBAC (Role-Based Access Control) with 4 user roles: owner, admin, member and viewer. CI/CD API keys are not a user role: they authenticate with narrow scopes (for example ci_dryrun:execute).

Rate limiting: 100 requests/minute per IP for authentication endpoints. 5 failed login attempts in 10 minutes result in a 15-minute lockout.

SOC 2 and ISO 27001 audits

Vericto's audit trail is designed to serve as direct evidence in security audits:

Signed PDF compliance report
Ed25519-signed exports
Mapping to SOC 2 and ISO 27001 controls
GDPR compatible (public DPA)
Vericto's own SOC 2: in progress

Every audit trail export, and its PDF compliance report, is signed with Ed25519. With Vericto's public key, auditors independently verify offline that the file has not changed since it was generated. Enterprise customers also receive a signed report every month. More detail in Audit evidence.

For Enterprise customers, Vericto offers direct support during audits and security reviews.

Vericto's own certification: Vericto is in the process of SOC 2 certification. We do not have a SOC 2 report or ISO 27001 certification yet. If your security review needs more information, write to security@vericto.com.

Vulnerability reporting

If you discover a security vulnerability in Vericto, we ask that you report it to us responsibly before disclosing it publicly.

Send your report to security@vericto.com with:

  • Detailed description of the vulnerability
  • Steps to reproduce it
  • Estimated potential impact
  • Your name or alias (optional, for public credit if desired)

We commit to responding in less than 48 hours and publishing a fix in less than 30 days for critical vulnerabilities. We will not take legal action against researchers who report vulnerabilities in good faith.