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. {.answer-block}

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ó.

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