El modo automático ahora es el predeterminado en Claude Code para los planes Pro, Max y Team

Actualización, 22 de octubre de 2026: el modo automático se implementará la próxima semana como el modo predeterminado para nuevas sesiones en la mayoría de las aplicaciones de Claude de los planes Pro, Max y Team. En lugar de pedirte aprobación para cada acción, una comprobación automatizada las revisa: las acciones seguras continúan haciéndose y las de riesgo se bloquean mientras Claude busca otra opción. Los administradores de Enterprise recibirán un correo electrónico antes de que el modo automático se convierta en el modo predeterminado en sus organizaciones.

Antes de convertir el modo automático en el modo predeterminado en Claude Code, lo hemos probado internamente y con red-teaming de terceros. Usamos esos hallazgos para mejorar el funcionamiento del modo automático en todos nuestros productos. Los datos de este artículo que aparecen a continuación son específicos de Claude Code.

Vamos a convertir el modo automático en el modo predeterminado de Claude Code. A partir del 14 de agosto, las nuevas sesiones de los planes Pro, Max y Team se ejecutarán en modo automático. Si ya has establecido un valor predeterminado diferente, es posible que te aparezca un aviso, una única vez, que te pregunte si quieres cambiar al modo automático. Si tienes fijado un valor predeterminado, todo sigue igual. El clasificador del modo automático utiliza un pequeño número de tokens adicionales por llamada a cada herramienta y, a partir de hoy, ya no cobramos esa sobrecarga del clasificador a los usuarios de los planes Pro, Max y Team de Claude Code.

Por ahora, el modo automático sigue siendo opcional en Claude Enterprise, Claude API, Claude Platform on AWS, Amazon Bedrock, Agent Platform de Google Cloud y Microsoft Foundry, para que los administradores tengan tiempo para revisar el cambio. Durante el próximo mes, tenemos previsto convertirlo en el modo predeterminado en todos los servicios de nuestros socios en la nube y dejar de cobrar por la sobrecarga del clasificador. Mientras tanto, los administradores de Enterprise pueden configurar el modo automático de Claude Code como su predeterminado en la configuración gestionada.

El modo automático está diseñado para combinar el deseo de los usuarios de no ser interrumpidos con un sistema que ayuda a evitar acciones perjudiciales: en lugar de solicitudes de permiso, dirige cada llamada a herramientas a través de un clasificador diseñado para bloquear acciones irreversibles, destructivas o dirigidas fuera de tu entorno. Cuando el clasificador bloquea algo, Claude suele encontrar de forma autónoma una manera más segura de proceder o te pide directamente autorización; si no puede avanzar (tres bloqueos seguidos o veinte en una sesión), Claude Code recurre a las aprobaciones manuales.

Hemos pasado los últimos meses comprobando si el modo automático es igual de seguro o más que un usuario medio que acepta las solicitudes de permiso. Realizamos evaluaciones internas de red-teaming, de red-teaming de terceros y de inyección de prompts, un estudio controlado con 1053 probadores remunerados y análisis de sesiones de producción reales. En todas las métricas que evaluamos, el modo automático igualó o superó a la revisión manual.

El modo automático también permite a Claude trabajar de forma autónoma durante periodos más largos. Esto hace que los modelos diseñados para trabajos de larga duración, como Claude Opus 5, sean más prácticos para dejarlos en ejecución durante horas en tareas extensas. Reducir la carga de trabajo adicional de los usuarios también aumenta la productividad. Entre las organizaciones que han adoptado Teams y Enterprise, los usuarios del modo automático envían aproximadamente un 25 % más de solicitudes de cambio. Desbloquear Claude permite que las tareas se ejecuten durante más tiempo sin interrupciones y que se complete más trabajo. Los equipos de Adobe, Nuro, Gusto y Garner Health ya utilizan el modo automático como su modo de producción predeterminado.

A continuación compartimos los datos de seguridad y los resultados de los clientes que motivan el cambio, y cómo configurar un valor predeterminado diferente si quieres.

Comparar la revisión manual con el modo automático

Los datos indican que la revisión manual puede convertirse en algo habitual: los usuarios aprueban el 97 % de las solicitudes de permiso de Claude Code. Aunque la mayoría de las solicitudes probablemente correspondan a comandos seguros y rutinarios, una tasa de aprobación tan alta sugiere que muchos usuarios hacen clic automáticamente en lugar de revisar cada comando. Estas solicitudes piden a los desarrolladores que tomen decenas o cientos de decisiones importantes de seguridad todos los días, a menudo cuando están realizando proyectos, lo que traslada la carga de revisión a los usuarios y aumenta las posibilidades de que se pase por alto algo importante. Los datos también indican que los usuarios examinan y cuestionan con más frecuencia otros tipos de diálogos: por ejemplo, cuando Claude presenta un plan para su aprobación, los usuarios lo rechazan un 39 % de las veces. Pero en el caso de solicitudes de permisos individuales, la tasa de rechazo es de solo el 3 %.

