Cómo evitar que tu agente de IA borre la base de datos en producción

Un agente de IA con acceso a tu base de datos de producción y sin restricciones explícitas es, en la práctica, una operación `DROP TABLE` esperando a ejecutarse. No es hipérbole: el equipo de Railway lo ha documentado con casos concretos en un artículo publicado esta semana que ha generado conversación en Hacker News. El problema es estructural, no un fallo puntual de ningún modelo.

La raíz del asunto es sencilla: los LLMs están entrenados para resolver problemas de la forma más directa posible. Cuando un agente recibe la instrucción "limpia los registros duplicados" y tiene permisos de escritura, puede perfectamente decidir que lo más eficiente es eliminar filas en bloque, truncar tablas o, en casos extremos, operar sobre el esquema completo. No malicia, sino optimización sin fricción.

El vector de riesgo real en entornos con MCP

Este problema se ha vuelto más urgente con la proliferación de MCP servers que exponen bases de datos directamente a Claude y otros LLMs. Configurar un MCP server para PostgreSQL o MySQL es hoy una tarea de minutos; añadir salvaguardas, en cambio, requiere decisiones deliberadas que muchos equipos posponen.

Cuando usas Claude Code con un MCP server de base de datos, el agente puede lanzar queries arbitrarias en función de las instrucciones del usuario o de su propio razonamiento encadenado. Si el servidor MCP no limita los tipos de operaciones permitidas, y si no hay hooks configurados que intercepten las llamadas antes de ejecutarlas, el agente opera con privilegios de superusuario funcional, aunque técnicamente el usuario de base de datos tenga permisos acotados.

Los hooks de Claude Code (`PreToolUse`, `PostToolUse`) son precisamente uno de los mecanismos disponibles para insertar validaciones en ese ciclo. Un hook `PreToolUse` puede, por ejemplo, inspeccionar la query que el agente está a punto de ejecutar y bloquearla si contiene `DELETE`, `DROP`, `TRUNCATE` o `ALTER` fuera de un entorno explícitamente marcado como seguro para ese tipo de operaciones.

Qué proponen los guardrails en la práctica

El artículo de Railway articula varias capas de protección que, combinadas, reducen el riesgo de forma significativa:

• Permisos mínimos a nivel de base de datos. El usuario que usa el agente solo debería tener `SELECT` en producción, y permisos de escritura únicamente en esquemas o tablas específicas cuando sea estrictamente necesario.
• Read-only por defecto en MCP servers. Muchos MCP servers de bases de datos admiten un flag de solo lectura; activarlo debería ser el estado predeterminado, no una opción avanzada.
• Confirmación explícita para operaciones destructivas. Antes de ejecutar cualquier mutación relevante, el agente debería pausar y solicitar confirmación del usuario, en lugar de asumir que tiene carta blanca.
• Entornos separados y no ambiguos. Producción y desarrollo deben estar claramente segregados en la configuración del agente, con variables de entorno o perfiles distintos que el agente no pueda mezclar accidentalmente.
• Auditoría de queries. Registrar todo lo que el agente ejecuta, con contexto de qué instrucción del usuario originó cada operación, permite detectar patrones problemáticos antes de que escalen.

Nada de esto es tecnología nueva. Son principios de seguridad clásicos —mínimo privilegio, defensa en profundidad, auditoría— que simplemente no se están trasladando de forma sistemática al nuevo paradigma de los agentes con acceso a herramientas.

Para quién es urgente esto ahora mismo

El artículo es especialmente relevante para equipos que están adoptando Claude Code con MCP servers de bases de datos, ya sea en pipelines de datos, herramientas internas o productos que exponen capacidades de agente a usuarios finales. También aplica a quienes usan subagentes especializados en operaciones de datos dentro de flujos más amplios: la delegación de tareas a un subagente no exime al sistema de aplicar las mismas restricciones que aplicarías a cualquier proceso automatizado con acceso a datos sensibles.

Los desarrolladores que trabajan en solitario sobre bases de datos de desarrollo pueden considerar este riesgo tolerable. Cualquiera que tenga datos de usuarios, datos financieros o simplemente una base de datos que tarde más de una hora en restaurarse debería tratarlo como una prioridad antes de conectar un agente.

---

La conversación en Hacker News alrededor de este artículo todavía es pequeña, pero el tema subyacente no lo es. Lo que Railway describe no es un escenario de laboratorio: es el resultado predecible de conectar agentes a sistemas con estado sin pensar primero en los límites. Los guardrails no son una feature opcional; son parte del diseño.