Resumen de la publicación
Un experimento con 40.000 sesiones y 409.000 decisiones midió qué tan bien aprueban o rechazan los humanos los comandos que les pide un agente de IA. El supervisor promedio deja pasar 1 de cada 3 amenazas, y solo el 20,8% logró detectarlas todas sin bloquear de más.
Vendimos la aprobación humana como el control que hace segura la delegación a agentes. Los números dicen que funciona mucho peor de lo que asumimos, y que el problema no se arregla pidiendo más atención.
Cada vez que alguien plantea un riesgo de los agentes de IA, la respuesta llega sola y suena razonable: «hay un humano que aprueba». La usé yo también, y está en las presentaciones de todos los proveedores y en las políticas internas que vi este año.
Desde que leí los números que salieron esta semana, dejé de usarla así.
Uno de cada tres pasa
Alex Wauters armó un juego de navegador donde jugás de supervisor: te llegan comandos que un agente quiere ejecutar y tenés que aprobarlos o rechazarlos, con presión de tiempo. Se recolectaron 40.000 sesiones y 409.000 decisiones, y cerca del 34% de los comandos eran efectivamente amenazas.
El jugador promedio dejó pasar 1 de cada 3, con una precisión media del 66,3%. Solo el 20,8% detectó todas las amenazas sin bloquear de más, que es el número que describe el trabajo real: si rechazás de más, el agente no sirve y el equipo termina desactivando la aprobación.
El desglose por tipo de amenaza es lo que convierte esto de dato curioso en algo accionable:
- Comandos destructivos obvios: 11,7% de omisión.
- Cambios permanentes en el sistema: 23,8%.
- Fuga de datos y ejecución de código: 33,4%.
- Salirse del alcance autorizado: 35,0%.
Fijate la progresión. Somos bastante buenos frenando un rm -rf y bastante malos frenando lo que se parece a trabajo normal.
El ejemplo estrella del estudio es npm run analyze, que se aprobó el 64,7% de las veces pese a tener código malicioso visible en el historial. No es que la gente no supiera: es que un comando que parece rutina no dispara la revisión, aunque la evidencia esté ahí, a la vista.
Esa es exactamente la brecha que un atacante necesita. No tiene que esconder nada: le alcanza con envolverlo en algo que se parezca al décimo comando aburrido del día.
Y no deberíamos sorprendernos. Es la misma fatiga por alertas que conocemos hace décadas de cualquier sistema de monitoreo, con otro nombre: un control cuya respuesta correcta es «sí» la mayoría de las veces no es un control, es un trámite.
Dos casos donde la aprobación ni siquiera existió
Si el estudio fuera lo único, se podría discutir cuánto se parece un juego a la realidad. Pero la misma semana dejó dos casos donde el humano directamente no estuvo.
- Rovo, el asistente de Atlassian, viene activado por defecto en los planes Standard, Premium y Enterprise. En el camino que encontró Varonis, un parámetro de la URL precarga instrucciones maliciosas y un solo click de un usuario ya autenticado alcanza para que Rovo busque información accesible por la víctima y la mande a un servidor ajeno. El usuario aprobó hacer click en un link, no eso.
- Los agentes de código con acceso al pipeline no tienen humano en el circuito por diseño: corren solos, de noche, disparados por un issue que abrió un desconocido.
Y está bien que corran solos, porque ese es el punto de automatizar. Lo que está mal es sostener que hay supervisión humana cuando el flujo se diseñó explícitamente para no tenerla.
Qué haría en lugar de pedir más atención
La conclusión fácil sería «capacitemos mejor a la gente», y me parece la conclusión equivocada: el problema no es de conocimiento sino de diseño de la interacción.
- Bajar el volumen antes que subir la atención. Si el agente pide veinte aprobaciones por hora, el problema es el alcance del agente, no la vista del que aprueba.
- Mostrar el efecto, no el comando. «Ejecutar
npm run analyze» no dice nada. «Este script va a conectarse a un dominio que no está en la lista permitida» sí. La decisión hay que tomarla sobre consecuencias. - Aislar en vez de aprobar. Si el agente corre en un entorno desechable donde el peor caso es perder ese entorno, la aprobación deja de ser el único control. Docker Sandboxes le da a cada agente su propia máquina virtual aislada. Ese enfoque escala; la atención humana no.
- Medir la tasa de aprobación. Si en tu organización se aprueba el 98% de los pedidos, ya sabés que ese control no está filtrando nada. Son dos líneas de SQL y te dice más que cualquier política escrita.
Un control que no medimos no es un control
Lo que más me molesta no es que la supervisión humana funcione mal, sino que la pusimos en los diagramas como si funcionara bien y nunca la medimos. Ningún equipo serio aceptaría un firewall del que no tiene métricas, y aceptamos sin chistar un control de aprobación del que no sabemos ni la tasa ni el tiempo promedio de decisión.
No estoy diciendo que saquemos al humano del circuito. Estoy diciendo que dejemos de contarlo como el control principal, cuando atrapa dos de cada tres cosas en el mejor caso y las que se le escapan son justamente las que un atacante elegiría.
La pregunta que dejaría sobre la mesa en la próxima reunión de arquitectura es esta: si mañana sacáramos la aprobación humana del diseño, ¿qué otro control quedaría en pie?
Si la respuesta es «ninguno», entonces no hay controles. Hay uno solo, y encima es el más débil.