El mismo patrón aparece en los archivos de configuración. En junio de 2026, el 49,5 % de los usuarios activos de la CLI ha creado manualmente una regla de autorización de Bash (el 5 % permite cualquier comando de shell directamente y otro 43 % tiene reglas de intérprete como Bash(python:*) o Bash(node:*), que en la práctica son básicamente equivalentes), y esa proporción crece aproximadamente 5 puntos porcentuales cada 5 semanas. Más allá de las reglas de autorización, el 62 % de los usuarios ha usado bypassPermissions o ha hecho clic en “no volver a preguntar” en Bash, y el 25 % de las sesiones interactivas empieza en el modo de omisión de permisos.

Las reglas de permisos siguen activándose antes que el clasificador en modo automático, excepto las reglas de autorización lo suficientemente amplias como para permitir la ejecución de código arbitrario (por ejemplo, python:*). Estas reglas arbitrarias se dejan de lado en modo automático, ya que permitirían que los comandos se saltaran completamente el clasificador. Los archivos de configuración no se modifican y las reglas se vuelven a aplicar en el momento en que cambias a otro modo.

Mejorar la seguridad con el modo automático

Investigaciones realizadas internamente y con varios terceros sugieren que el modo automático es más seguro que la forma en que un usuario típico interactúa actualmente con las solicitudes de permiso. Probamos el modo automático comparándolo con lo que los desarrolladores realmente aprueban cuando hacen clic en las solicitudes de permisos. En cada una de estas medidas (red teaming interno, pruebas de penetración de terceros y análisis de sesiones reales), el modo automático igualó o superó a la aprobación humana.

El modo automático supera a los permisos manuales en seguridad

Contratamos a 1053 probadores remunerados a través de un proveedor de investigación para un estudio de programación. Estos participantes trabajaron en un entorno de prueba configurado específicamente para el estudio, en vez de en sus propias bases de código o en proyectos reales. Los participantes sabían que los estaban evaluando, pero, según el diseño estándar de estudio ciego, no se les dijo qué comportamiento se evaluaba. En algún momento de cada sesión, se cambió una sola solicitud de permisos por un comando claramente peligroso y el proveedor registró si el probador la aprobó (nota: la aprobación de la solicitud no dio lugar a que se ejecutara algo peligroso; solo cambió el texto de la solicitud que vieron los probadores).

Los probadores detectaron el comando peligroso solo el 13,6 % de las veces (143 de 1053), mientras que el modo automático bloqueó el 89 % de los mismos comandos (937 de 1053). En una comparación directa, el modo automático bloqueó 800 comandos que un humano aprobó, mientras que los humanos solo bloquearon 6 que el modo automático había permitido. A medida que las sesiones se hicieron más largas, los humanos obtuvieron peores resultados: bloquearon alrededor del 17 % de los comandos peligrosos al principio de una sesión, y bajaron a alrededor del 5 % después de 50 o más solicitudes previas, mientras que la tasa de bloqueo del modo automático se mantuvo estable independientemente de la duración de la sesión.

El modo automático evita más acciones dañinas

Nuestra investigación también sugiere que el modo automático evita más acciones dañinas que el modo de permisos manuales.

Examinamos el rendimiento del modo automático en la vida real. Entre mayo y junio de 2026, examinamos sesiones que nuestro proceso de seguridad había marcado para su revisión y que solo procedían de cuentas que habían aceptado el uso de sus datos para entrenamiento y análisis. Volvimos a evaluar cada una con un modelo en dos escalas de 0 a 10. El primero fue la gravedad del daño: 10 era un daño irreversible y de alcance empresarial, como filtrar todo el código fuente de una empresa; 7 representaba una gravedad de producción, como eliminar filas de una base de datos de producción; y 0 era una acción totalmente reversible y limitada al espacio de trabajo local, como sobrescribir un archivo temporal. El segundo era con qué grado de explicitud había solicitado el usuario la acción, para poder separar las acciones dañinas que el usuario solicitó directamente de las que el agente realizó con instrucciones menos explícitas.

