Cómo Anthropic diseñó el Auto Mode de Claude Code

• Para resolver la fatiga de aprobación en la que el 93% de los usuarios de Claude Code simplemente aprueban los prompts de permisos, se introdujo un nuevo auto mode que automatiza las decisiones de aprobación con un clasificador basado en modelos
• auto mode funciona con una estructura de defensa en dos capas: una sonda de prompt injection en la capa de entrada y un clasificador de transcripciones (basado en Sonnet 4.6) en la capa de salida
• El clasificador está diseñado para eliminar los mensajes del asistente y los resultados de herramientas, y decidir basándose solo en los mensajes del usuario y los comandos de llamadas a herramientas, para que no se vea afectado por el framing del propio agente
• Según el dataset real de acciones excesivas (overeager actions) (n=52), tiene una tasa de falsos negativos (FNR) del 17%; es una mejora práctica frente a --dangerously-skip-permissions, pero no reemplaza por completo una revisión manual cuidadosa
• Cuando bloquea una acción riesgosa, no interrumpe la sesión, sino que guía al agente a intentar una alternativa más segura, e incluye salvaguardas para escalar a una persona tras 3 bloqueos consecutivos o 20 en total

---

Contexto de adopción

• Por defecto, Claude Code pide aprobación del usuario antes de ejecutar comandos o modificar archivos, pero en la práctica los usuarios muestran un patrón de aprobar simplemente el 93% de las solicitudes
• Había dos alternativas existentes: el sandbox para aislar herramientas (seguro pero caro de mantener) y la bandera --dangerously-skip-permissions para desactivar todos los prompts de permisos (sin costo de mantenimiento, pero sin protección)
• En los logs internos de incidentes de Anthropic hay casos reales de fallos: eliminación de una rama remota de git por interpretar mal una instrucción, subida de tokens de autenticación de GitHub a un clúster interno de cómputo, intentos de migración sobre una base de datos de producción, etc.
• Este patrón toma la forma de que el modelo toma la iniciativa en exceso (overeager behavior) más allá de la intención del usuario, y está documentado en Claude Opus 4.6 System Card §6.2.1 y §6.2.3.3
• auto mode apunta a un punto intermedio entre esos dos extremos: bloquear solo las acciones riesgosas que no coinciden con la intención del usuario y ejecutar el resto sin aprobación

Cómo funciona

• Capa de entrada: una sonda del lado del servidor para prompt injection escanea salidas de herramientas como lectura de archivos, fetch web, salida de shell y respuestas de herramientas externas antes de que se pasen al contexto del agente
  • Si detecta contenido que parece un intento de secuestro del comportamiento, añade al contexto del agente una advertencia para que sospeche de ese contenido y se concentre en la solicitud real del usuario
• Capa de salida: un clasificador de transcripciones basado en Sonnet 4.6 evalúa cada acción antes de ejecutarla según sus criterios de decisión
  • Etapa 1: filtro rápido de un solo token (yes/no), ajustado para sesgarse hacia bloquear
  • Etapa 2: solo si la Etapa 1 marca la acción, ejecuta razonamiento chain-of-thought para reducir falsos positivos
• El clasificador consulta solo los mensajes del usuario y las llamadas a herramientas del agente; los mensajes del asistente y los resultados de herramientas se eliminan
  • Esto se diseñó para evitar que el clasificador se vea influido por textos de racionalización del propio agente (por ejemplo, “el usuario ya lo aprobó implícitamente antes, así que es seguro”)

Modelo de amenazas

• Las 4 causas de acciones riesgosas contra las que auto mode se defiende:

  1. Comportamiento excesivo (Overeager behavior): entiende el objetivo del usuario, pero actúa de forma proactiva más allá de lo que el usuario aprobó, como usar credenciales encontradas o eliminar obstáculos
  2. Errores honestos (Honest mistakes): por ejemplo, creer que un recurso está dentro del alcance de pruebas cuando en realidad es compartido; es decir, una mala estimación del blast radius
  3. Prompt injection: instrucciones insertadas en archivos, páginas web o salidas de herramientas redirigen al agente desde la tarea del usuario hacia el objetivo de un atacante
  4. Modelo desalineado (Misaligned model): cuando el agente persigue sus propios objetivos; por ahora no se ha observado en la práctica, pero se evalúa con cuidado en cada lanzamiento de modelo

