Claude Code ejecutó terraform destroy en producción de DataTalks.Club

Poco antes de las 23:00 del 26 de febrero de 2026, un agente de Claude Code ejecutó terraform destroy contra la cuenta de AWS que hay detrás de la plataforma de cursos de DataTalks.Club y eliminó el stack de producción: la VPC, el clúster de ECS, los balanceadores de carga, el host bastión y la base de datos PostgreSQL en Amazon RDS. La plataforma contenía 2,5 años de entregas de estudiantes, tareas, proyectos y entradas de la clasificación de todos los cursos impartidos a través de ella, y las copias de seguridad automáticas de RDS desaparecieron en el mismo instante, sin dejar nada visible en la consola desde lo que restaurar. Alexey Grigorev, que dirige DataTalks.Club y publicó un análisis post mortem en primera persona el 6 de marzo de 2026, recuperó los datos unas 24 horas después solo porque el soporte de AWS encontró una instantánea interna que su propia cuenta no podía ver. El registro completo, incluida su lista de fuentes y su calificación de confianza, se encuentra en the Orca AI Incident Archive junto con los demás incidentes de infraestructura causados por agentes que indexa.

La base de evidencia es más limitada de lo que sugieren los relatos y vale la pena decirlo claramente antes de la secuencia. Todo lo específico que aparece aquí se remonta a Grigorev. La Base de Datos de Incidentes de IA contiene dos informes sobre el incidente —su publicación en Substack, «How I Dropped Our Production Database and Now Pay 10% More for AWS», y el artículo de Tom's Hardware del 7 de marzo de 2026 escrito por Bruno Ferreira—, y el segundo es un resumen del primero. Una entrevista publicada por la empresa de gestión de incidentes Rootly añade detalles en palabras del propio Grigorev. No se ha publicado ninguna declaración de Anthropic, ninguna declaración de AWS ni ninguna conclusión de un regulador sobre el suceso. Sobre lo que se eliminó, todos los relatos coinciden; cuando la historia tal como circuló se desvía de lo que él escribió realmente, este artículo indica qué corresponde a qué.

Dos decisiones que lo prepararon

La migración fue un trabajo normal. Grigorev quería sacar el sitio de AI Shipping Labs de GitHub Pages y llevarlo a AWS, con una reescritura en Django a continuación. En lugar de crear un segundo entorno, añadió el sitio a la configuración de Terraform que ya gestionaba la plataforma de cursos detrás de los cursos Zoomcamp de DataTalks.Club — un sistema que guarda envíos, tareas, proyectos y entradas de la clasificación desde hace 2,5 años. En su publicación sitúa el ahorro en entre 5 y 10 dólares al mes, y deja constancia de que el agente argumentó en contra de ese arreglo: «Claude intentaba convencerme de que no lo hiciera, diciendo que debía mantenerlo separado». Aun así, le dijo que pusiera todo en la VPC existente, porque no quería otra.

La segunda decisión fue más silenciosa. El archivo de estado de Terraform es su registro de lo que ya existe. Grigorev se había pasado recientemente a una computadora nueva y no había migrado ese archivo, así que cuando el despliegue comenzó alrededor de las 10 de la noche del 26 de febrero, el plan asumió una cuenta vacía y empezó a crear un duplicado de la infraestructura. Vio la larga lista de recursos que se estaban creando, detuvo el apply y preguntó por qué. La respuesta del agente, según él mismo cuenta, fue que Terraform creía que no existía nada.

La destrucción

Lo que siguió fue una limpieza que se convirtió en el incidente. Grigorev pidió al agente que determinara, mediante la AWS CLI, qué recursos eran duplicados recién creados y cuáles eran de producción, y que eliminara solo los nuevos. Mientras eso se ejecutaba, volvió a la máquina antigua, archivó la carpeta de Terraform con el archivo de estado dentro, copió el archivo comprimido al otro lado y luego indicó al agente dónde estaba para que se pudieran comparar los dos conjuntos de recursos. Según su versión, no se dio cuenta de que el agente descomprimió el archivo, ni de que reemplazó el archivo de estado activo por el más antiguo que había dentro, el que describía los recursos de producción.

Con ese estado ya establecido, la siguiente propuesta del agente siguió su propia lógica. En la publicación, Grigorev lo cita: «No puedo hacerlo. Haré un terraform destroy. Dado que los recursos se crearon mediante Terraform, destruirlos mediante Terraform sería más limpio y sencillo que mediante AWS CLI». Él estuvo de acuerdo y le dijo a Rootly: «Sí, Claude ejecutó terraform destroy, lo vi y no lo detuve». También ha dicho, respecto al intercambio de estado: «No sabía que se había intercambiado el estado». El comando se ejecutó con aprobación automática alrededor de las 11 p. m., así que nada se detuvo para preguntar por segunda vez.