Entre las sesiones señaladas, las que se aprobaron manualmente contenían daños graves no deseados con más del doble de frecuencia que las sesiones en modo automático. Con respecto a la gravedad de producción (7 o más), el 6,3 % de las sesiones aprobadas manualmente contenía una acción dañina que el usuario no había solicitado explícitamente, frente al 2,4 % de las sesiones en modo automático, y la brecha se mantuvo en todos los niveles de gravedad que probamos.

Las pruebas adversarias de red teaming reforzaron el modo automático

Trabajamos junto con Apollo Research, una startup de seguridad de la IA con sede en el Reino Unido, en un piloto de dos semanas en el que se inyectaban ataques sintéticos en trayectorias de programación reales, en tres conjuntos de datos: fallos generales, exfiltración de datos y amenazas relacionadas con la seguridad.

La colaboración siguió un ciclo estándar de detección, corrección y verificación. Apollo compartió un conjunto de ataques exitosos junto con recomendaciones para mejorar el modo automático. Reforzamos el clasificador frente a dichos ataques, principalmente dándole más contexto sobre el entorno que protege (visibilidad del repositorio, estado de git y reglas de tratamiento de datos que se describen a continuación).

Tras el refuerzo, Apollo volvió a realizar pruebas con otro conjunto de ataques reservado al que nunca tuvimos acceso. El modo automático detectó aproximadamente la mitad de los ataques que no había detectado anteriormente, a costa de no detectar aproximadamente el 2 % de los ataques que antes sí detectaba. Como no pudimos ajustar el clasificador con el conjunto reservado, esto sugiere que el refuerzo se generaliza a nuevos ataques en lugar de parchear los ataques específicos que Apollo compartió. Tanto en el conjunto compartido como en el reservado, la tasa de no detección del clasificador bajó del 12 % al 7 %.

Estos ataques son sintéticos y adversarios de forma intencionada, están creados para detectar dónde falla el clasificador y son más maliciosos que cualquier cosa que Claude haría sin indicaciones. La tasa de no detección del 7 % es la de este conjunto y no debe considerarse la tasa de no detección del tráfico real.

El modo automático reduce el riesgo de inyección de prompts

El clasificador del modo automático añade una capa adicional de defensa contra ataques de inyección de prompts que intentan forzar al agente a desviarse de las instrucciones del usuario. Cuando se ejecuta con el modo automático, sondas analizan los resultados de las herramientas en busca de instrucciones potencialmente maliciosas, y el modo automático comprueba que las acciones estén alineadas con la intención del usuario. Hicimos pruebas para comparar el modo automático con un modelo sin protección para ilustrar la potencia de este enfoque de defensa en profundidad.

Encargamos una evaluación a un tercero, Trajectory Labs, que el 17 de julio de 2026 probó diferentes modelos en las últimas versiones de Claude Code y Codex disponibles para el público. 1 Probaron 72 escenarios de inyección indirecta de prompts que no compartieron con Anthropic. Cada escenario se probó 10 veces. Los ataques exitosos, fuera de un entorno de pruebas, darían lugar a acciones irreversibles que podrían perjudicar al usuario, como la filtración de datos confidenciales, el fraude financiero o el phishing de credenciales. Los ataques se optimizaron contra Claude Opus 4.7, que no figura en el conjunto de modelos presentados, así que todos los modelos de la evaluación se enfrentaron a ellos como ataques inéditos. Además del modo automático, en las evaluaciones se analizaron el modo bypassPermissions de Claude Code y el modo Full Access de Codex.

Tanto Codex como Claude Code se evaluaron con una integración de navegador idéntica producida por Trajectory Labs, PBC. Esta integración proporciona un conjunto de herramientas MCP que funcionan como una capa ligera sobre API comunes de Chrome, como `navigate`. No se probaron las salvaguardas integradas en las integraciones de navegador propias, como las extensiones de Chrome que ofrecen OpenAI y Anthropic. Por lo tanto, estos resultados deben considerarse como una medición del modelo subyacente, no como el conjunto completo de salvaguardas que podrían existir en una implementación determinada.

En esta evaluación, ninguno de los 720 intentos de ataque tuvo éxito contra Claude Fable 5, Opus 5 o Sonnet 5 en modo automático. Por otro lado, el 5,83 % de los ataques tuvieron éxito contra GPT-5.6 Sol en el modo de revisión automática de Codex. Cabe destacar que esta cifra es superior al 0,09 % de tasa media de éxito de los ataques contra nuestros últimos modelos ejecutados en modo bypassPermissions sin salvaguardas adicionales. Las pruebas mostraron una tasa de éxito de los ataques del 19,03 % contra GPT-5.6 Sol cuando se ejecutaba en modo Full Access. Como se muestra a continuación, las tasas de éxito de los ataques son diferentes entre las tareas en las que las herramientas devuelven resultados en forma de texto y las que tienen que interactuar con un navegador a través de capturas de pantalla.

