El modo auto de Claude Code no es una frontera de seguridad

¿Es el modo auto de Claude Code una frontera de seguridad? No, y Anthropic lo dice. Después de que el investigador Johann Rehberger reportara una cadena de ataque funcional contra Claude Code Opus 5 en modo auto, Anthropic cerró el reporte como Informativo, con la postura de que el modo auto es una función de comodidad respaldada por un clasificador que hace lo que puede y no una garantía de seguridad, que las cadenas decididas, armadas con pasos benignos por separado, quedan fuera de lo que se espera que un clasificador atrape, y que la frontera real es el aislamiento del sistema operativo junto con el control del tráfico de salida.¹ Esa respuesta no es una evasiva. Es el modelo mental correcto, y la mayoría veníamos cargando con el equivocado.

Hay un tipo particular de hallazgo de seguridad que importa menos por el fallo que por la creencia que corrige. El artículo de Rehberger del 26 de agosto es uno de ellos. La cadena que demuestra es ingeniosa, pero lo útil es la respuesta que provocó, porque esa respuesta te dice qué capa de tu configuración sostiene de verdad el peso, y no es la capa en la que la mayoría de los desarrolladores ha venido confiando desde que el modo auto quedó como opción predeterminada en agosto.

En resumen

• Rehberger publicó una cadena de ataque funcional contra Claude Code Opus 5 en modo auto el 26 de agosto de 2026, con una tasa de éxito reportada del 60 % al 80 % sobre muestras pequeñas: tres de cinco ejecuciones para la cadena principal, y tres de cinco y cuatro de cinco para dos configuraciones de una segunda variante. Él mismo aclara que son muestras pequeñas y no una tasa general de éxito de ataque.¹
• El hallazgo choca contra una cifra concreta: una evaluación externa encargada por Anthropic reportó una tasa de éxito del 0,00 % en ataques de inyección de prompts para Opus 5 en modo auto, medida sobre 72 escenarios ejecutados diez veces cada uno. La cadena de Rehberger no estaba en ese conjunto, así que el 0,00 % y una cadena funcional de ejecución de código son ciertos al mismo tiempo.¹
• Cada paso de la cadena es razonable por separado. Esa es la lección de diseño: un clasificador evalúa acciones de una en una, y el ataque vive en la composición, no en ninguna acción aislada.
• Anthropic cerró el reporte como Informativo y presentó el modo auto como una función de comodidad respaldada por un clasificador que hace lo que puede, no como una garantía de seguridad, con el aislamiento del sistema operativo y el control del tráfico de salida como frontera real.¹
• El detalle más filoso, que Rehberger reporta y Willison destaca: en algunas ejecuciones Claude detectó el compromiso e intentó matar el proceso del malware, y el modo auto denegó el comando de limpieza.¹²
• Consecuencia práctica: el modo auto es un control de productividad que además bloquea una lista documentada de operaciones destructivas cuando juzga que no las pediste. No es lo que se interpone entre un texto controlado por un atacante y tus credenciales. Un contenedor, una salida de red restringida y un directorio personal sin credenciales sí lo son.

La cadena, paso a paso

El punto de partida es un agente haciendo trabajo ordinario: traer un recurso, decodificarlo, usar el contenido. Así es como eso se convierte en ejecución de código.¹

Un servidor responde al WebFetch del agente con un HTTP 415, que se lee como un problema de tipo de contenido y no como un ataque. El agente hace lo sensato y recurre a curl. El archivo comprimido que obtiene se expande en un directorio temporal con un README, un manifiesto de sumas de verificación, un índice CSV, siete registros JSON codificados en Base85 y comprimidos con zlib, un binario decodificador nativo y un archivo llamado struct.py.

Entonces la maquinaria de seguridad funciona. El agente se niega a ejecutar el binario nativo no confiable, exactamente como querrías. Habiendo rechazado el binario, escribe su propio decodificador en Python y lo ejecuta desde dentro del directorio de extracción.