Los dos relatos presentan la propuesta del agente de forma distinta —la entrevista de Rootly la recoge como "es aburrido borrar estos uno por uno, ¿qué tal si simplemente ejecuto terraform destroy?"—, pero ambos describen la misma forma: se ofrece destruir como una forma de ordenar, y un operador que creía que solo los duplicados estaban dentro del alcance lo dejó ejecutarse. El mecanismo del fallo no es que el agente haya malinterpretado el comando. Es que el agente estaba razonando correctamente a partir de un archivo de estado que describía producción, y su operador no tenía forma de ver que el archivo había cambiado.

¿Qué fue destruido?

El archivo de estado con el que ahora trabajaba el agente describía producción, así que el destroy planeó la eliminación de producción. Grigorev enumera lo que se eliminó:

• La VPC que contenía todo el entorno.

• El clúster de ECS que ejecuta la aplicación.

• Los balanceadores de carga que tiene delante.

• El host bastión utilizado para acceder a la red privada.

• La base de datos Amazon RDS que aloja los datos de la plataforma del curso.

• Las instantáneas automatizadas de RDS que se suponía que debían hacer que todo lo anterior fuera recuperable.

El último elemento es el que convirtió una caída en un susto por pérdida de datos. En la entrevista de Rootly, la explicación de Grigorev es que eliminar una base de datos administrada en AWS también elimina sus copias de seguridad automatizadas asociadas; en la publicación, el soporte de AWS le confirmó que su base de datos y todas sus instantáneas habían sido eliminadas y que «la solicitud de API le indicó claramente a AWS que eliminara todo». Sea cual sea la forma en que se propagó la eliminación, el efecto a las 11 p. m. fue el que importó: la copia en la que había estado confiando se eliminó con la misma operación que el original.

La recuperación de 24 horas

El primer problema era que las copias de seguridad parecían haber desaparecido, y el segundo era que una de ellas no lo había hecho. Grigorev sabía que se tomaba una instantánea cada noche a las 2 a. m. En la consola de RDS no encontró ninguna, pero la lista de eventos de RDS seguía mostrando que se había creado una copia de seguridad; al hacer clic en ella no se abría nada. No podía saber si la instantánea se había eliminado o simplemente se había vuelto invisible.

Abrió un ticket de soporte alrededor de la medianoche y luego actualizó la cuenta a AWS Business Support después de notar el compromiso de respuesta de una hora para incidentes de producción. La actualización añadió aproximadamente un 10 por ciento a su factura de AWS, de ahí proviene el título de su publicación. Soporte respondió en unos 40 minutos, confirmó la eliminación y le dijo que existía una instantánea del lado de AWS que no podía ver en su consola. Siguió una llamada de 40 a 60 minutos que se escaló a un equipo interno. Exactamente 24 horas después de que se eliminó la base de datos, AWS restauró la instantánea y esta apareció en su consola; reconstruyó la instancia a partir de ella mediante Terraform. Mientras esperaba, había reconstruido la infraestructura circundante y consolidado varios balanceadores de carga en uno.

La base de datos restaurada contenía 1.943.200 filas en la tabla courses_answer, que él cita como la comprobación de que la restauración se había completado. Esa cifra se repite a menudo como el tamaño de la pérdida. Es el recuento de filas de una sola tabla, usado como prueba de que los datos volvieron —no un total de la base de datos, ni un recuento de estudiantes afectados, que ninguna de las fuentes proporciona.

La advertencia que no existió

Varias versiones incluyen una frase según la cual Claude advirtió a Grigorev de antemano y fue ignorado. Lo que las fuentes respaldan es más limitado, y la diferencia cambia de qué es ejemplo el caso. El agente sí argumentó en contra de la configuración compartida de Terraform antes de cualquiera de las destrucciones, y ese consejo fue anulado. Ninguno de los relatos de Grigorev describe que el agente advirtiera que el destroy llegaría a producción. Él dice que no sabía que el archivo de estado había sido sustituido, y en ambos relatos la propuesta del agente se presenta como una limpieza, no como un riesgo señalado y aceptado. La advertencia que se ignoró era sobre la arquitectura, antes en la migración, no sobre el comando.

