Claude Code lanza Auto Mode para saltar permisos seguro | Keryc
Claude Code introduce Auto Mode, una opción técnica que busca un punto medio entre pedir aprobación humana en cada paso y desactivar por completo las protecciones. ¿El objetivo? Reducir la fatiga de aprobaciones sin regalar seguridad.
Qué problema resuelve Auto Mode
A quien ha trabajado con agentes le suena familiar: el modelo pide permiso para cada comando y terminas haciendo clic sin mirar. Esa fatiga de aprobaciones facilita errores humanos y procesos ineficientes. La alternativa extrema, --dangerously-skip-permissions, elimina prompts pero deja el sistema sin protección.
Auto Mode ofrece una tercera vía: delegar las aprobaciones a clasificadores basados en modelos. La idea es bloquear lo peligroso y dejar pasar lo rutinario, todo sin saturar al usuario.
Arquitectura de defensa: dos capas
Auto Mode opera con dos capas complementarias: la capa de entrada (input) y la capa de salida (output).
Capa de entrada: un probe servidor-side que detecta intentos de prompt injection en salidas de herramientas (lecturas de archivos, fetches web, salida de shell, respuestas externas). Si el contenido parece malicioso, el probe añade una advertencia en el contexto del agente para que trate esa información como sospechosa y se ancle en lo que el usuario pidió.
Capa de salida: un transcript classifier que corre sobre Sonnet 4.6 y evalúa cada acción antes de ejecutarla. Funciona en dos etapas: un filtro rápido de token único (sí/no) y, solo si el primer filtro marca la acción, una etapa de razonamiento tipo chain-of-thought para reducir falsos positivos.
La combinación busca que la mayoría de acciones pase sin latencia de razonamiento, y que el razonamiento costoso se use solo cuando hace falta.
Reglas por niveles: qué llega al clasificador
Auto Mode aplica un allowlist y reglas por niveles para minimizar el alcance del clasificador y concentrarlo en lo relevante:
Tier 1: Allowlist de herramientas seguras y configuraciones del usuario. Incluye solo operaciones de lectura, búsquedas, navegación de código y acciones que no cambian estado. Al activarse Auto Mode se eliminan reglas que permiten ejecución arbitraria (acceso a shell amplio, intérpretes con comodines, comandos de package manager).
Tier 2: Operaciones de archivos dentro del directorio del proyecto. Escribas y edits rutinarios dentro del repo siguen sin pasar por clasificador; se asume que el control de versiones permite auditoría.
Tier 3: Todo lo demás. Shells, fetches web, integraciones externas, spawns de subagentes y operaciones fuera del directorio del proyecto llegan al transcript classifier.
Solo las acciones con riesgo real alcanzan al clasificador, lo que reduce costos y latencia.
Cómo decide el clasificador
El prompt del clasificador es una plantilla fija con tres ranuras personalizables que definen la política del usuario (qué se considera confiable, qué bloquear, excepciones). Las decisiones se basan en tres principios:
Evaluar impacto real: se mira el efecto de la acción, no solo el texto. Si el agente escribe un payload y luego lo ejecuta, el clasificador evalúa el payload. Si hay cadenas de comandos concatenadas, se evalúa todo el conjunto.
Leer la intención del usuario: el clasificador es conservador. Todo lo que el agente hace por iniciativa propia es no autorizado hasta que el usuario lo autorice explícitamente. "Clean up my branches" no autoriza una eliminación masiva por defecto.
Definir el entorno de confianza: por defecto, solo se considera confiable el repo git actual. El usuario puede extender esto (orgs de GitHub, buckets, APIs internas). Fuera de ese límite, el riesgo de exfiltración existe.
Diseño técnico del pipeline
Stage 1: filtro rápido (single-token) instruido para "errar por bloquear". Su misión es empujar la recall alta para no dejar pasar acciones peligrosas. Esto genera más falsos positivos.
Stage 2: razonamiento con chain-of-thought para limpiar falsos positivos. Solo corre sobre lo marcado por stage 1, lo que amortigua el costo computacional.
Se diseña además que el clasificador no vea los outputs de las herramientas ni los mensajes del assistant. Solo recibe mensajes de usuario y llamadas a herramientas. Esto evita que el agente "converse" con el clasificador y lo convenza.
Datos y métricas (evaluación)
Probado en tres datasets: tráfico real, acciones reales de sobreentusiasmo (overeager) y exfiltración sintética. Reportan FPR (tasa de falsos positivos) y FNR (tasa de falsos negativos):
Dataset
Stage 1 (filtro)
Pipeline completo (Stage 1 -> Stage 2)
Tráfico real n=10,000
8.5% FPR
0.4% FPR
Overeager real n=52
6.6% FNR
17% FNR
Exfiltración sintética n=1,000
1.8% FNR
5.7% FNR
La cifra honesta importante: 17% FNR en el conjunto de acciones overeager reales tras toda la pipeline. Eso significa que el clasificador deja pasar 17% de acciones peligrosas interesadas en resolver la tarea del usuario. ¿Es aceptable? Depende: es una mejora grande respecto a --dangerously-skip-permissions, pero aún no reemplaza revisiones humanas para infraestructuras críticas.
Defensa contra prompt injection y ataques en cadena
Auto Mode no depende solo del clasificador. Si un contenido malicioso entra por una herramienta y logra manipular al agente, el input probe intenta detectar la inyección y marca la pieza como sospechosa antes de que llegue al agente.
Para que un ataque funcione de punta a punta, debe escapar la detección del probe y además producir una llamada a herramientas que el clasificador juzgue segura y alineada con la intención del usuario. Hacer ambas cosas es mucho más difícil que sortear una sola defensa.
Además, el clasificador corre en ambos extremos de una delegación a subagentes: al delegar trabajo y al recibir resultados. Eso evita que un subagente reciba una tarea que parece autorizada solo porque la orquestación la presenta como tal.
Manejo de bloqueos y experiencia de usuario
Cuando el clasificador bloquea, Claude no se detiene indefinidamente. En lugar de eso devuelve una negación como resultado de herramienta con instrucciones para buscar un camino más seguro y no intentar rodear la restricción.
Hay un backstop: tras 3 denegaciones consecutivas o 20 en total, la sesión se detiene y se escala a humano. En modo headless (claude -p) el proceso se termina. Esta regla protege contra agentes comprometidos o excesivamente insistentes.
Los falsos positivos son bajos (0.4% FPR) pero no nulos. Auto Mode está diseñado para que un falso positivo permita reintentos y nudges en vez de romper flujos largos.
Personalización y despliegue
La plantilla del clasificador incluye tres ranuras configurables: la política de confianza, las categorías a bloquear y las excepciones. Vienen con valores conservadores por defecto. Puedes empezar con claude auto-mode defaults y luego ajustar la configuración en lugar de reescribir todo.
Recomendación práctica: usa Auto Mode cuando comparas contra --dangerously-skip-permissions o cuando la sobrecarga de aprobación humana no compensa el riesgo. No lo uses como sustituto de revisiones humanas en tareas de alto riesgo.
Reflexión final
Auto Mode no promete perfección; promete un mejor balance entre autonomía y seguridad. Es una defensa en profundidad: probe de input, clasificador de transcript en dos etapas, reglas por niveles y políticas ajustables. Para equipos que quieren menos clics pero no quieren dejar de proteger infraestructuras críticas, es una herramienta valiosa.
¿Y después? Mejorar el testset de overeagerness, ajustar la plantilla y reducir la FNR serán las siguientes tareas. Mientras tanto, la recomendación práctica es conocer los límites del modo automático, configurar bien el entorno de confianza y mantener revisión humana donde el riesgo es inaceptable.