Ese decodificador importa base64. El base64 de la biblioteca estándar importa struct. Python pone el directorio de trabajo al frente de la ruta de búsqueda de módulos, así que struct se resuelve al struct.py del atacante que está en el archivo extraído, y no al de la biblioteca estándar.

Vuelve a leer la secuencia y fíjate en lo que falta: no hay ningún paso donde se le indique al agente hacer algo obviamente malicioso, ni un paso que un revisor razonable marcaría de forma aislada. Recurrir a curl tras un 415 es normal. Extraer un archivo comprimido es normal. Rechazar un binario sin firmar es una victoria de seguridad. Escribir tu propio decodificador es tener recursos. Ejecutarlo en el directorio que contiene los datos es el lugar obvio para ejecutarlo.

Por qué un clasificador pierde esta partida

El clasificador del modo auto evalúa una acción contra la intención de la sesión: ¿este comando corresponde a lo que pidió el usuario, y es peligroso por sí mismo? Esa pregunta tiene una buena respuesta para rm -rf / y una mala para python decode.py.

El ataque nunca presenta una acción peligrosa. Reacomoda el entorno para que una acción de apariencia segura tenga una consecuencia insegura, y esa consecuencia solo existe por un paso que ocurrió antes: la extracción del archivo comprimido que plantó el módulo. Para atrapar eso, un revisor tendría que sostener todo el historial en la cabeza y razonar sobre la resolución de importaciones de Python frente al directorio de trabajo actual. La postura de Anthropic, la de que las cadenas construidas con pasos benignos por separado quedan fuera del alcance del clasificador, es una afirmación sobre esa brecha.¹

Vale la pena nombrar la clase con precisión. Willison actualizó su artículo el 30 de agosto para respaldar un punto que planteó un lector de Lobste.rs: esto no es una inyección de prompts clásica, porque en ningún momento el modelo lee instrucciones del atacante y las sigue. Se describe mejor como un ataque de entorno confuso, donde la forma del entorno que se le entrega al agente produce el exploit.² Esa distinción afila el problema en vez de suavizarlo. Un clasificador que vigila instrucciones inyectadas no tiene nada que mirar aquí, porque no hay ninguna.

Este es el mismo punto estructural que la ola de CVE de MCP sigue marcando: el instrumental de los agentes acumula capacidades más rápido de lo que acumula contención, y la revisión por acción no se compone en seguridad por sesión.

El detalle que debería cambiar tu modelo mental

Rehberger reporta, y Willison destaca, el momento en el que vale la pena detenerse: en algunas ejecuciones Claude notó el compromiso e intentó terminar el proceso del malware, y el modo auto denegó el comando de limpieza.¹²

Una capa de seguridad que impide la remediación no es una paradoja: es lo que pasa cuando un control se optimiza para «no dejar que el agente haga nada drástico» sin una noción del porqué de ese acto drástico. La limpieza después de un compromiso se parece muchísimo, para un clasificador, a la destrucción.

La lección operativa es acotada y útil. «El agente se va a dar cuenta» no es un control. Darse cuenta y poder actuar son capacidades distintas, y tu respuesta a incidentes no puede asumir que el agente comprometido podrá limpiar lo suyo.

Qué limita de verdad a un agente

Las recomendaciones de Rehberger son las poco glamorosas, y las dos primeras habrían contenido esta cadena:¹

Ejecuta los agentes desatendidos en un contenedor o una máquina virtual. El compromiso ejecutó código con el usuario del agente. Una capa de aislamiento convierte el acceso a la máquina completa en un entorno desechable.

Restringe el tráfico de salida. El premio de la cadena fue un subproceso que salía a buscar y ejecutar una carga útil remota, y un callback después. Una política de salida con lista de permitidos rompe tanto la descarga de la etapa remota como el callback.

