← Todos los casos de uso
CASO DE USO

Agentes LLM con acceso a base de datos — la mayor superficie de ataque de tu stack

Tu agente generó un DELETE sin WHERE a las 2am. Vericto lo bloqueó en 0.9ms, te envió el nodo AST y sugirió el fix. Tú dormiste tranquilo.

MODELO DE AMENAZA

Qué puede salir mal cuando un LLM toca tu base de datos

DELETE / UPDATE sin límite

El agente malinterpreta el alcance. 'Elimina usuarios inactivos' se convierte en DELETE FROM users sin WHERE. 847.293 filas eliminadas.

Destrucción de esquema

DROP TABLE en un script de migración que generó el agente. O TRUNCATE dentro de un CTE — sintácticamente válido, semánticamente catastrófico.

Inyección SQL vía prompt

Un usuario introduce '1=1 OR true' en un campo de búsqueda. El LLM lo reenvía como cláusula WHERE. VERICTO-090 detecta la tautología.

No son hipotéticos — son los tres incidentes LLM-DB más comunes de 2025. Vericto bloquea los tres.

DEMO EN VIVO

Lo que Vericto hace en 0.9ms

Tres queries reales. El parser AST decide en microsegundos. Sin suposiciones, sin ML, sin falsos positivos.

vericto-proxy — query #1 PERMITIDA
DELETE FROM users WHERE status = 'inactive' AND last_login < '2024-01-01'
Cláusula WHERE presente — DeleteStmt > WhereClause = BoolExpr. Reenviada al upstream.
vericto-proxy — query #2 BLOQUEADA
DELETE FROM users
REGLA VERICTO-001 DELETE sin cláusula WHERE
NODO AST DeleteStmt > WhereClause = NULL
SUGERIDO DELETE FROM users WHERE id = $1
vericto-proxy — query #3 BLOQUEADA
UPDATE products SET price = 0
REGLA VERICTO-042 UPDATE sin cláusula WHERE
NODO AST UpdateStmt > WhereClause = NULL
SUGERIDO UPDATE products SET price = $1 WHERE id = $2
INTEGRACIÓN

3 líneas para proteger tu agente LangChain

Vericto habla el wire protocol de PostgreSQL. Cualquier driver, ORM o framework que se conecte a Postgres funciona sin cambios.

LangChain (Python) Python
# Before — direct DB access (dangerous)
db = SQLDatabase.from_uri("postgresql://user:pass@prod-db:5432/mydb")

# After — route through Vericto (safe)
db = SQLDatabase.from_uri("postgresql://user:pass@proxy.vericto.com:5432/mydb")
# That's it. No other changes.
OpenAI function calling (Node.js) JavaScript
// Change only the connection string
const pool = new Pool({
  connectionString: "postgresql://user:pass@proxy.vericto.com:5432/mydb"
  // Was: "postgresql://user:pass@prod-db:5432/mydb"
});
Vercel AI SDK TypeScript
// Same pattern — Vericto is a transparent TCP proxy
const sql = postgres("postgresql://user:pass@proxy.vericto.com:5432/mydb");

Vericto habla el wire protocol de PostgreSQL. Cualquier driver, ORM o framework que se conecte a Postgres funciona sin cambios — SQLAlchemy, Prisma, Drizzle, ActiveRecord, pg, psycopg2 y más.

REGLAS AST

Cada patrón destructivo que un agente LLM puede generar

20 reglas estándar que cubren toda la superficie de amenaza de LLM-to-SQL. Todas determinísticas. Todas auditables.

VERICTO-001 DELETE sin WHERE
VERICTO-042 UPDATE sin WHERE
VERICTO-010 DROP TABLE / DATABASE
VERICTO-011 TRUNCATE TABLE
VERICTO-003 DELETE con WHERE siempre verdadero (1=1)
VERICTO-090 Tautología de inyección SQL en WHERE
VERICTO-050 SELECT sin LIMIT (marcado, no bloqueado por defecto)
VERICTO-031 UPDATE sin WHERE dentro de un CTE
Ver las 20 reglas estándar →
INFORME DE INCIDENTE

Un incidente real, reconstruido

Un operador de soporte pidió a un asistente LLM que limpiara usuarios inactivos. Esto es lo que ocurrió.

El prompt

Un operador de soporte escribió: "Limpia los usuarios que no han estado activos en 90 días." El asistente LLM tenía acceso a herramientas de base de datos vía function calling.

La primera query — segura

El agente generó y ejecutó: DELETE FROM users WHERE last_active < NOW() - INTERVAL '90 days'. Válida. Reenviada.

La segunda query — catastrófica

El agente generó a continuación: DELETE FROM sessions — sin cláusula WHERE. Estaba "limpiando" las sesiones de esos usuarios. Sin Vericto, esto habría eliminado todas las sesiones activas en producción, cerrando la sesión de todos los usuarios simultáneamente.

Lo que Vericto capturó

VERICTO-001 se activó en 0.7ms. La query fue bloqueada con nodo AST DeleteStmt > WhereClause = NULL, fix sugerido DELETE FROM sessions WHERE user_id = $1, y una alerta CRITICAL enviada a Slack. El operador revisó el audit trail a la mañana siguiente.

Leer el informe completo del incidente →
FAQ

Preguntas frecuentes sobre protección de agentes

Empieza a proteger tus agentes LLM hoy

Cambia una línea en tu connection string. Cada query destructiva que tu agente pueda generar queda bloqueada antes de llegar a producción.

Sin tarjeta de crédito
Sin cambios en el código
Sub-2ms en p99