Las reglas estándar cubren lo destructivo. Tu negocio tiene más reglas
Las 42 reglas estándar bloquean DELETE y UPDATE sin WHERE, DROP, TRUNCATE y DDL riesgoso. No saben que en tu stack la tabla payments no se toca sin WHERE, ni que tu agente de soporte no tiene nada que hacer en ella. Eso es una política, y en Vericto se escribe, se prueba y se aplica con el mismo motor determinístico que decide todo lo demás: misma sentencia, mismas reglas, mismo veredicto.
Reglas propias, como código
Una regla custom es una condición YAML sobre el árbol sintáctico de la sentencia: el tipo de nodo, la tabla y el predicado. No hay modelo ni varianza: la sentencia cumple la condición o no la cumple.
- Se crea en el dashboard o por API (
POST /rules/custom). La condición se revisa mientras escribes y antes de guardar ves un diff contra la versión guardada. - Cada coincidencia queda en el audit trail con el código de la regla (
CUSTOM-001) y el nombre que le diste. - Hasta 5 reglas custom en Builder, 20 en Team e ilimitadas en Enterprise.
Observa primero, aplica después
Cada capa empieza sin bloquear nada, para que veas qué haría antes de que lo haga:
- El workspace: con el observe mode, una ventana de 7 días al conectar tu primera base, cada BLOCK se degrada a FLAG. El dashboard muestra qué se habría bloqueado y con qué regla.
- Cada regla custom: empieza en monitor, se evalúa y se registra, y nunca bloquea. «Promover a enforce» te dice qué hará la regla en tu workspace y enlaza su última simulación, o te avisa si no la simulaste.
- Cada agente: su allowlist de tablas y columnas empieza en observe: lo que queda fuera se marca con
VERICTO-087y se bloquea recién en enforce.
Simula contra tu tráfico real
El simulador de reglas reproduce un cambio contra el historial de queries de tu workspace (hasta 30 días en Builder, 90 en Team y según contrato, hasta 180, en Enterprise) y dice qué flujos legítimos habría bloqueado. La allowlist de un agente se simula contra sus queries de los últimos 7 días. Nada se ejecuta contra tu base de datos.
Lecturas sin límite y datos sensibles
- Un
SELECTsinLIMIT,FETCHniTOPse marca conVERICTO-050, en los seis dialectos. - La allowlist por agente decide qué tablas y columnas lee o escribe cada identidad (Team y Enterprise).
- Las columnas sensibles se bloquean, se marcan o vuelven enmascaradas (Team y Enterprise).
Un kill switch por agente
Cuando un agente hace algo que no debe, primero se lo detiene. En Respuesta a incidentes → Bloquear un agente, el owner o un admin elige el objetivo (una API key, un usuario de base de datos, un principal del registro o todos los agentes del workspace), escribe el motivo y confirma. En todos los planes. El bloqueo no toca la allowlist ni las reglas: al desbloquear, todo vuelve a estar como antes.
- API de runtime, SDK,
check_sqldel MCP y CLI: al instante. La siguiente llamada recibe BLOCKED conVERICTO-105y un mensaje que le dice al agente que no reintente y que pida ayuda a una persona. - Proxy TCP: en su siguiente sincronización de reglas (300 segundos por defecto, configurable hasta 30), como una allowlist que no permite ninguna tabla. Lo aplica cualquier vericto-proxy con acceso de agentes (4.8.0 o posterior), sin actualizar nada: la sentencia se rechaza con
VERICTO-087. - Mientras el workspace está en modo monitor o en una ventana de observe mode, un proxy anterior a 4.18.0 solo marca las sentencias del agente bloqueado, sin rechazarlas. El dashboard lo advierte al bloquear.
- Cada bloqueo y desbloqueo queda en el registro de auditoría con el actor, el motivo y la hora, y se avisa por los canales del workspace.
Límites
- Es defensa en profundidad: los roles, permisos y el row-level security de tu base de datos siguen siendo la primera línea.
- Vericto ve el SQL, no el prompt: no intenta detectar una inyección, limita lo que la sentencia puede hacer.
- Una simulación es evidencia, no prueba: un flujo que no corrió en la ventana no está cubierto.