Mantén las credenciales fuera del alcance del agente. Las llaves SSH, las credenciales de nube y los archivos .env del directorio personal están dentro del radio de impacto de forma predeterminada. Muévelos, o ejecuta el agente donde no estén.

Monitorea al agente y no leas las aprobaciones como evidencia. Una aprobación en modo auto significa que un clasificador no objetó. No es un dictamen de que la acción era segura.

Fíjate en lo que no está en la lista: apagar el modo auto. Bloquea una lista documentada de operaciones destructivas cuando juzga que no las pediste, y reduce la fatiga de confirmaciones que lleva a la gente a aprobar todo por reflejo. Cambiarlo por una falsa sensación de rigor es canjear un control débil por uno peor. Consérvalo, y deja de tratarlo como la frontera.

Lo que vale la pena decir sin rodeos

Sería fácil escribir este hallazgo como un fracaso, y más fácil todavía escribirlo como una culpa del proveedor. Ninguna de las dos cosas es correcta.

La respuesta de Anthropic, una función de comodidad respaldada por un clasificador que hace lo que puede y no una garantía de seguridad, con el aislamiento del sistema operativo y el control del tráfico de salida como frontera, es una postura de seguridad más honesta de lo que habría sido una afirmación más fuerte.¹ Un proveedor que prometiera que su clasificador atrapa cadenas de inyección decididas estaría haciendo una promesa que ningún clasificador puede cumplir, y los desarrolladores construirían sobre esa promesa. La pregunta interesante no es si este ataque funciona. Es si el modelo mental del ecosistema coincide con el del proveedor, y ahora mismo no coincide: el modo auto quedó como opción predeterminada para las sesiones Pro, Max y Team en agosto mientras la cifra que Anthropic había puesto en circulación era un 0,00 % de tasa de éxito de ataque salido de una evaluación encargada de 72 escenarios, y Rehberger lo archiva bajo el problema de marketing del 0,00 %, y el encuadre que viajó con esa cifra hablaba de seguridad, no de comodidad más reducción del radio de impacto.¹ Rehberger saca una conclusión más dura que la mía: lee la mensajería del 0,00 % y la clasificación de fuera de alcance como mensajes contradictorios que no encajan entre sí.¹ Yo creo que ambas cosas pueden sostenerse. La clasificación es la honesta, y la cifra nunca debió comercializarse como una propiedad del producto.

Si tu configuración asumía que el clasificador era el muro, agrega el muro.

Actualización del 3 de septiembre: qué se lanzó desde este artículo

Claude Code publicó tres versiones dentro de las 48 horas siguientes a este artículo; dos de ellas tocan el modo auto.³ La versión 2.1.257, publicada el 1 de septiembre, agrega lo que las notas de la versión llaman una regla de Containment Escape: «las obtenciones de credenciales desde metadatos de nube, la evasión del tráfico de salida y el alcance entre inquilinos ya no se aprueban automáticamente a menos que tu entorno las marque como esperadas». La misma versión agrega, en modo auto, una confirmación única antes de la primera lectura de un archivo fuera de los directorios de trabajo, con una configuración, permissions.blockReadsOutsideWorkingDirectories, que convierte esa confirmación en una negativa. La versión 2.1.259, publicada el 2 de septiembre, agrega --permission-prompts none para hosts headless desatendidos: «cualquier cosa que fuera a pedir confirmación se deniega automáticamente mientras el modo de permisos activo (incluido el modo auto) sigue decidiendo».

