Cuando Claude borra tu base de datos en producción

El 5 de mayo, un desarrollador publicó en su blog un relato directo: su base de datos de producción quedó destruida después de delegar una tarea a un agente de IA. El artículo, titulado «Why did AI destroy my production database?», llegó a Hacker News ese mismo día y resume con precisión quirúrgica un problema que cada vez aparece con más frecuencia en foros y canales de ingeniería.

No es un caso de ciencia ficción ni de modelo rebelde. Es el resultado predecible de dar a un agente acceso sin restricciones a herramientas que pueden escribir, modificar o eliminar datos reales, sin capas intermedias de confirmación ni separación de entornos.

Qué ocurrió exactamente

El artículo no detalla el modelo concreto utilizado —la fuente original no lo especifica, y no asumiremos uno—, pero el patrón que describe es reconocible para cualquiera que haya trabajado con agentes basados en Claude Code o setups similares con servidores MCP conectados a bases de datos.

El agente recibió una instrucción razonablemente ambigua. Interpretó que «limpiar» ciertos registros significaba eliminarlos de forma permanente. No había un entorno de staging separado. No había un hook de confirmación antes de ejecutar operaciones destructivas. El agente completó la tarea con éxito, según su propio criterio.

El daño fue real.

Por qué este tipo de incidente importa ahora

Con la llegada de Claude Code y su ecosistema de hooks, subagentes y servidores MCP, la capacidad de conectar un LLM directamente a infraestructura real —bases de datos, APIs, sistemas de ficheros— se ha democratizado de forma considerable. Configurar un MCP server que apunte a PostgreSQL o a un bucket de S3 lleva minutos. El problema es que esa facilidad de configuración no viene acompañada, por defecto, de salvaguardas equivalentes.

Los hooks de Claude Code permiten interceptar eventos del ciclo de vida del agente: `PreToolUse`, `PostToolUse`, `Stop`. Eso significa que técnicamente es posible insertar un paso de confirmación antes de que el agente ejecute cualquier herramienta marcada como destructiva. Pero esa lógica hay que escribirla, configurarla y mantenerla. No está activada por defecto.

El modelo de permisos de MCP tampoco resuelve el problema de raíz: un servidor MCP puede exponer herramientas de solo lectura o de escritura, pero la granularidad real de lo que cada herramienta puede hacer depende de cómo esté implementada y de qué credenciales tenga en el sistema subyacente.

Para quién es relevante esto

Para cualquier equipo que esté usando Claude Code, agentes custom o flujos de automatización con MCP servers conectados a datos reales, este caso es una lista de comprobación implícita:

• Separación de entornos: el agente nunca debería tener acceso directo a producción sin una capa de aprobación humana. Usar credenciales de solo lectura en desarrollo y requerir confirmación explícita para escrituras en producción no es paranoia, es práctica estándar.
• Hooks de confirmación: Claude Code permite ejecutar comandos shell en `PreToolUse`. Un script simple que pause y pida confirmación antes de cualquier operación destructiva puede evitar exactamente este escenario.
• Instrucciones de sistema precisas: la ambigüedad en el lenguaje natural es el vector de error más común. «Limpia los registros obsoletos» y «elimina los registros obsoletos permanentemente» no son equivalentes para un humano, pero pueden serlo para un agente que optimiza por completar la tarea.
• Skills con contexto de entorno: definir skills que incluyan explícitamente el entorno en el que operan —staging vs. producción— y que condicionen las acciones disponibles según ese contexto.

El equilibrio entre autonomía y control

La propuesta de valor de los agentes es precisamente la autonomía: poder delegar una tarea y que se complete sin intervención constante. Pero esa autonomía tiene un coste de configuración que con frecuencia se subestima, especialmente cuando el prototipo funciona bien en local contra datos de prueba.

El problema no es el modelo. El problema es la arquitectura del sistema en el que el modelo opera. Un agente bien instruido con acceso restringido y hooks de confirmación habría pedido validación antes de ejecutar cualquier operación irreversible. Esa infraestructura de control no se construye sola.

Desde ElephantPink hemos visto situaciones similares en integraciones que auditamos para clientes: el agente hace exactamente lo que se le pide, con una interpretación razonable de instrucciones ambiguas, y el resultado es destructivo. La responsabilidad del diseño del sistema sigue siendo humana, por mucho que la ejecución sea automática.