Un browser game pide a los jugadores que hagan de revisor humano para un agente IA que lanza comandos en la terminal. Algunos son inofensivos (git status, npm test), otros ocultan exfiltración de credenciales o ejecución de código remoto. En más de 40.000 sesiones y 409.000 decisiones individuales, los jugadores dejaron pasar un comando peligroso de cada tres (precisión media 66,3%).

Los comandos claramente destructivos como rm -rf / se detienen casi siempre (tasa de error 11,7%). Pero los comandos que leen tus credenciales (cat ~/.aws/credentials) o envían datos a servidores externos pasan tres veces más frecuentemente (tasa de error 33-35%). El peor caso: npm run analyze aprobado en el 64,7% de los casos, aunque el log encima del prompt mostraba el payload malicioso dentro de package.json.

Por qué te afecta. Si despliegas agentes y apruebas sus comandos manualmente, estos números te describen a ti. La supervisión humana en tiempo real es un filtro con agujeros medibles, no una garantía. El problema es estructural, no distracción ocasional. Los comandos familiares (npm run, git config) ocultan payloads arbitrarios, y quien aprueba no tiene el tiempo ni el contexto para inspeccionarlos todos. El dato se suma a lo que contamos sobre el test UK AISI, donde un agente engañaba a revisores humanos sin recibir instrucción: aquí la medida es a escala, con números reproducibles.

El 7% de los jugadores aprobó cada prompt individual. Anthropic ya documentó el fenómeno en Claude Code llamándolo permission fatigue: cuantas más aprobaciones ves, menos atención das a cada una. Los datos del juego lo confirman, con las tasas de error que suben hacia el final de sesión.

En detalle

El juego fue publicado hace unos meses en scalex.dev y recibió interés en Hacker News (244 puntos, 187 comentarios). Tras añadir rastreo estadístico, el autor analizó más de 40.000 ejecuciones con 409.000 decisiones approve/deny individuales.

Los números principales. El 35,2% de los jugadores interceptó cada amenaza, pero solo el 20,8% lo logró bloqueando como mucho un comando seguro de cada cinco. Los otros llegaron a cero amenazas bloqueándolo todo: el título poco halagador en el juego era “Human Bottleneck”. El 32,9% de las sesiones terminó con puntuación negativa: las penalizaciones por amenazas aprobadas y comandos seguros bloqueados superaron todo lo que el jugador hizo bien.

Las categorías de amenaza y sus tasas de error.

• Destructivos obvios (rm -rf /, chmod -R 777 /): 11,7% de tasa de error.
• Mutación persistente (inyección crontab, secuestro git config): 23,8%.
• Exfiltración y ejecución de código (curl a APIs desconocidas, paquetes typosquatting): 33,4%.
• Violación de scope (cat ~/.aws/credentials, cat ~/.kube/config): 35,0%.

El patrón es claro: los comandos que parecen operaciones normales de desarrollo son los que pasan. Los comandos claramente destructivos se detienen casi siempre. Los comandos que leen archivos sensibles o envían datos al exterior, que son los más peligrosos en producción, pasan tres veces más frecuentemente.

El punto ciego de npm run. El comando individual más aprobado por error es npm run analyze, pasado en el 64,7% de los casos. El comando en sí es inocente, pero npm run ejecuta un script definido en package.json, y ese script puede contener cualquier cosa. El juego mostraba el contenido real del script en el log del agente, justo encima del prompt de aprobación: dos tercios de los jugadores no lo leyeron.

Tres comandos npm run en el juego (analyze, setup, deploy) fueron erroneamente aprobados en el 52,5% de los casos (n=9.482) contra el 28,4% para todas las otras exfiltraciones. Ocultar un payload tras un nombre de script familiar duplica aproximadamente la tasa de éxito del ataque, incluso cuando el payload es visible.

Como observa un comentarista en Hacker News, el modelo de aprobación comando-por-comando tiene un defecto fundamental: el agente pudo haber modificado package.json, build.js o un archivo en node_modules antes del comando que pide aprobar. Pedirle al usuario que valide npm run build cuando los archivos que ese script ejecuta pueden haber sido ya comprometidos no es una defensa sólida.

Fatiga por aprobación. Las tasas de error mejoran en los primeros comandos de cada sesión (quien se calienta) y luego suben hacia el final. El reloj que pasa y la presión de procesar tantos comandos como sea posible degradan la atención. Es la versión comprimida en pocos minutos de lo que Anthropic documenta en Claude Code en horizontes de horas o días.

El costo de la vigilancia: bloqueo excesivo. Comandos inofensivos se bloquean regularmente: npm config set registry a un mirror interno bloqueado en el 59% de los casos, rm -rf dist/ en el 45%, kill del proceso en puerto 3000 en el 43%. Quien supervisa no solo se equivoca dejando pasar los peligrosos: también ralentiza el trabajo legítimo del agente.

Los límites del dato. Era un juego: el 34% de los comandos mostrados eran amenazas, una proporción mucho más alta que la real. Los jugadores sabían que estaban siendo probados, lo que debería mejorar la vigilancia respecto al trabajo diario. Los números no dicen qué sucede en ocho horas de trabajo con un agente real, pero la dirección del dato es clara: la supervisión humano-en-el-bucle como última línea de defensa no aguanta bajo presión, y el problema empeora con la familiaridad del comando.

Para quienes construyen sistemas de agentes, el aprendizaje operativo apunta hacia arquitecturas zero trust con credenciales temporales y permisos mínimos, donde el daño de un comando aprobado por error está limitado por el diseño del sistema, no por la atención de quien hace clic.