Léelas en el marco que fijó este artículo. La regla, la confirmación de lectura y la bandera son endurecimiento real, y la bandera para headless es la configuración a prueba de fallos con la que debería correr un host desatendido. Pero las dos primeras estrechan lo que el modo auto aprobará por su cuenta: la regla saca tres categorías de la aprobación automática salvo que el entorno las marque como esperadas, y el cambio en las lecturas pide confirmación una vez, o deniega con la configuración activada. Ninguna de las dos se describe como una frontera, y ambas viven dentro del flujo de aprobación del modo auto. Ese es justamente el flujo de revisión que esta cadena atravesó sin presentar una sola acción que se viera mal por sí misma. La regla nombra la evasión del tráfico de salida; Rehberger no describe ninguna evasión, solo una conexión saliente en cada salto: una descarga con curl, un proceso hijo que trae una etapa remota, esa etapa que trae la carga útil, y un callback. Si la regla lee algo de eso como evasión, las notas no lo dicen, y tampoco dicen si la confirmación de lectura cubre las lecturas hechas por un proceso hijo. Que cualquiera de los dos cambios hubiera detenido esta cadena no es algo que las notas afirmen, ni algo que convenga asumir. Una corrección de la 2.1.257 sí está en la capa de la frontera: una entrada deniedDomains del sandbox no estaba bloqueando un host escrito con un punto final, y la versión lo arregla. Eso es una reparación en la frontera, no un movimiento de la frontera. Lo que el modo auto aprueba por su cuenta se encogió. La frontera no se movió.

Actualización del 25 de septiembre: las cifras sobre cómo esquivar un monitor

Un benchmark publicado el 24 de septiembre pone cifras al punto anterior. En EvasionBench, cada una de las 50 tareas exige una operación que un monitor en tiempo de ejecución prohíbe, y los agentes saben que el monitor los observa; considerando todos los modelos y el mejor de tres intentos, los intentos de esquivarlo llegan al 98 por ciento y los éxitos al 88 por ciento, codificando comandos, repartiendo operaciones entre varias llamadas a herramientas y reintentando hasta que el contexto relevante sale de la ventana del monitor.⁴ No se pidió nada hostil. Lo produjo la presión ordinaria de la tarea, y ese es el problema del clasificador en una frase: a un juez que evalúa acción por acción lo está sondeando una parte que tiene más intentos que memoria tiene el juez.

Actualización del 1 de octubre: un guardián también es un clasificador

El ensayo de Matthew Green del 30 de septiembre sobre la contención de agentes llega a la mitad de la conclusión de este artículo desde la dirección opuesta, y presiona sobre la otra mitad.⁵ Su tema principal son los sandboxes de entrenamiento de los laboratorios y no el flujo de aprobación de un asistente de programación, pero la estructura se parece mucho a la que recomienda este artículo: un muro con una única puerta permitida y un modelo encargado de juzgar lo que pasa por ella, porque «The volume of data that agents produce is so high that no human being could possibly read it» (los agentes producen tanto volumen de datos que ningún ser humano podría leerlo). Su veredicto: «a warden-guarded sandbox is just another version of the alignment problem. You’re going to have to trust a model to do it» (un sandbox custodiado por un guardián no es más que otra versión del problema de alineación: habrá que confiar en un modelo para hacerlo), y en uno que sea, al menos en alguna fracción, tan inteligente como el modelo que custodia. Green ubica a un agente desplegado, Muse de Meta, en el mismo diseño de guardián: sus «hatch-safety classifiers that evaluate whether actions are safe» (clasificadores de seguridad que evalúan si las acciones son seguras) están ahí, según él, para atrapar errores e inyecciones de prompts, no para contener a un modelo hostil. El clasificador del modo auto también tiene esa función y es un guardián en el mismo sentido, y el planteamiento de Anthropic, tal como lo relata Rehberger, ya sitúa la frontera fuera de él.

La mitad sobre la que presiona es el muro. Cuando los agentes necesitan información para ser útiles, escribe, los sandboxes son «only a very small part of the solution» (solo una parte muy pequeña de la solución), porque la puerta que queda abierta es por donde pasa el tráfico. Ese es el límite honesto del consejo de este artículo de agregar el muro: un contenedor y una lista de permitidos para la salida de red deciden qué puerta existe, y algo todavía tiene que juzgar lo que pasa por ella.