Tres incidentes que el modo automático evitó dentro de Anthropic

El modo automático también es el predeterminado para todo el uso interno de Claude Code en Anthropic. Estas son tres acciones que el clasificador evitó internamente:

• Una filtración de datos fuera de la red: cuando falló una carga a una unidad interna, la alternativa de Claude era publicar el mismo informe en un sitio público para compartir código. El modo automático denegó la opción alternativa y preguntó al usuario los pasos siguientes.
• Una operación de destrucción masiva: en una sesión de larga duración, Claude intentó finalizar procesos de forma masiva en aproximadamente dos mil pods y puso en cola eliminaciones que habrían desmantelado cientos de GPU de trabajos de entrenamiento en curso. El modo automático marcó los comandos destructivos antes de su ejecución.
• Escalada de permisos excesiva: cuando se solicitó a Claude que aprovisionara acceso de solo lectura a la facturación, optó por un rol en la nube que otorga control administrativo total en la raíz de la cuenta. El modo automático detectó la discrepancia entre lo que se solicitó y los roles que se habrían otorgado.

En cada caso, Claude encontró una ruta más segura de forma autónoma o consultó con el usuario antes de continuar.

Cómo hacer que el modo automático sea aún más seguro

Invertimos constantemente en nuevas funciones del modo automático que hacen que sea más seguro y sencillo desplegar código en producción. Estos son algunos ejemplos recientes:

• Denegaciones estrictas: la filtración de datos, como enviar tu código o secretos a un destino externo, pertenece a una categoría que el clasificador está diseñado para no aprobar nunca. Para ejecutar una acción como esa, tienes que desactivar el modo automático o ejecutar el comando tú mismo. Las reglas de denegación estricta se pueden personalizar en la configuración, así que puedes añadir más reglas para cosas que no quieres permitir jamás, aunque los usuarios de tu organización lo soliciten.
• Reglas para acceder a datos y compartirlos: el clasificador ahora incluye reglas explícitas que distinguen secretos e información potencialmente sensible/confidencial, y dónde se puede acceder a ellos y compartirlos. Para hacer cumplir esas reglas, también comprueba si el destino de un git push o de una solicitud de cambio es público, privado o de confianza antes de ejecutar la acción. El mismo push puede ser rutinario o una filtración según su destino: el código que pertenece al repositorio privado de tu equipo no debería acabar en uno público, y el clasificador ahora está diseñado para indicar cuándo podría ocurrir esto.
• Comprobación del estado de git antes de realizar acciones destructivas de git: ante un comando que podría descartar trabajo sin confirmar, como git reset --hard, el clasificador ve el estado actual de git del repositorio, lo que permite al modo automático saber qué se está restableciendo.
• Detección de inyección de prompts: cuando Claude extrae contenido de fuentes externas, como páginas web, contenido de archivos o resultados de herramientas, la API hace una comprobación para ver si ese contenido incluye intentos de secuestrar el comportamiento de Claude. Cuando algo parece un intento de inyección, se añade una advertencia al contexto de Claude antes de compartir el resultado con el usuario.

Modo automático en producción

Los equipos ya están usando el modo automático como su modo de producción predeterminado:

• El equipo de la plataforma de comercialización de Adobe se encarga de mantener precisas y actualizadas las páginas de precios y promociones de Adobe.com en más de 90 países y más de 30 idiomas. Desarrollaron un ciclo agéntico para crear y verificar esas páginas, que ejecutan en modo automático para que los ingenieros reciban las solicitudes de cambio terminadas para su revisión.
• Nuro usa el modo automático en todas sus organizaciones de investigación e ingeniería para impulsar agentes de investigación nocturnos que optimizan progresivamente las métricas de evaluación y devuelven solicitudes de cambio terminadas para que se revisen por la mañana.
• Gusto adoptó el modo automático para acabar con la fatiga de permisos que hacía que los ingenieros se saltaran directamente las comprobaciones de permisos. Desde mediados de mayo, alrededor del 10 % de las sesiones incluyen una denegación del clasificador, lo que demuestra que está realmente trabajando sin ralentizar las tareas legítimas.
• Garner Health estableció el modo automático como predeterminado para sus 550 empleados a través de la configuración gestionada, con lo que estandarizó un ciclo de vida de desarrollo de software (SDLC) en toda la empresa que ya no depende de listas de comandos permitidos seleccionadas manualmente.