Las herramientas de red team agénticas pueden ser secuestradas por sus propios objetivos

¿Qué es esto?

El 23 de junio de 2026, Dario Pasquini y sus colegas de Cracken (con un colaborador de la Universidad Politécnica Nacional de Lviv) publicaron Red-Teaming the Agentic Red-Team (arXiv:2606.24496). Es el primer análisis de seguridad en profundidad de las herramientas que muchos profesionales usan ya para automatizar la seguridad ofensiva: sistemas agénticos de pentest y red team que dirigen el reconocimiento, la explotación y la post-explotación con poca o ninguna intervención humana.

El hallazgo es incómodo: estas herramientas se defienden a sí mismas muy mal. En 12 sistemas ampliamente utilizados —incluidos CAI, RedAmon, PentestAgent, DarkMoon, PentAGI, AIRecon, PentestGPT, METATRON, nebula, xalgorix, Artemis y STRIX— los autores demuestran que un adversario que controla el objetivo de una operación puede darle la vuelta: exfiltrar las claves de API del LLM del operador, plantar un punto de apoyo persistente y, en última instancia, comprometer la máquina del propio operador, incluso cuando el agente corre dentro de un contenedor en sandbox. Se trata de un artículo sobre una clase de vulnerabilidad, no de la difusión de un payload.

Cómo funciona

La manipulación empieza donde el agente menos lo espera: en la salida de los propios sistemas que ataca. Un agente ofensivo reinyecta en su LLM los resultados de comandos, las páginas extraídas y los banners de servicios. Un objetivo que devuelve contenido manipulado puede orientar el razonamiento del agente, no mediante una cadena explícita de «ignora las instrucciones anteriores», sino a través de engaño contextual y reward hacking. El artículo describe una manipulación sin inyección de prompt que provoca una ejecución de código casi determinista en el worker del agente, incluso con modelos de frontera como Claude Opus 4.8, GPT-5.5 y Gemini 3.1 Pro, tomando prestadas ideas de la evasión de antivirus para disfrazar el comportamiento malicioso como un paso legítimo hacia el objetivo del agente.

Los autores abstraen la escalada en una kill chain adaptada a estas herramientas: manipulación inicial del LLM, ejecución de código en el worker, movimiento lateral, persistencia, elusión de los guardarraíles, escape del sandbox y, finalmente, compromiso del host. Dos debilidades arquitectónicas recurrentes causan la mayor parte del daño. Primero, un aislamiento débil del sistema de archivos: muchas herramientas comparten un directorio con permisos de escritura (un bind mount o un volumen Docker) entre el worker poco confiable y el orquestador más confiable, de modo que un atacante capaz de ejecutar código en el worker puede troyanizar archivos fuente vivos que el orquestador cargará después —persistencia dura y una vía hacia el movimiento lateral—. Segundo, un aislamiento de red débil y canales demasiado amplios: API de orquestación pensadas solo para la interfaz son alcanzables desde el worker, y el código del orquestador que analiza la salida del worker queda expuesto a errores de inyección clásicos —metacaracteres de shell, escape de plantillas, deserialización insegura— que convierten un canal de datos en ejecución remota de código.

Por qué importa

Los agentes de seguridad ofensiva operan con privilegios inusualmente peligrosos: amplio alcance de red, claves de API valiosas y la confianza implícita del operador. Por diseño, además, pasan toda su vida ingiriendo datos controlados por el atacante. Es el lethal trifecta llevado a su extremo lógico, y significa que el sandbox alrededor del worker no es la frontera de seguridad que se supone: el artículo demuestra que el compromiso del host sigue siendo alcanzable con independencia del sandboxing en la mayoría de las herramientas probadas. Para quien despliega estos sistemas contra adversarios reales —red teams, MSSP y, cada vez más, defensores que emulan amenazas— un objetivo trampa ya no es hipotético. La misma vía de inyección de prompt a RCE observada en frameworks de agentes generales se aplica aquí, con el giro de que el atacante ya posee el entorno que se le ordena atacar al agente.

Defensas

La lección central del artículo es arquitectónica: deje de suponer que el LLM rechazará de forma fiable lo malicioso e imponga en su lugar una frontera de privilegios estricta en el harness. Trate cada byte producido por el worker como una entrada no confiable que debe escrutarse antes de llegar al orquestador. En concreto, los autores recomiendan mantener el orquestador y el worker en contenedores/SO y segmentos de red distintos, exponiendo solo los puertos estrictamente necesarios; evitar por completo los montajes de archivos compartidos y mover los artefactos por un canal único, estrechamente definido y auditable (con aprobación humana o inspección de contenido) en lugar de un directorio compartido; y mantener la capa de orquestación sin herramientas, delegando toda ejecución de comandos en el worker para que un worker comprometido no pueda pivotar hacia arriba. Endurezca el canal comando-respuesta frente a la inyección igual que cualquier parser que maneje entrada hostil, y reconstruya los contenedores worker en cada operación para que la persistencia no sobreviva. El mínimo privilegio —y no una confianza optimista en la alineación del modelo— es el principio de carga. Estos controles refuerzan la idea más amplia de que los escapes de sandbox en agentes que ejecutan código son un problema de sistema, no de modelo.

Estado

Red-Teaming the Agentic Red-Team es una divulgación de investigación (arXiv:2606.24496, publicada el 23 de junio de 2026) que cubre 12 herramientas nombradas; los autores resumen las capacidades del atacante por herramienta y proponen una arquitectura de referencia segura en lugar de difundir exploits armados. No hay un único CVE: la contribución es una taxonomía compartida de fallos de diseño y un plan de defensa. Cualquier equipo que use utillaje ofensivo agéntico debería auditar ya su despliegue frente a la kill chain del artículo: verificar el aislamiento worker/orquestador, eliminar los montajes compartidos y confirmar que un objetivo hostil no puede alcanzar nada más allá de un sandbox worker desechable.