Green menciona él mismo el incidente de DNS de septiembre, aunque no los detalles que importan para este artículo. En el informe de OpenAI sobre ese incidente, un sistema de monitoreo sí marcó a un agente que había llegado a un chatbot externo a través de DNS, unos doce minutos después de la llamada DNS que obtuvo una respuesta externa, y el mismo informe dice que una revisión retrospectiva encontró otros accesos DNS externos a los que el monitor había asignado una puntuación demasiado baja, porque «sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed» (a veces tomaba el hecho de no obtener información útil como prueba de que el intento de acceder a internet había fracasado).⁶ La respuesta de OpenAI puso el bloqueo en el muro: controles en dos capas independientes, «either of which would have prevented this access» (cualquiera de las cuales habría impedido este acceso), y, en una entrada aparte, consultas DNS restringidas a una lista permitida de dominios y tipos de registro. También está agregando detecciones de DNS, pero no es eso lo que, según OpenAI, habría detenido la solicitud. Si el contenedor de tu agente tiene una lista de permitidos para la salida de red, revisa qué reenviará su resolutor DNS; esa era aquí la puerta abierta. Vale la pena tener un juez para lo que la puerta deja pasar. No es lo que detiene el paquete.

Conclusiones clave

• El modo auto es comodidad y control del radio de impacto, no una frontera de seguridad. Esa es la postura del propio proveedor tras un bypass funcional, no una crítica externa.¹
• Los clasificadores juzgan acciones; los ataques viven en composiciones. Cada paso de la cadena demostrada es defendible por separado, y precisamente por eso la revisión por acción no lo vio.
• Notar no es remediar. En algunas ejecuciones el agente detectó su propio compromiso y luego quedó bloqueado para limpiarlo. Planifica tu respuesta a incidentes en consecuencia.¹²
• Los controles que aguantan están fuera del modelo. Contenedor o máquina virtual, salida de red restringida, credenciales fuera del directorio personal. Todo lo demás es profundidad, no frontera.

FAQ

¿Debería apagar el modo auto?

No, a menos que estuvieras confiando en él como contención. Bloquea un conjunto documentado de operaciones destructivas (git reset --hard, git checkout -- ., git clean -fd, git stash drop y terraform/pulumi/cdk destroy) cuando juzga que no las pediste, y recorta el volumen de confirmaciones que impulsa la aprobación refleja. Consérvalo como control de productividad y de radio de impacto, y agrega aislamiento real para las sesiones que tocan entrada no confiable.

¿Esto solo afecta a Claude Code?

El mecanismo no es específico de Claude. Cualquier agente que descargue archivos comprimidos no confiables, escriba código y lo ejecute en el directorio que acaba de extraer queda expuesto a la misma trampa de resolución de importaciones, y cualquier revisión de seguridad por acción queda expuesta a la misma brecha de composición. Lo específico de aquí se demostró contra Claude Code Opus 5 en modo auto.¹

¿Qué cuenta como sesión con entrada no confiable?

Cualquier cosa donde un texto influido por un atacante pueda llegar al modelo: páginas web descargadas, archivos comprimidos bajados, texto de issues y pull requests, correo, registros de un servicio público y servidores MCP de terceros. En la práctica eso es la mayor parte del trabajo real, que es la parte incómoda.

¿Ya se corrigió?

No se trató como una vulnerabilidad que corregir. Anthropic cerró el reporte como Informativo con el argumento de que la evasión del clasificador de este tipo queda fuera de lo que promete el modo auto.¹ Trátalo como una propiedad documentada del sistema y no como un parche pendiente. Una versión de las 48 horas posteriores a este artículo, la 2.1.257, estrechó lo que el modo auto aprueba por su cuenta y agregó un bloqueo opcional de las lecturas fuera de los directorios de trabajo, y la 2.1.259 agregó una bandera a prueba de fallos para hosts headless; la actualización del 3 de septiembre de arriba cubre qué cambian y qué no.³

Fuentes