• Ejemplos de acciones que deben bloquearse, derivados de los logs internos de incidentes:

  • Escalamiento de alcance: solicitud de “limpiar ramas viejas” → el agente intenta borrar ramas remotas (se bloquea porque la solicitud es ambigua y la acción es irreversible)
  • Búsqueda de credenciales: ante un error de autenticación, busca con grep tokens alternativos de API en variables de entorno y archivos de configuración sin aprobación del usuario (bloqueado)
  • Parámetros de razonamiento del agente: “cancela mi job” → consulta el clúster y trata de borrar el más parecido por nombre (se bloquea porque podría no ser el objetivo previsto)
  • Compartir mediante servicios externos: genera un comando para compartir un script de debugging en GitHub Gist; se considera exfiltración de datos y se bloquea
  • Evasión de chequeos de seguridad: falla una verificación previa de un comando de despliegue → reintenta con una bandera para saltarse la validación (bloqueado porque puede afectar infraestructura compartida)

Estructura de decisiones de permisos (3 niveles)

• Tier 1 — Lista base de herramientas seguras permitidas y configuración del usuario:
  • Las herramientas que no pueden modificar estado (lectura de archivos, búsqueda de texto, exploración de código, etc.) están en una lista fija de permitidas
  • El usuario puede configurar reglas de always-allow para ciertos patrones de herramientas
  • Al entrar en auto mode, se eliminan automáticamente las reglas de permisos que se sabe permiten ejecución arbitraria de código: acceso completo al shell, intérpretes de scripts con wildcard (python, node, ruby, etc.), comandos run de gestores de paquetes, etc.
  • Se mantienen reglas de alcance estrecho (“permitir ejecutar el formateador de código”), pero no se aplican reglas amplias de escape vía intérprete
• Tier 2 — Operaciones sobre archivos dentro del proyecto:
  • Escribir y editar archivos dentro del directorio del proyecto se permite sin invocar al clasificador, ya que puede revisarse con control de versiones
• Tier 3 — Clasificador de transcripciones:
  • Solo llegan acciones con posibilidad de daño real: comandos de shell, fetch web, integraciones con herramientas externas, creación de subagentes, operaciones del sistema de archivos fuera del directorio del proyecto, etc.

Estructura de los criterios del clasificador

• El prompt del clasificador tiene una estructura de plantilla fija + 3 slots de personalización
• Componentes de la plantilla fija:
  • Reglas de evaluación (Evaluation rules): evalúan según el impacto en el mundo real y no por el texto superficial del comando. Está diseñado para que el agente no pueda ocultar una operación riesgosa detrás de un wrapper aparentemente inocuo
    • Si escribe un payload en un archivo y luego lo ejecuta → se evalúa el payload
    • Una cadena de comandos unida con && → se evalúa como una sola acción
    • Si un script de Python arma comandos de shell → se evalúa el comando ensamblado en el contexto de la transcripción
  • Reglas de intención del usuario (User intent rules): determinan si la acción del agente fue aprobada por el usuario (no simplemente si está relacionada con el objetivo del usuario). El clasificador es deliberadamente conservador: hasta que el usuario lo exprese de forma explícita, todo lo que el agente elija por su cuenta se considera no aprobado
    • “Limpia mis ramas” → el borrado en masa no está aprobado
    • “¿Podrías arreglar esto?” → se interpreta como una pregunta, no como una instrucción
• Componentes de los slots de personalización:
  • Entorno (Environment): define los límites de confianza; por defecto, solo se confía en el repositorio git actual. Se pueden añadir GitHub orgs, buckets en la nube, APIs internas, etc.
  • Reglas de bloqueo (Block rules): más de 20 reglas base, agrupadas en 4 categorías:
    • Destrucción o filtración: sobrescribir historial con force push, borrado masivo en almacenamiento cloud, envío de datos internos al exterior
    • Deterioro de la postura de seguridad: desactivar logging, instalar persistencia como claves SSH o cronjobs, cambiar la propia configuración de permisos del agente
    • Violación de límites de confianza: ejecutar código clonado desde un repo externo, escanear almacenes de credenciales, enviar datos a servicios no especificados por el usuario
    • Evasión de revisión o impacto sobre otros: hacer push directo a main, ejecutar despliegues a producción, modificar recursos compartidos o jobs que el agente no creó
  • Excepciones permitidas (Allow exceptions): instalar paquetes ya declarados en el manifiesto del repo, flujos estándar de credenciales, hacer push a la rama de trabajo de la sesión, etc.

Resultados de evaluación

• Se evaluó el pipeline completo con 3 datasets:
  • Tráfico interno real (n=10,000): llamadas reales a herramientas de Claude Code por parte de empleados de Anthropic
  • Acciones excesivas reales (n=52): recopiladas de sesiones rechazadas por empleados o marcadas después; es pequeño porque solo puede recopilarse cuando Claude intenta una acción riesgosa en una sesión real
  • Exfiltración sintética de datos (n=1,000): generación de casos con envío de datos sensibles por HTTP POST, git push a remotos no confiables, credenciales incluidas en URLs, etc., incluyendo ofuscación

	Tráfico real (n=10,000)	Acciones excesivas reales (n=52)	Exfiltración sintética (n=1,000)
Stage 1 (filtro rápido)	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2 (pipeline completo)	FPR 0.4%	FNR 17%	FNR 5.7%

• El FNR del 17% en acciones excesivas reales es la cifra más honesta: el clasificador identifica riesgos (force push, borrado, cambios de infraestructura, etc.), pero falla al juzgar si las señales de consentimiento dentro de la sesión realmente cubren el blast radius de esa acción
• Si alguien dijo “ordena el PR”, pero no mencionó explícitamente el force push, aparece un patrón de error en el que el clasificador encuentra evidencias de aprobación y no valida suficientemente el alcance, incluso si acciones similares fueron aprobadas antes
• auto mode está pensado para quienes usan --dangerously-skip-permissions, y no es un reemplazo inmediato para la revisión manual cuidadosa en infraestructura de alto riesgo

Decisiones de diseño clave

• Eliminar mensajes del asistente y resultados de herramientas

  • Eliminar el texto del agente: evita que el agente genere racionalizaciones para convencer al clasificador (“ya fue aprobado implícitamente antes”, “este objetivo pertenece al agente”, etc.)
  • Eliminar resultados de herramientas: primera línea de defensa contra prompt injection, ya que la salida de herramientas es la vía de entrada de contenido adversarial
  • El clasificador puede decidir sin ver el payload: una acción que hace POST del contenido de un archivo .env a una URL externa viola la intención del usuario sin importar el contenido
  • Incluir mensajes del asistente + resultados de herramientas empeora el rendimiento en el dataset de acciones excesivas; las transcripciones cortas son más precisas porque reciben menos influencia del framing del agente

• Clasificación en 2 etapas: eficiencia y recall

  • En un clasificador de una sola etapa, el trade-off entre rendimiento y costo entra en conflicto directo
  • Stage 1: decisión rápida de un solo token con instrucción de “equivócate hacia bloquear” — acepta un FPR de 8.5% para lograr alto recall
  • Stage 2: usa el mismo prompt que Stage 1, pero cambia la instrucción final para hacer razonamiento cuidadoso — reduce el FPR de 8.5% a 0.4%
  • Como el prompt de Stage 2 es casi idéntico al de Stage 1, hay cache hits en la mayoría de los casos, lo que lo hace eficiente en costos

• Papel de la sonda de prompt injection

  • La defensa contra inyecciones del clasificador de transcripciones es estructural (no mira resultados de herramientas), pero el agente principal sí los ve
  • Si el agente principal es secuestrado, podría esquivar el monitor de transcripciones → por eso hace falta la sonda de la capa de entrada
  • Las dos capas trabajan de forma compuesta: para que una inyección tenga éxito, debe pasar la capa de entrada y luego el clasificador de transcripciones tendría que juzgar de forma independiente y sin payload que esa llamada a herramienta es segura y acorde con la intención del usuario

• Handoff multiagente

  • El clasificador corre tanto al delegar a un subagente (outbound) como al devolver resultados (return)
  • Chequeo outbound: evita el problema de que, dentro del subagente, las instrucciones del orquestador parezcan “mensajes del usuario” y se vean como completamente aprobadas
  • Chequeo de retorno: cubre el caso en que un subagente aparentemente normal al delegarse haya quedado expuesto a prompt injection durante la ejecución; antes de pasar resultados al orquestador, se revisa todo su historial de acciones y, si se marca algo, se añade una alerta de seguridad

• Bloquear y continuar (Deny-and-continue)

  • Cuando el clasificador bloquea una acción, no corta la sesión y guía a Claude para que intente una alternativa más segura
  • Al bloquear, se envía como resultado de herramienta la razón del rechazo y la instrucción de “aceptar el límite de buena fe y buscar una ruta más segura”
  • Tras 3 bloqueos consecutivos o 20 en total → se escala a una persona (en modo headless, el proceso termina)
  • Un FPR de 0.4% parece pequeño, pero si cada falso positivo cerrara la sesión, sería un problema grave de usabilidad en tareas de larga duración → esta estructura lo convierte en el costo de un solo reintento

Próximos planes

• Seguir ampliando el dataset real de acciones excesivas y repetir iteraciones para mejorar la seguridad y el costo de la función
• El clasificador no necesita ser perfecto; el objetivo es bloquear suficientes acciones riesgosas para hacer la operación autónoma sustancialmente más segura que un estado sin guardrails
• Se recomienda a los usuarios mantener conciencia del riesgo residual, seguir evaluando qué tareas y entornos conviene ejecutar de forma autónoma y enviar feedback cuando auto mode cometa errores