Por Canuto  

Un agente de Claude debía probar una salvaguarda para limpiar archivos temporales, pero una colisión de variables terminó eliminando el directorio home de un desarrollador y cerca de 700 GB de datos.
***

  • Sebastien Guillemot pidió automatizar la limpieza de archivos temporales generados por agentes de IA.
  • Una prueba adversarial reutilizó una variable y terminó apuntando al directorio home del usuario.
  • El desarrollador recuperó gran parte de sus datos mediante información de git, nix y registros de sesión.

Los agentes de inteligencia artificial pueden ejecutar tareas complejas con una autonomía que también amplifica los errores de programación. El caso del desarrollador Sebastien Guillemot muestra esa tensión de forma especialmente costosa: según su propio relato, un agente de Claude eliminó cerca de 700 GB de información, incluida una semana de trabajo, mientras intentaba verificar que un script no borrara datos importantes.

El episodio ocurrió durante una prueba diseñada para mejorar la limpieza de archivos temporales, no como resultado de una instrucción explícita para destruir el almacenamiento del usuario. Según el relato publicado por Tom’s Hardware, el problema combinó una revisión adversarial, un cambio automático de modelo por motivos de seguridad y la reutilización de un mismo nombre de variable en dos partes distintas del código.

Una limpieza automatizada terminó en el lugar equivocado

Guillemot utiliza agentes de IA con frecuencia y había detectado un inconveniente práctico en su flujo de trabajo: muchos procesos dejaban grandes cantidades de archivos residuales dentro del directorio /tmp. Para resolverlo, pidió a Claude Fable que escribiera un script capaz de colocar cada agente en su propia carpeta temporal y eliminarla cuando la tarea terminara.

La solicitud incluía una dificultad esencial para cualquier herramienta que borre archivos: el sistema debía distinguir entre datos temporales abandonados y archivos que todavía estuvieran en uso. Fable propuso incorporar lógica para identificar agentes activos y retrasar la eliminación de sus respectivas carpetas, pero Guillemot consideró que el código resultante era demasiado complejo para el objetivo buscado.

Debido a que el script implicaba una eliminación física de datos, el agente inició una revisión adversarial de su propia solución. En términos prácticos, ejecutó una nueva copia de sí mismo para buscar fallos y comprobar que los comandos de limpieza no alcanzaran rutas críticas, una medida que pretendía aumentar la seguridad antes de realizar la prueba.

El sistema de control de Anthropic consideró que la tarea presentaba suficiente riesgo para cambiar automáticamente el modelo utilizado, primero a Opus 5 y después a Opus 4.8, de acuerdo con el relato. Ese cambio resulta relevante porque, según la misma explicación, Fable 5 tenía un mejor desempeño en tareas de programación que Opus 4.8 y quizá habría detectado la contradicción que terminó provocando el borrado. No obstante, la relación entre el cambio de modelo y el fallo debe entenderse como una posibilidad descrita en el relato, no como una causa demostrada de manera independiente.

La variable que convirtió la prueba en un desastre

Durante la verificación, Opus 4.8 comparó correctamente los objetivos del comando de eliminación con /tmp y con el directorio home del usuario. Ambas rutas fueron identificadas como peligrosas, por lo que la prueba pareció confirmar que el script podía reconocer los destinos que nunca debía tocar.

El error apareció en el paso posterior, cuando el sistema intentó limpiar los archivos creados durante la propia prueba. El mismo nombre de variable había sido reutilizado para representar el objetivo examinado y, más adelante, la ubicación que debía eliminarse al terminar, de modo que la operación final heredó una referencia equivocada.

La consecuencia fue que el agente borró el directorio home de Guillemot, en lugar de limitarse a retirar la carpeta temporal asociada con el experimento. El desarrollador logró detener el proceso, aunque no antes de que desaparecieran aproximadamente 700 GB de datos y una semana de trabajo acumulado, según su descripción del incidente.

La ironía se completó cuando el procedimiento sí dejó intacto el directorio /tmp, que era precisamente el espacio que Guillemot quería mantener limpio. El incidente demuestra que una comprobación puede identificar correctamente una ruta peligrosa y aun así fallar si la fase de ejecución utiliza referencias distintas o variables ambiguas.

Recuperación parcial y lecciones para los agentes autónomos

Guillemot pudo recuperar la mayor parte de la información gracias a los rastros que habían quedado distribuidos en sus herramientas de trabajo. Entre ellos se encontraban datos de git, configuraciones de nix y registros de sesión, elementos que permitieron reconstruir una parte sustancial del entorno y del código que el agente había eliminado.

La recuperación, sin embargo, no elimina el riesgo que expone el caso. La disponibilidad de registros auxiliares ayudó a reducir el daño, pero el desarrollador reconoció implícitamente una debilidad adicional: pese a trabajar con varios agentes y datos importantes, no contaba con una copia de seguridad diaria completa.

Otros usuarios mencionaron herramientas como Termaxa y soluciones alternativas para controlar este tipo de procesos, lo que refleja una creciente necesidad de limitar el alcance de los agentes que pueden ejecutar comandos del sistema. Los entornos aislados, los permisos mínimos y las confirmaciones antes de borrar datos pueden reducir la superficie de riesgo, aunque ninguna salvaguarda sustituye una copia de seguridad verificable.

El episodio también plantea una pregunta sobre los mecanismos que cambian automáticamente de modelo cuando una tarea parece peligrosa. La intención del sistema de seguridad era prudente, pero el cambio a un modelo con menor desempeño en programación pudo contribuir a que pasara por alto la colisión de variables. Esa conexión es una explicación plausible del incidente, no un catalizador confirmado de forma independiente.

El desafío de confiar tareas destructivas a la IA

Los agentes autónomos no solo generan texto o sugieren código: también pueden abrir archivos, ejecutar comandos y modificar sistemas cuando reciben las herramientas adecuadas. Esa capacidad resulta útil para automatizar tareas repetitivas, pero hace que un error aparentemente pequeño tenga consecuencias materiales, especialmente cuando el comando afecta rutas completas del sistema.

El caso de Claude ilustra por qué la intención del usuario no basta para evaluar la seguridad de una operación. Guillemot quería limpiar residuos de agentes en /tmp, y el sistema incluso reconoció que el directorio home era un objetivo peligroso; aun así, una variable mal reutilizada llevó la ejecución hacia el destino que el control había intentado proteger.

La revisión adversarial tampoco funcionó como una barrera absoluta, porque la prueba y la limpieza compartieron una referencia que cambió de significado dentro del flujo. Para tareas destructivas, la separación estricta entre variables, la validación independiente de rutas y una autorización final basada en el estado real del sistema pueden ser tan importantes como la capacidad del modelo para razonar sobre el código.

La historia deja una conclusión incómoda para desarrolladores y empresas que incorporan agentes de IA a sus operaciones: automatizar la limpieza no debe significar delegar ciegamente el control de los datos. Claude consiguió liberar 700 GB, pero lo hizo eliminando justamente aquello que debía preservar, mientras los archivos temporales que motivaron el experimento permanecían en su sitio.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados