Bloquea el SQL destructivo
DELETE y UPDATE sin WHERE, DROP, TRUNCATE y DDL riesgoso, también dentro de CTEs y en cada sentencia de un string multi-sentencia. Cada bloqueo trae la regla, el nodo AST y una corrección sugerida.
AST SEMÁNTICO
Firewall SQL determinístico para agentes de IA
Tu LLM generó un DELETE sin WHERE. Lo bloqueamos antes de que tocara producción.
Conéctalo como proxy TCP, API, CLI o MCP. Vericto parsea el AST de cada query y bloquea las operaciones destructivas antes de que lleguen a tu base de datos.
Agente de IA
Vericto
Base de datos
-
DELETE FROM usersBLOQUEADAVERICTO-001DELETE sin WHERE: no llega a la base de datos. El agente recibe un error SQL y la corrección sugerida.DELETE FROM users WHERE id = $1 -
SELECT email FROM customersENMASCARADAVERICTO-085email es una columna sensible: el proxy reescribe la query y la base de datos devuelve el valor enmascarado.a***@example.com -
SELECT id, total FROM orders WHERE id = $1PERMITIDAorders está en la allowlist del agente: la query pasa sin cambios.id · total
Sin cambios en tu código
Sin tarjeta de crédito
Misma query, mismo veredicto, siempre
CARACTERÍSTICAS
Qué hace Vericto con cada query
Un motor AST determinístico decide sobre cada sentencia antes de que se ejecute. Cuatro controles corren sobre él.
Enmascara columnas sensibles
Marca columnas como email o card_number y decide por columna: bloquear, marcar o enmascarar (full, last4, email o hash). En el proxy TCP, la base de datos devuelve el valor ya enmascarado. Team y Enterprise.
Una allowlist por agente
Cada agente usa solo las tablas y columnas que le das, en solo lectura o lectura y escritura. Todo lo demás se deniega. Empieza en observe y pasa a enforce cuando el tráfico lo confirme. Team y Enterprise.
Simula antes de aplicar
Reproduce un cambio de reglas contra tu tráfico real (hasta 30, 90 o 180 días según el plan) y mira qué flujos legítimos bloquearía, antes de que bloquee nada. Desde el dashboard o desde CI. Builder, Team y Enterprise.
Los paneles reproducen la salida tal como la describe la documentación; los datos son de ejemplo.
- MCP: el agente valida su SQL mientras lo escribe
- CLI y GitHub Action: falla el PR antes del deploy
- Agentes LLM y Text-to-SQL
- Reglas custom en YAML sobre el AST
- Audit trail firmado y alertas
- Fail-open por defecto, fail-closed si lo eliges
- Las credenciales nunca salen de tu red
- AST frente a allowlists de operaciones
COBERTURA
42 reglas · 6 dialectos · 8 familias de incidentes · 52 escenarios
Cada escenario es un patrón concreto de SQL que una regla detecta, probado contra vericto-engine 4.1.1. Se cuenta una vez, no una vez por dialecto ni por posición.
10
Borrado o reescritura masiva de datos
DELETE y UPDATE sin WHERE o con un WHERE siempre verdadero, TRUNCATE, MERGE, CTEs que modifican datos
7
Destrucción del esquema
DROP TABLE, DATABASE y SCHEMA, DROP COLUMN, RENAME, CREATE OR REPLACE de Snowflake
6
Protecciones desactivadas
RLS y triggers desactivados, constraints eliminadas, masking policies quitadas, PRAGMA inseguros de SQLite
10
Exfiltración y fuga de datos
Copias de tablas enteras, columnas sensibles, accesos fuera de la allowlist, unloads y shares de Snowflake, ATTACH y VACUUM INTO
6
Ejecución de código y escalada de privilegios
COPY … PROGRAM, bloques DO, GRANT, cambio de rol y tasks de Snowflake, load_extension
4
Inyección y evasión
Tautologías OR 1=1, sondas por tiempo, sentencias apiladas, comentarios ejecutables de MySQL
5
Rendimiento y costo
SELECT sin límite, SELECT * sin WHERE, lotes de más de 10.000 filas, warehouses de Snowflake
4
Recuperación y calidad de datos
Cambios de tipo con pérdida, INSERT sin columnas, DELETE … LIMIT 0, retención de Snowflake en 0
Quién lo causa
La misma regla frena el error de una persona, el bug de un ORM y el ataque de un agente comprometido. Cada escenario se cuenta en su origen más típico:
- 5 Consola de un desarrollador o DBA
- 7 Bug de la aplicación o del ORM
- 9 Migración en CI/CD
- 9 Agente de IA o text-to-SQL
- 9 Atacante por SQL injection
- 13 Insider o agente comprometido
Dentro de la sentencia, no solo arriba
Un DELETE escondido en un CTE, una tautología en una tabla derivada o en una rama UNION, un DROP apilado después de un COMMIT, un INSERT … SELECT dentro de un trigger de SQLite: el motor recorre el árbol sintáctico hasta 50 niveles y evalúa cada sentencia de un string multi-sentencia. Lo que es más profundo, o lo que el parser no puede leer, no pasa en silencio: queda registrado como error de parseo, y se bloquea si eliges parse_error: block.
El anidamiento patológico no lo tumba
Unos 950 NOT encadenados, unos 4 KB de SQL, desbordan la pila de un parser recursivo y matan el proceso que lo ejecuta. Vericto mide el anidamiento del texto antes de parsearlo y rechaza lo que pasa de 200 niveles: el proxy sigue en pie y la sentencia queda registrada como demasiado compleja (bloqueada con parse_error: block).
En 6 incidentes públicos que documentamos, el SQL destructivo (el publicado, o la sentencia que implica el mecanismo) da BLOCKED con estas reglas cuando la conexión pasa por Vericto: un DELETE FROM en cada tabla de producción, DROP TABLE pedido a frameworks de text-to-SQL (dos CVE), un schema push que borró tablas, COPY … TO PROGRAM en un servidor MCP «read-only» y un COMMIT; DROP SCHEMA que escapó de una transacción de solo lectura. Los casos, con sus fuentes.
CÓMO FUNCIONA
Tres pasos. Empieza por donde quieras.
Empieza por donde te dé menos fricción: proxy TCP, Runtime API, CLI, Validation API o MCP. Los cinco llaman al mismo motor AST determinístico, así que el veredicto es el mismo por cualquiera de ellos.
DELETE no tiene WHERE. Narración en inglés, con subtítulos en inglés y en español.Conéctate como prefieras
Cinco modos sobre el mismo motor. Dos actúan en runtime y bloquean en línea; tres actúan antes de ejecutar, en tu pipeline o en el editor del agente. Cómo elegir.
EN RUNTIME
Proxy TCPsolo cambias el host del connection string; bloquea en líneaRuntime APItu aplicación pregunta antes de ejecutar; también Oracle, SQL Server, Snowflake y SQLite
ANTES DE EJECUTAR
CLIvalida en pre-commit y CI, con exit code según el veredictoValidation APIlotes de SQL por HTTPS, sin instalar nadaMCPel agente valida el SQL mientras lo escribe
Vericto parsea el AST completo, no el texto
Cada query se analiza a su árbol sintáctico: con pg_query (el parser de Postgres) en Postgres y con sqlparser-rs en MySQL, Oracle, SQL Server, Snowflake y SQLite. El árbol completo, no solo el primer token ni patrones de texto. El mismo motor en los cinco modos, así que el veredicto no depende de por dónde entró la sentencia.
DeleteStmt
relation: users
whereClause: NULL ⚠
Destructivas bloqueadas. Seguras pasan.
Las queries que violan el ruleset se bloquean con el nodo AST infractor, la regla activada y la versión segura sugerida. En runtime la sentencia no llega a la base de datos; antes de ejecutar, el veredicto vuelve como exit code o como respuesta al agente. Las limpias pasan sin cambios.
BLOQUEADA
DELETE FROM users
PERMITIDA
SELECT * FROM users WHERE id = $1
INTEGRACIONES
Funciona con tu stack actual
Dos caminos. En PostgreSQL y MySQL, el proxy TCP no requiere cambios en tu código. En las seis bases, los SDK, la API de runtime, el CLI y MCP revisan el SQL antes de que se ejecute.
Bases de datos
Sin cambios de código
Proxy TCP
Apunta tu connection string al proxy. Funciona con cualquier driver u ORM y bloquea las queries destructivas en línea, antes de que lleguen a la base.
Configurar el proxy →
Las seis bases de datos
SDK, API de runtime, CLI y MCP
Los SDK de Python y Node y la API de runtime revisan cada query antes de que tu código la ejecute. El CLI y MCP revisan el SQL antes de que llegue a producción.
Frameworks y herramientas
- LangChainProtege agentes SQL desde los SDK de Python y JS
- dbt
vericto-dbt checkrevisa los modelos compilados en CI - AirflowOperador SQL y cluster policy en el SDK de Python
- MCPServidor remoto:
check_sqlpara Claude Code, Kiro y más - GitHub ActionsLa acción
vericto/check-sqlanota los hallazgos en el PR - GitLab CIJob listo:
vericto initcon--target gitlab
¿No ves tu stack? Cualquier driver de PostgreSQL o MySQL funciona a través del proxy, y la API de runtime, desde cualquier lenguaje. Ver todas las integraciones →
SOC 2 · ISO 27001
Evidencia para tu auditoría, lista cada mes
Lo que Vericto bloquea y registra en producción ya es la evidencia que pide un auditor SOC 2 o ISO 27001. Vericto la entrega lista para leer y firmada:
- Reporte PDF firmado con Ed25519 con cada export: resumen del período, reglas, controles y configuración. Desde el plan Team.
- Mapeo a 12 controles de SOC 2 (CC6.1–CC8.1) e ISO 27001 (A.5.18–A.8.32), con lo que los debilita.
- Un reporte cada mes, conservado 13 meses en Enterprise: el período de auditoría completo, sin exportar nada a mano.
PRECIOS
Precios simples. Sin sorpresas.
Los precios no incluyen impuestos. El IVA, GST o sales tax que corresponda a tu país se añade al confirmar el pago.
Team
$249/mes
- 50M queries/mes
- Supera el volumen sin cortes: te avisamos
- Columnas sensibles y acceso de agentes
Enterprise
Desde
$2,500
/mes
- Contrato anual
- SLA de 99,9% (Standard); 99,95% y 99,99% con despliegue dedicado
- Reporte de cumplimiento mensual automático, conservado 13 meses
Con facturación anual, Builder queda en $63/mes y Team en $199/mes.
EMPIEZA HOY
Tu agente de IA no debería tener acceso irrestricto a producción.
Conecta tu primera base de datos en menos de 5 minutos.
Sin tarjeta de crédito
Onboarding en <5 minutos
Cancela cuando quieras
Determinístico y verificable. No pedimos que confíes a ciegas.
Vericto no usa IA para decidir qué bloquear. El motor, el proxy y la CLI tienen código público, y cada afirmación de esta página se puede comprobar.
Código público
El motor AST, el proxy TCP y la CLI, en GitHub, como código fuente disponible bajo la Functional Source License (FSL-1.1-ALv2), que pasa a Apache-2.0 dos años después de cada versión: vericto-engine, vericto-proxy, vericto-cli.
CLI en npm
Instálala y prueba tus migraciones contra tus reglas:
@vericto/vericto-cliEvidencia verificable sin conexión
Los reportes de cumplimiento van firmados con Ed25519 y tu auditor comprueba la firma con la clave pública, sin cuenta ni red. Cómo verificarlos.
Changelog y estado públicos
Cada versión, con lo que cambió y por qué, en el changelog. La disponibilidad del servicio, en la página de estado.
+0,42 ms
Lo que agregó el proxy en p50 en PostgreSQL con 1 conexión, medido en staging el 16 de octubre de 2026 (vericto-proxy 4.12.0, tarea ARM64 de 0,25 vCPU, Aurora Serverless v2 a 10 ACU, TLS, modo enforce). Es una medición, no una garantía: condiciones y método.
Determinístico
La misma query con las mismas reglas recibe siempre el mismo veredicto. Antes de aplicar una regla, el simulador muestra qué flujos legítimos bloquearía.