Guardarraíles SQL para agentes de IA — Bloquea consultas destructivas antes de que se ejecuten
Las guardarraíles SQL para agentes de IA interceptan sentencias peligrosas (DROP, TRUNCATE, DELETE/UPDATE masivos sin WHERE, escaneos completos de tabla, consultas de gran volumen, etc.) antes de que lleguen a tu MySQL, PostgreSQL o Cloudflare D1. FutrixData combina coincidencia con reglas estáticas y verificaciones EXPLAIN anticipadas — para que el mismo SELECT pueda ser de bajo riesgo en una búsqueda indexada y de riesgo medio cuando el plan revele un escaneo amplio (por ejemplo, una consulta de 100.000 filas).
Qué significan las "guardarraíles SQL" en un contexto de IA
Los permisos de la base de datos responden a "quién puede conectarse, quién puede leer o escribir". Los agentes introducen un problema más fino: bajo una misma conexión, sentencias diferentes implican riesgos muy distintos. SELECT * FROM orders WHERE id = 1001 es una búsqueda puntual; SELECT * FROM orders es un volcado de datos de clientes. Las guardarraíles son la capa intermedia que los distingue.
Cuatro categorías de riesgo
- Operaciones destructivas.
DROP TABLE,TRUNCATE,DELETE/UPDATEsinWHERE— bloqueadas por defecto. - Consultas amplias. Escaneos completos de tabla, índices ausentes, filas escaneadas estimadas grandes, joins profundos — escaladas por el
EXPLAINanticipado. - DDL.
ALTER,CREATE, eliminación de índices — advierten o requieren aprobación, según la tabla. - Cambios de privilegios.
GRANT,REVOKE— bloqueadas de plano.
Evaluación en dos capas: reglas estáticas + EXPLAIN anticipado
Las reglas estáticas detectan lo evidente (sin WHERE, la tabla destino es audit_logs, etc.). El sondeo detecta lo que un parser no puede: si la consulta realmente usa un índice. FutrixData escala el riesgo cuando:
- No se utiliza ningún índice.
- Las filas escaneadas superan el umbral configurado.
- El plan de Explain no está disponible o no es verificable.
- MySQL: escaneo completo de tabla, tabla temporal, filesort, subconsulta dependiente, join costoso.
- PostgreSQL: scan secuencial, subplanes profundos, ordenación de conjunto de resultados grande.
- D1: etapas
SCAN, scans de tablas base tras la expansión de vistas.
Los sondeos sólo elevan el riesgo; nunca degradan una operación ya clasificada como de alto riesgo.
Reglas integradas para MySQL / PostgreSQL / D1
| Sentencia | Acción por defecto |
|---|---|
SELECT, SHOW, DESCRIBE, EXPLAIN | allow |
INSERT, REPLACE, UPDATE … WHERE, DELETE … WHERE | warn |
UPDATE / DELETE sin WHERE | block |
CREATE, ALTER | warn |
DROP, TRUNCATE, GRANT, REVOKE | block |
Las reglas de usuario sobrescriben las integradas en virtud de un alcance más preciso y mayor prioridad. Por ejemplo: advertir en UPDATE por defecto, pero prohibir cualquier DELETE sobre orders en producción.
Modos de confianza
Los modos de confianza por fuente deciden qué pueden ejecutar automáticamente los puntos de entrada programáticos (Agent, MCP, Skill, CLI).
| Modo | Comportamiento |
|---|---|
| Approval | Cada ejecución requiere confirmación humana. |
| Cautious | Por defecto. Sólo las sentencias de bajo riesgo se ejecutan automáticamente. |
| Trusted | Bajo y medio riesgo automático; el alto riesgo aún requiere confirmación. |
| Danger | Todo se autoejecuta, incluidas operaciones que normalmente se bloquearían. Recomendado sólo para datos de prueba puntuales. |
Cómo funciona la aprobación
Cuando un agente recibe un resultado require_approval, el proxy devuelve una respuesta estructurada que describe la regla coincidente y la sentencia parseada. Quien invoca debe reenviar la solicitud con approve: true. La aprobación se verifica en la capa de entrada — los agentes no pueden simplemente pasar approve: true en una llamada arbitraria para evitar la interceptación.
Ejemplos
// Agent attempts:
DELETE FROM users;
// FutrixData response:
{
"ok": false,
"risk": "block",
"rule": "sql.delete_without_where",
"reason": "DELETE without WHERE clause on table users",
"data_source": "prod-postgres",
"audit_id": "audit_01HQ7M..."
}// Caller reissues:
{
"statement": "DELETE FROM users WHERE last_login < now() - interval '5 years'",
"approve": true,
"approval_reason": "scheduled GDPR purge, ticket OPS-2189"
}Preguntas frecuentes
¿Qué bloquea FutrixData por defecto en fuentes de datos SQL?
DROP, TRUNCATE, GRANT, REVOKE y UPDATE/DELETE sin WHERE. Todo lo demás cae en allow (lecturas) o warn (escrituras / DDL), con el modo de confianza decidiendo si los warns requieren aprobación.
¿Tendré falsos positivos en consultas legítimas?
Las reglas estáticas son deliberadamente estrechas — operaciones destructivas y patrones de WHERE ausente. El EXPLAIN anticipado es la capa más fina; los umbrales (filas máximas escaneadas, joins máximos) son configurables por fuente (puedes eximir tablas pequeñas concretas en las que el optimizador suela usar Seq Scan, ajustando el umbral de filas escaneadas).
¿Puedo anular un bloqueo?
Sí — para warn / require_approval, quien invoca reenvía con approve: true y un motivo que queda en el registro de auditoría. Las reglas block duras (por ejemplo, DROP en producción) requieren un cambio de configuración, no una anulación por llamada; eso es por diseño.
¿Esto funciona con SQL en bruto o sólo con ORMs?
SQL en bruto. FutrixData parsea sintaxis MySQL, PostgreSQL y D1 directamente para extraer tipo de comando, tabla destino, presencia de WHERE, joins y subconsultas. Los ORMs que emiten SQL en bruto se cubren de forma transparente.
¿Cómo difiere el manejo de MySQL respecto al de PostgreSQL?
El conjunto de reglas estáticas es el mismo. Los sondeos difieren: MySQL inspecciona escaneos completos de tabla, tablas temporales, filesort, subconsultas dependientes y estimaciones de filas en joins. PostgreSQL inspecciona scans secuenciales, conteos de joins, subplanes y ordenaciones de conjuntos de resultados grandes. D1 inspecciona SCAN vs SEARCH y valida los scans de tablas base tras la expansión de vistas.
¿El EXPLAIN anticipado añade latencia?
Sí — típicamente un round-trip extra a la base de datos antes de que se ejecute la consulta real. Para búsquedas puntuales son milisegundos; para consultas que no superan el explain, la latencia ahorrada al no ejecutarlas eclipsa el coste del sondeo.
Prueba FutrixData con tu propia base de datos
Aplicación de escritorio gratuita para macOS, Windows y Linux. Enterprise Edition autoalojada para despliegues en producción.