¡Vaya, Claude ha vuelto a meter la pata!
Esta vez, Claude eliminó todo el directorio principal del proyecto de un desarrollador, borrando 700 GB de archivos. Otra vez el temido «rm -rf».
En resumen, el desarrollador le pidió a la IA que escribiera un script cuyo propósito era garantizar que los archivos no se borraran por error. La IA consideró que la tarea era un poco peligrosa, así que inició una revisión de seguridad. El resultado de la revisión: borró todo el directorio principal.
Guillemot es un usuario intensivo de Agentes de IA. En su trabajo diario de desarrollo, invoca con frecuencia varios agentes de programación con IA para tareas de asistencia. Pero un pequeño problema lo perseguía: estos Agentes nunca limpian después de usarlos, dejando un montón de archivos basura en el directorio /tmp.
Así que tomó una decisión que parecía muy razonable: pedirle a Claude Fable 5 que escribiera un script para crear carpetas de espacio aislado independientes en /tmp para cada Agente, y limpiarlas automáticamente después de completar la tarea. La dificultad principal era no borrar archivos que estuvieran siendo utilizados por otros procesos.
Fable rápidamente propuso una solución, añadiendo lógica para detectar Agentes en ejecución y retrasar la eliminación. Guillemot le echó un vistazo, pensó que el código era demasiado complejo y pidió una simplificación.
Hasta este punto, todo era bastante normal.
El punto de inflexión ocurrió durante la revisión de seguridad.
Dado que el script involucraba operaciones de borrado permanente, Fable inició por sí mismo una «revisión adversaria» (adversarial review), es decir, puso en marcha una nueva instancia del modelo para verificar si el código que había escrito era seguro. Esto activó los mecanismos de seguridad de Anthropic.
Anthropic incorporó en Claude Code un mecanismo de degradación de seguridad: cuando el sistema determina que la tarea actual involucra operaciones sensibles (como ciberseguridad, biotecnología, o en este caso, eliminación de archivos), automáticamente degrada el modelo de una versión de alta capacidad a una versión más conservadora. La intención de este mecanismo era reducir la probabilidad de que el modelo sea «demasiado agresivo» en escenarios de alto riesgo.
En este caso, el sistema de seguridad primero degradó el modelo de Fable 5 a Opus 5, y luego aún más a Opus 4.8.
Opus 4.8 comenzó a ejecutar las pruebas de seguridad. La lógica de la prueba era la siguiente: comparar la ruta de destino del script de eliminación con /tmp y el directorio principal del usuario, para confirmar que el script no dañaría por error estos directorios críticos.
La prueba en sí misma fue superada. Tanto /tmp como el directorio principal fueron correctamente identificados como «objetivos peligrosos, no eliminables».
Pero después de la prueba del código había un paso de limpieza: eliminar los archivos temporales generados durante el proceso de prueba. El desastre ocurrió aquí. Opus 4.8 reutilizó el mismo nombre de variable del paso de prueba para el paso de limpieza. Esta variable había sido asignada con la ruta del directorio principal del usuario durante la fase de prueba, y el paso de limpieza ejecutó la operación de borrado directamente sobre esta variable.
En otras palabras, el modelo acababa de confirmar que «el directorio principal no se puede borrar», y al segundo siguiente, lo borró.
El desarrollador detectó la anomalía e inmediatamente terminó el proceso, pero ya era demasiado tarde. 700 GB de datos habían sido eliminados, y una semana de trabajo se convirtió en nada.
El directorio /tmp que originalmente se iba a limpiar, permaneció intacto.
El mecanismo de degradación de seguridad de los modelos ya ha generado numerosas quejas en la comunidad.
Los problemas principales reportados por los desarrolladores incluyen: la degradación es demasiado sensible, incluso tareas de codificación normales pueden activarla por error; la capacidad del modelo disminuye significativamente después de la degradación, pero la complejidad de la tarea no cambia; la degradación es «pegajosa», una vez activada persiste durante toda la sesión, incluso si las operaciones posteriores son completamente inofensivas.
Algunos desarrolladores incluso han escrito scripts específicos de hook que, al detectar que el modelo ha sido degradado, pausan automáticamente la sesión para evitar que el modelo de menor capacidad continúe ejecutando operaciones de alto riesgo.
El mecanismo de seguridad determina que la tarea es «demasiado peligrosa» y necesita ser manejada por un modelo más débil. Pero un modelo más débil es precisamente más propenso a cometer errores, especialmente en escenarios que requieren un manejo preciso de detalles como el alcance de las variables o las rutas de archivo.
«Errar es humano, pero para hacer un desastre completo, necesitas una computadora.»
Este artículo proviene de la cuenta de WeChat "机器之心" (ID:almosthuman2014), autor: Leng Mao
