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. If the Vericto proxy cannot reach the database or fails internally, the query receives an explicit error: it never passes unverified.

Least privilege by default

The 4 CRITICAL rules (DELETE without WHERE, UPDATE without WHERE, DROP, TRUNCATE) are active by default in all workspaces. Disabling them requires explicit action by an administrator.

Immutable audit trail

Every block or allow decision is recorded with a timestamp, full query (encrypted), AST node, triggered rule, and latency. Records cannot be modified or deleted by users.

Multi-region

The Vericto proxy is deployed across multiple regions with automatic failover. Data is stored in the region you configure, no cross-region transfers by default.

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 opens an upstream connection to your real database using the connection string you configured (stored encrypted with AES-256-GCM).
  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: encrypted with AES-256-GCM using per-workspace derived keys (HKDF over a master key). Never stored in plain text.
  • 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 bcrypt hashes. The plain-text key is shown only once, at creation time.
  • In transit: TLS 1.3 for all HTTP connections. TLS 1.2+ for the proxy’s TCP connections. HSTS with preload 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.

Compliance SOC2/ISO27001

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

SOC2 Type II (en proceso)
GDPR compliant
Audit trail exportable
Firma Ed25519 en exports

Each audit trail export includes an Ed25519 signature of the file content. With the workspace public key, auditors can independently verify offline that the export has not been modified since it was generated. The JSON export format is compatible with the SOC2 evidence schema.

For Enterprise customers, Vericto can provide: custom compliance reports, access to infrastructure logs, and direct support during audits.

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.