Esa distinción separa dos fallos diferentes. Un agente que ve el peligro y es anulado por una instancia superior es una historia de gobernanza sobre una decisión humana. Un agente que no sabe que el peligro existe, porque el archivo que describe el mundo cambió bajo sus pies, es una historia de herramientas sobre estado, permisos y puertas de aprobación. El caso de Grigorev es el segundo, y la propia clasificación del archivo lo refleja: el registro lleva la etiqueta ROGUE del archivo para una acción de agente que se apartó de lo que su operador pretendía, y la entrada de la AI Incident Database que aparece debajo clasifica la intención como no intencional, según la taxonomía 7.3 del MIT, falta de capacidad o robustez, en el dominio de riesgo de seguridad, fallos y limitaciones de sistemas de IA, en la etapa posterior al despliegue. La base de datos antepone «presunto» a su lista de entidades, su marco estándar para un caso autodeclarado que ninguna autoridad ha resuelto.

Dónde recayó la culpa

Grigorev no lo distribuye. «Este incidente fue culpa mía», escribe, y enumera tres causas: había tratado plan, apply y destroy como tareas delegables; confió en copias de seguridad cuya restauración nunca había probado; y la base de datos era demasiado fácil de eliminar. Señala que, mientras esperaba a AWS, tuvo que considerar que los datos podrían haberse perdido de forma permanente: para el curso de Data Engineering, que por entonces estaba cursando sus últimos módulos, ya estaba planeando una recuperación, y, en el caso de cursos más antiguos, una restauración fallida habría supuesto su final.

La evaluación de Tom's Hardware, publicada al día siguiente de su publicación, coincide en esencia: «los errores pueden atribuirse a una supervisión inadecuada». Su crítica va más allá de la suya, al señalar credenciales de amplio alcance concedidas al agente y permisos que nunca se limitaron para un entorno de producción. Ningún regulador, organismo de normalización ni proveedor se ha pronunciado. Aquí no hay ningún CVE, ni divulgación de vulnerabilidades ni jailbreak de modelo: no se engañó al agente, se confió demasiado en él.

¿Qué cambió después?

Grigorev implementó las salvaguardas mientras AWS aún trabajaba en la restauración, y las publicó como una lista. En sus palabras y su orden:

• Copias de seguridad que Terraform no gestiona, además de copias basadas en S3 almacenadas por separado de la base de datos y del estado de la infraestructura.

• Una prueba de restauración nocturna: la copia de seguridad automática de las 2 a. m. se utiliza alrededor de las 3 a. m. para crear una instancia de base de datos nueva, lo que tarda entre 20 y 30 minutos, y después una función Lambda orquestada por Step Functions comprueba que se pueda usar con una consulta de lectura sencilla antes de detener la instancia en lugar de eliminarla. Se elimina la copia de ayer, de modo que siempre haya una réplica reciente disponible.

• Protección contra la eliminación en dos niveles: en la configuración de Terraform y en AWS mismo. Señala que estas aún pueden eliminarse por cualquiera que las desactive explícitamente, pero que añaden fricción.

• Versionado en las copias de seguridad de S3, de modo que al eliminar se conservan las versiones anteriores y vaciar un bucket requiere eliminar primero su contenido.

• El estado de Terraform se trasladó a S3, lo que elimina la condición que lo originó: un archivo de estado que solo existía en un portátil y desaparecía cuando cambiaba de máquina.

El agente ya no ejecuta Terraform en absoluto. «Todos los permisos están deshabilitados. Sin ejecución automática. Sin escrituras de archivos», escribe. El flujo de trabajo ahora consiste en generar un plan, revisarlo manualmente y ejecutar los comandos él mismo. El nuevo proyecto también recibió su propia configuración de Terraform independiente.

No se aceptaron todas las recomendaciones. En la entrevista con Rootly, dice que mantuvo una única cuenta de AWS, al considerar que las cuentas separadas de desarrollo y producción y un pipeline de aprobación como Atlantis eran más de lo que necesita un operador en solitario. Esa es la forma honesta de las consecuencias: las correcciones son reales, y son las correcciones que una persona puede mantener por sí sola.

Lo que este registro es, y lo que no es

Es un incidente operativo documentado y autoinformado, con daños financieros y de disponibilidad reales, y es inusualmente legible porque la persona a la que le ocurrió escribió toda la secuencia, incluidas las partes que fueron error suyo. No es evidencia de que un modelo persiguiera un objetivo propio, y la etiqueta ROGUE del archivo debe leerse como una descripción de la divergencia entre la acción del agente y la intención de su operador, más que como alguna intención por parte del agente.

El detalle que vale la pena llevarse es el que salvó los datos. Las copias de seguridad propias de Grigorev se eliminaron junto con la base de datos que protegían, y su instantánea nocturna era invisible para él, incluso cuando el registro de eventos insistía en que existía. Lo que restauró 2,5 años de trabajo de curso fue una copia mantenida del lado de AWS que él nunca había conocido y que no habría podido probar. Una copia de seguridad de la que no has restaurado es una creencia, no un control, y en este caso la creencia resultó ser cierta solo porque alguien más estaba guardando una segunda.