Tu LLM generó un DELETE sin WHERE. Lo bloqueamos antes de que tocara producción.

Un allowlist de operaciones bloquea por el primer token de la query: si empieza con DELETE, bloquea. Si empieza con SELECT, permite. Es un instrumento sin granularidad.

El AST (Abstract Syntax Tree) parsing construye el árbol sintáctico completo de la query. Vericto recorre ese árbol buscando nodos que violen las reglas. Esto permite detectar:

• UPDATE products SET price = 0 sin WHERE clause (UpdateStmt > WhereClause = NULL)
• DELETE FROM users sin WHERE en cualquier nivel de anidamiento
• TRUNCATE disfrazado dentro de un CTE
• DELETE FROM orders LIMIT 0 — un DELETE que no borra nada pero es sintácticamente peligroso

Un allowlist no puede detectar ninguno de estos casos porque todos empiezan con tokens que parecen seguros en superficie.

El parsing AST de una query típica (<500 tokens) ocurre en <2ms en p99. El overhead total del proxy (TLS handshake + parsing + forwarding) vs conexión directa es <0.3% en benchmarks.

El proxy está escrito en Rust con tokio para manejo asíncrono de conexiones TCP. Sin garbage collection pauses, sin overhead de runtime. Diseñado específicamente para el path crítico.

El registro de eventos en el audit trail es completamente asíncrono — no está en el path crítico de la query.

No. Vericto actúa como proxy TCP transparente. Solo cambias el host en tu connection string:

Tu ORM (SQLAlchemy, Prisma, ActiveRecord, Drizzle) no sabe que hay un proxy en el medio. Las queries llegan exactamente igual. Vericto las intercepta, las analiza, y las reenvía si son seguras.

El proxy de Vericto se despliega en múltiples regiones con alta disponibilidad. El plan Team incluye SLA de uptime. En el caso improbable de un fallo total del proxy, el comportamiento es fail-closed: las queries no pasan hasta que el proxy se recupere.

Para el plan Enterprise, ofrecemos VPC deployment — el proxy se despliega dentro de tu propia infraestructura, eliminando la dependencia de red externa.

Puedes monitorear el estado del servicio en status.vericto.com.

Sí, el texto completo de cada query interceptada se almacena en el audit trail, cifrado en reposo con AES-256-GCM. Esto es necesario para la funcionalidad de explicación accionable y para el audit trail de compliance.

El texto de la query se almacena también como hash SHA-256 para indexación. El acceso al texto completo requiere autenticación con permisos de workspace.

La retención varía por plan: 7 días (Free), 30 días (Builder), 90 días (Team), configurable (Enterprise). Puedes exportar y purgar el audit trail en cualquier momento.

Los datos de queries nunca se usan para entrenar modelos ni se comparten con terceros.

El CLI de Vericto permite validar un archivo de queries SQL contra el ruleset de tu workspace sin necesidad de conexión a la base de datos:

vericto check --file migrations.sql --dialect postgres

✓ 12 queries analizadas.
✗ 1 query destructiva detectada:

  Line 47: TRUNCATE TABLE orders
  Rule: VERICTO-011 (severity: CRITICAL)
  AST node: TruncateStmt > relation: orders
  Suggested fix: DELETE FROM orders WHERE created_at < NOW() - INTERVAL '90 days'

El proceso termina con exit code 1 si hay queries destructivas (el pipeline de CI falla) o exit code 0 si todo está limpio. Compatible con GitHub Actions, GitLab CI y Jenkins.

No. Vericto es específico para bases de datos SQL. El AST parsing es una técnica que aplica al lenguaje SQL — extenderlo a NoSQL requeriría parsers completamente diferentes y el concepto de "query destructiva" es menos definido en esos contextos.

El foco actual es SQL con los dialectos más usados en producción con agentes de IA: Postgres, MySQL, Oracle y SQL Server, con SQLite y Snowflake en el roadmap. Esto cubre el 95%+ de los casos de uso de LLM-to-SQL en producción.