La suposición popular de que un ser humano que revisa cada comando puede mantener bajo control a los agentes codificadores de IA se enfrenta a un serio escrutinio. Un nuevo análisis de más de 40.000 sesiones de juego y más de 409.000 decisiones individuales de aprobación o denegación encontró que los revisores humanos omitieron aproximadamente uno de cada tres comandos maliciosos de agentes de IA, lo que plantea preguntas urgentes sobre si "humano en el circuito" es un límite de seguridad confiable.

Los hallazgos provienen de un juego de navegador creado por Alex Wauters, un ex ingeniero de Uber que escribe sobre seguridad para desarrolladores en Scale X. El juego coloca a los jugadores en el papel de un revisor humano para un agente de codificación de IA, pidiéndoles que aprueben o rechacen comandos de shell bajo presión de tiempo. Algunos comandos son rutinarios, como "git status" o "npm test". Otros son intentos cuidadosamente disfrazados de extraer credenciales, instalar puertas traseras o enviar secretos a servidores remotos. Después de agregar el seguimiento estadístico, Wauters recopiló suficientes datos para pintar una imagen detallada de dónde el juicio humano tiene éxito y, más a menudo, falla. Para obtener más información sobre la [cobertura de la industria de la IA] más amplia (https://aibuzzwire.news), este estudio se destaca como uno de los experimentos con mayor cantidad de datos hasta la fecha.

Los comandos más peligrosos fueron los más difíciles de atrapar

El hallazgo más sorprendente del estudio es que los comandos obviamente destructivos, como `rm -rf` en directorios críticos, se capturaron de manera confiable. Las amenazas que realmente lograron robar credenciales se pasaron por alto casi tres veces más. El comando más omitido en todo el juego fue "npm run analyse", aprobado por el 64,7 por ciento de los jugadores a pesar de que el registro histórico del agente muestra claramente que el script subyacente había sido manipulado para canalizar las credenciales a un servidor externo.

El problema es estructural. Comandos como `npm run` ejecutan cualquier script definido en el archivo `package.json` de un proyecto. Ese script podría ser un analizador de paquetes legítimo o un código malicioso inyectado por una edición de archivo anterior que el agente modificó. Para estar seguro, un desarrollador necesitaría inspeccionar cada archivo modificado antes de aprobarlo, lo que anula la ventaja de velocidad que se supone que brindan las herramientas de codificación de IA.

En tres de estos comandos de carga útil disfrazados en el juego, la tasa de fallos fue del 52,5 por ciento en comparación con el 28,4 por ciento para todos los demás ataques de exfiltración de credenciales. Ocultar una carga útil detrás de un nombre de script familiar duplicó aproximadamente su tasa de éxito, incluso cuando la carga útil era visible en el registro del historial que se muestra justo encima de la solicitud de permiso.

La fatiga en materia de permisos erosiona la vigilancia con el tiempo

Anthropic reconoció anteriormente que la fatiga de permisos es un fenómeno real en su producto Claude Code, y señaló que cuantas más aprobaciones ve un usuario, menos atención le presta a cada una. Los datos de Scale X respaldan empíricamente esta preocupación. Las tasas de fallo disminuyeron durante los primeros comandos de cada sesión a medida que los jugadores calentaban, pero luego aumentaron constantemente hacia el final, en consonancia con la fatiga o la presión creciente de un reloj que corre.

Este patrón refleja la dinámica del mundo real. Los desarrolladores que se apresuran a lanzar funciones bajo presión de fecha límite enfrentan el mismo incentivo para hacer clic en aprobar rápidamente, y el gran volumen de comandos de rutina crea un problema de aguja en un pajar donde las amenazas genuinas son estadísticamente raras. El resultado es un sistema que capacita a los usuarios para que aprueben todo.

El otro lado: el bloqueo excesivo ralentiza todo

El estudio también documentó el modo de falla opuesto. Varios comandos genuinamente benignos fueron bloqueados rutinariamente por jugadores cautelosos, incluidas las invocaciones estándar de compilación y prueba. Este bloqueo excesivo ralentiza al agente y, paradójicamente, aumenta el riesgo a largo plazo. Cuando a los usuarios se les pide repetidamente que aprueben comandos que resultan ser inofensivos, el ruido erosiona su voluntad de examinar futuras indicaciones, lo que eventualmente los empuja hacia omisiones completas o modos de aprobación automática que eliminan por completo la revisión humana.

Funciones como el modo automático de Anthropic intentan mitigar esto determinando automáticamente si un comando es seguro antes de avisar al usuario. Pero como lo demuestran los datos del estudio sobre cargas útiles encubiertas, incluso los contenidos de comando visibles no son suficientes para que los humanos emitan juicios confiables bajo presión.

La falta de contexto es el problema central

Un comando, `cat ~/.zshrc`, resultó ser el más divisivo de todo el juego, aprobado por el 45,9 por ciento de los jugadores. El comando es inofensivo para los desarrolladores que no guardan secretos en su perfil de shell, pero expone claves API para muchos de los que exportan credenciales allí. Su riesgo depende completamente de una configuración del sistema que el agente no puede ver y el revisor tal vez no recuerde.

Varios otros comandos generaron una controversia similar en el hilo de discusión de Hacker News por la misma razón. El problema fundamental es que a los desarrolladores se les pide que hagan juicios de seguridad sin tener una idea completa de qué archivos han cambiado, qué hizo el agente en los pasos anteriores y qué contiene la configuración actual del sistema. Como señaló un comentarista, pedir a los usuarios que validen comandos que son ambiguos sin contexto no es una protección sólida.

¿Qué sigue para la seguridad de los agentes?

Wauters sostiene que la solución no son mejores seres humanos sino mejores herramientas. Los agentes aislados para que no puedan acceder a las credenciales directamente, el aislamiento estricto del contexto y los límites estructurales sobre lo que los agentes pueden hacer sin permisos elevados son más prometedores que depender de la vigilancia humana. Hasta que esas salvaguardas estén implementadas, otorgar permisos amplios a los agentes sigue siendo riesgoso, independientemente de si un ser humano está nominalmente al tanto.

El estudio no es un artículo académico revisado por pares y Wauters reconoce sus limitaciones. El juego advirtió a los jugadores sobre amenazas y aplicó presión de tiempo artificial que puede no reflejar perfectamente los entornos de desarrollo reales. Pero el hallazgo principal, que los revisores humanos capacitados bajo presión pasan por alto un tercio de los ataques deliberadamente disfrazados, debería dar a cada equipo que implementa agentes de codificación de IA una razón para reconsiderar su modelo de seguridad.

Para los desarrolladores que construyen con agentes de IA hoy en día, la conclusión práctica es asumir que el ser humano en el circuito eventualmente fallará. Diseñe los permisos y el espacio aislado de su agente para que una aprobación perdida no signifique una clave de AWS filtrada o una canalización de compilación comprometida. Los datos sugieren que tratar la revisión humana como su principal defensa es una apuesta que no vale la pena.

Manténgase por delante de la IA

El panorama de seguridad de los agentes de IA está evolucionando rápidamente. Manténgase informado con los últimos desarrollos de IA y las últimas investigaciones.

Leer más noticias sobre IA →