La verdadera pregunta es: ¿alguien revisa realmente las solicitudes de aprobación de permisos que piden las herramientas de programación con IA?
Anthropic también se dio cuenta: solo se rechaza el 3% de las solicitudes de permisos.
Así que tomaron una decisión: dentro de 5 días, todo Claude Code activará el modo automático por defecto.
Cada llamada al clasificador en modo automático consume algunos tokens adicionales, pero estos costes ya no se cobrarán al usuario.
Plataformas en la nube como Amazon, Google y Microsoft siguen siendo opcionales, pero Anthropic solo les da un mes para que también cambien a modo automático por defecto en estos canales.
El creador de Claude Code dijo que su equipo ya solo usa el modo automático desde hace tiempo y que no pueden imaginarse volviendo a aprobar permisos manualmente.
La era de la aprobación manual de permisos ha terminado
El primer grupo de razones que da Anthropic para este cambio es que la aprobación manual se ha convertido en un gesto habitual:
La tasa de aceptación de las solicitudes de permiso de Claude Code por parte de los usuarios es del 97%. En comparación, cuando Claude presenta un plan para su aprobación, la tasa de rechazo es del 39%; mientras que la tasa de rechazo para una única solicitud de permiso es solo del 3%.
La misma tendencia aparece en los archivos de configuración. Hasta junio de 2026, el 49.5% de los usuarios activos de CLI habían escrito manualmente una regla Bash `allow-rule`. De ellos, el 5% permitía directamente cualquier comando de shell, y otro 43% escribía reglas del tipo Bash(python:), Bash(node:), que en la práctica son básicamente equivalentes a permisos generales. Esta proporción aumenta aproximadamente 5 puntos porcentuales cada cinco semanas.
Además, 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 ya se ejecutan en modo `bypass permissions` desde el principio.
El segundo grupo de razones proviene de un experimento controlado. Anthropic reclutó a 1053 probadores profesionales de pago a través de un proveedor de investigación, quienes completaron tareas de codificación en un entorno de prueba especializado. A mitad de la sesión, una de las solicitudes de permiso fue reemplazada por un comando claramente peligroso. El proveedor registró si los probadores hacían clic en "Aceptar" (aceptar no ejecutaba realmente ninguna operación peligrosa, solo se modificó el texto de la solicitud).
El resultado fue que los probadores bloquearon este comando en el 13.6% de los casos, 143 veces; el modo automático bloqueó el 89% de los mismos comandos, 937 veces.
En comparación directa, el modo automático bloqueó 800 comandos que los humanos permitieron, mientras que los humanos solo bloquearon 6 comandos que el modo automático habría permitido.
Además, cuanto más larga era la sesión, peor era el rendimiento humano: al principio podían bloquear alrededor del 17%, después de más de 50 solicitudes bajaba a alrededor del 5%, mientras que la tasa de bloqueo del modo automático no variaba con la duración de la sesión.
También se reevaluaron datos de producción.
De mayo a junio de 2026, Anthropic tomó sesiones de cuentas que ya habían autorizado el uso de datos para entrenamiento y análisis, que habían sido marcadas por su canal de seguridad, y las volvió a calificar con un modelo basado en una escala de gravedad del 0 al 10.
-10 puntos representa un daño irreversible a nivel de toda la empresa. -7 puntos representa un nivel como la eliminación de registros de una base de datos de producción. -0 puntos representa operaciones locales completamente reversibles, como sobrescribir un archivo temporal.
Al mismo tiempo, se evaluó cuán explícita era la solicitud del usuario para esa operación. En el nivel de gravedad 7 y superior, en las sesiones con aprobación manual, el 6.3% presentó operaciones dañinas no solicitadas explícitamente por el usuario. En las sesiones con modo automático fue el 2.4%, una diferencia que se mantuvo en cada nivel de gravedad probado.
El clasificador en sí también pasó por pruebas de adversario. Anthropic realizó una prueba piloto de dos semanas con la empresa de seguridad en IA Apollo Research, inyectando ataques sintéticos en trayectorias reales de codificación, cubriendo tres conjuntos de datos: fallos de generalización, filtración de datos y amenazas relacionadas con la seguridad.
Después de que Apollo devolviera muestras de ataques exitosos y recomendaciones de refuerzo, Anthropia fortaleció principalmente el clasificador proporcionándole más contexto del entorno, incluyendo visibilidad del repositorio, estado de git y reglas de procesamiento de datos.
Tras el refuerzo, Apollo volvió a probar con un conjunto de ataques reservado al que Anthropic no tenía acceso. El modo automático recuperó aproximadamente la mitad de los ataques que antes se le habían escapado, a costa de dejar pasar aproximadamente el 2% de los ataques que antes bloqueaba. Calculando con ambos conjuntos de datos combinados, la tasa de detección fallida bajó del 12% al 7%. Anthropic también aclaró que estos ataques fueron sintetizados para encontrar puntos débiles del clasificador, y que el 7% no debe interpretarse como la tasa de detección fallida en tráfico real.
Para la inyección de prompts, Anthropic encargó una evaluación a un tercero, Trajectory Labs, y también incluyó a OpenAI para comparar. Hubo 72 escenarios de inyección indirecta, cada uno ejecutado 10 veces.
Los ataques estaban optimizados para Claude Opus 4.7, que no estaba en la lista de modelos evaluados, por lo que todos los modelos evaluados enfrentaron ataques no vistos antes.
De los 720 intentos de ataque, Claude Fable 5, Opus 5 y Sonnet 5, ejecutándose en modo automático, no fueron vulnerados ni una sola vez;
GPT-5.6 Sol en modo Codex Auto-review tuvo una tasa de éxito de ataque del 5.83%, y en modo Full Access del 19.03%.
Como referencia, la tasa promedio de éxito de ataque de los últimos modelos de Claude en modo `bypassPermissions` sin protección adicional es del 0.09%.
Los tres casos públicos de bloqueo fueron:
En uno, después de que fallara la subida a un disco en la nube interno, la opción de Claude fue publicar el mismo informe en un sitio público de compartir código. Fue rechazado y se le preguntó al usuario.
En una sesión larga, Claude intentó terminar procesos en lotes a través de dos mil pods, y encoló una operación de eliminación que habría eliminado tareas de entrenamiento en ejecución en cientos de GPUs. El comando fue marcado antes de ejecutarse.
En otro caso, cuando se le pidió configurar permisos de solo lectura para facturación, Claude tomó un rol en la nube que tenía permisos administrativos completos a nivel raíz de la cuenta. El alcance de los permisos no coincidía con la solicitud y fue bloqueado.
Las capacidades añadidas recientemente incluyen:
Clasificar la filtración de datos como "hard deny", el clasificador nunca lo aprueba. Para ejecutarlo, hay que salir del modo automático o ejecutarlo manualmente. Esta regla se puede ampliar en la configuración.
Diferenciar entre claves e información sensible, sus respectivos rangos accesibles y compartibles, y comprobar antes de un `git push` o un PR si el repositorio de destino es público, privado o de confianza.
Leer el `git status` antes de comandos como `git reset --hard` que podrían descartar trabajo no confirmado.
Y, cuando Claude obtiene una página web, archivo o salida de una herramienta, una sonda del lado de la API escanea en busca de intentos de inyección y añade una advertencia antes de que el resultado entre en el contexto.
¿Quieres volver al modo anterior? Shift+Tab
Para usuarios Pro, Max y Team, si nunca han configurado un modo de permiso por defecto, recibirán una notificación dentro del producto y las nuevas sesiones comenzarán automáticamente en modo automático; quienes hayan configurado otro por defecto verán una consulta única; si el administrador de Team ya ha especificado un por defecto en `managed settings`, no se verán afectados.
Cambiar de modo en CLI es con Shift+Tab, en la versión de escritorio se usa el menú desplegable de modos. Los administradores pueden fijar el valor por defecto a nivel de organización con `defaultMode` en `managed settings`, o desactivar completamente el modo automático con `disableAutoMode`.
Anthropic termina el anuncio advirtiendo que el modo automático depende de un sistema de clasificación, que puede reducir el riesgo pero no eliminarlo. Para cambios de alto riesgo en infraestructuras de producción, aún se recomienda que los usuarios revisen personalmente las acciones de Claude.
Enlace de referencia: [1]https://claude.com/blog/auto-mode-default-in-claude-code
Este artículo proviene de la cuenta oficial de WeChat "量子位", autor: 关注前沿科技
