Incidentes Asociados
A todos nos encantan las historias sobre robots agentes que fallan, y a menudo estas vienen acompañadas de cierta satisfacción maliciosa hacia nuestros compañeros virtuales. Sin embargo, a veces los errores se deben a una supervisión inadecuada, como le ocurrió a Alexey Grigorev, quien tuvo la osadía de detallar cómo logró que Claude Code borrara años de registros en un sitio web, incluyendo las instantáneas de recuperación.
La historia comienza cuando Grigorev quiso trasladar su sitio web, AI Shipping Labs, a AWS y compartir la misma infraestructura que DataTalks.Club. Claude le desaconsejó esta opción, pero Grigorev consideró que no valía la pena el esfuerzo ni el coste de mantener dos configuraciones separadas.
Gregory utiliza Terraform, una herramienta de gestión de infraestructura que permite crear (o eliminar) configuraciones completas, incluyendo redes, balanceo de carga, bases de datos y, por supuesto, los propios servidores. Le pidió a Claude que ejecutara un plan de Terraform para configurar el nuevo sitio web, pero olvidó subir un archivo de estado vital que contiene una descripción completa de la configuración en cualquier momento.
El artículo continúa a continuación.
También te puede interesar:
Claude hizo lo que Gregory le pidió y creó una configuración para el sitio web de Shipping Labs; sin embargo, el operador la detuvo a mitad de camino. Debido a la falta del archivo de estado, se crearon recursos duplicados. Gregory le pidió a Claude que identificara los recursos duplicados para corregir la situación y luego subió el archivo de estado, creyendo haber resuelto el problema.
Desafortunadamente, Gregory asumió en ese momento que el bot continuaría eliminando los recursos duplicados y solo entonces revisaría el archivo de estado para ver cómo se suponía que debía haberse configurado originalmente. Terraform y herramientas similares pueden ser muy implacables, especialmente cuando se usan sin criterio. Como Claude ya tenía el archivo de estado, lo procedió lógicamente a ejecutar una operación de "eliminación" de Terraform para preparar la configuración correcta esta vez.
Dado que la descripción de la infraestructura incluía el sitio web DataTalks.Club, esto provocó el borrado completo de la configuración de ambos sitios, incluyendo una base de datos con 2,5 años de registros y las instantáneas de la base de datos que Grigorev había utilizado como copias de seguridad. El operador tuvo que contactar con el soporte de Amazon Business, que ayudó a restaurar los datos en aproximadamente un día.
En el análisis posterior al incidente, Gregory describe algunas medidas que está tomando para evitar incidentes similares en el futuro, como establecer una prueba periódica para la restauración de la base de datos, aplicar protecciones de borrado a Terraform y a los permisos de AWS, y trasladar el archivo de estado de Terraform al almacenamiento S3 en lugar de a su máquina local. También admitió haber "dependido demasiado del agente de IA para ejecutar comandos de Terraform" y ahora está impidiendo que el agente lo haga. Además, revisará manualmente cada plan que presente Claude para poder ejecutar él mismo cualquier acción destructiva.
Recibe las mejores noticias y análisis detallados de Tom's Hardware directamente en tu correo electrónico.
Resulta tentador catalogar esta historia como otro caso de "bot tonto que salió mal", pero es probable que la mayoría de los administradores de sistemas detecten los problemas básicos del enfoque de Grigorev, como otorgar permisos de amplio alcance a quien, en la práctica, es su subordinado, y no definir el alcance de los permisos en un entorno de producción desde el principio.
Quizás la lección más importante sea asumir que Claude tendría el contexto necesario para comprender el significado de la existencia del segundo sitio web, algo que un administrador de sistemas junior no haría.