RIFT-Bench: red-teaming de agentes cartografiando su código, no sus prompts
Un artículo de Fujitsu de junio de 2026 reenfoca las pruebas de seguridad de agentes en su estructura. Extrae del código un grafo de los componentes del agente e instancia ataques a medida, generalizando a 45 sistemas heterogéneos.
¿Qué es esto?
RIFT-Bench es una metodología de red-teaming para sistemas de IA agéntica, publicada en arXiv el 22 de junio de 2026 por un equipo de Fujitsu Research of Europe y Fujitsu Research of India. Su argumento es que la mayoría de las pruebas de seguridad de agentes LLM heredaron los supuestos equivocados del red-teaming de LLM: tratan el prompt del usuario como única superficie de ataque y solo juzgan el éxito por la salida de texto final del modelo. Esa visión encaja con un chatbot. No encaja con un sistema que invoca herramientas, mantiene memoria, coordina varios agentes y ejecuta acciones reales en un entorno.
La observación central del artículo es que las vulnerabilidades de los agentes surgen de las interacciones entre entradas no confiables, herramientas, memoria y acciones privilegiadas, no de un prompt aislado. Por tanto, para probar un agente de forma útil primero hay que entender cómo está realmente construido. RIFT-Bench convierte esa comprensión estructural en el punto de partida de la evaluación, y no en una idea tardía.
Cómo funciona
El marco opera en dos fases automatizadas. La primera, Discovery, lee el código del sistema objetivo y extrae una representación estructurada que los autores llaman NodeSpec: un grafo jerárquico que captura cada componente agéntico, cómo interactúan los componentes y qué bloques de código de implementación anclan cada nodo. Discovery también configura una emulación de herramientas ajustable, para ejecutar las pruebas sin llamar realmente a servicios externos: una medida de seguridad y de coste que evita efectos secundarios reales.
La segunda fase, Scanning, usa el grafo NodeSpec para instanciar ataques adaptados al sistema concreto, luego los ejecuta, los traza y los puntúa, produciendo un informe de vulnerabilidades. Lo que hace reutilizable el enfoque en agentes muy distintos es una jerarquía de superficie de ataque de cuatro niveles. Una surface es una clase de punto de entrada: herramientas, memoria, recursos externos, entrada de usuario. Un suite es una configuración operativa dentro de una superficie, como la inyección vía salidas de herramientas. Un probe es una plantilla reutilizable y agnóstica al sistema, junto con sus evaluadores. Un attempt es la instanciación concreta de un probe sobre las herramientas y argumentos reales de un sistema. El mismo probe puede así reinstanciarse automáticamente sobre muchas arquitecturas, acoplado a un segundo eje de objetivos adversarios: realizar una acción no deseada, impedir completar la tarea, filtrar información interna o sobrecargar los recursos.
Como RIFT-Bench evalúa el sistema en sí y no un sustituto simulado, sus probes alcanzan modos de fallo que las pruebas limitadas al prompt pasan por alto: por ejemplo, una superficie de herramienta maliciosa expresada como inyección a nivel de descripción, acciones no autorizadas o manipulación de la salida, cada una un suite distinto con sus propias plantillas.
Por qué importa
El problema recurrente de la seguridad de agentes es que las evaluaciones están atadas a un framework o a un entorno de benchmark, de modo que los resultados no se transfieren. Un conjunto de ataques escrito para una implementación no puede reutilizarse en otra, y las comparaciones entre sistemas heterogéneos se vuelven imposibles. El aporte de RIFT-Bench es la generalidad: los autores demuestran el pipeline en 45 sistemas agénticos que abarcan cinco dominios —finanzas, medicina, asistente personal, viajes y tareas abiertas «wild»— y reportan tasas de éxito de ataque desglosadas por superficie de ataque, arquitectura, framework, objetivo del atacante y tipo de evaluador. Esas tasas varían mucho según el dominio y el objetivo, que es precisamente el punto: una única cifra oculta dónde es realmente débil un sistema dado.
Para los defensores, el valor práctico es una manera reproducible de preguntar «¿dónde está expuesto este agente?» en lugar de «¿falla este agente una suite de pruebas fija?». A medida que los agentes pasan del prototipo a los flujos de trabajo empresariales, ese giro de la prueba centrada en el prompt a la centrada en la estructura es lo que permite que la seguridad siga el ritmo de sistemas cableados de formas muy diversas.
Defensas
RIFT-Bench es en sí mismo una herramienta defensiva, y el artículo integra la evaluación de defensas en el marco en lugar de tratarla aparte.
Pruebe las defensas en contexto, no en abstracto. Los defensores pueden definir una lógica de intervención personalizada que RIFT-Bench incorpora automáticamente al sistema objetivo, de modo que una mitigación se mida frente a los mismos probes que el sistema sin defender. El artículo aporta una defensa simple de eliminación de descripción (retirar las descripciones de herramientas antes de ejecutar) e integra el prompt sandwiching y los delimitadores de datos de trabajos previos como referencias.
Defienda en dos niveles. Los autores distinguen las mitigaciones a nivel de componente (filtrado de entrada/salida embebido en módulos) y a nivel de sistema (modificar la lógica de orquestación entre agentes y herramientas para que las inyecciones no alcancen acciones privilegiadas). Un agente robusto suele necesitar ambas: un buen clasificador en un módulo no sirve si el diseño sigue enrutando una salida de herramienta no confiable hacia una acción de alta autoridad.
Cartografíe primero su propia superficie de ataque. La lección más profunda trasciende esta herramienta: no se asegura lo que no se ha modelado. Enumerar dónde entran las entradas no confiables —prompts de usuario, salidas de herramientas, memoria, recursos externos— y dónde residen las acciones privilegiadas es el requisito previo a cualquier prueba útil.
Sopese los compromisos de forma explícita. Como el marco mide juntas robustez, sobrecarga de cómputo y utilidad de la tarea, hace visible el coste de cada defensa. Trate la mitigación como una disyuntiva de ingeniería que se mide, no como una casilla que se marca.
Estado
| Elemento | Referencia | Notas |
|---|---|---|
| Artículo de referencia | arXiv:2606.23927, 22 jun 2026 | Fujitsu Research (Europa e India) |
| Método | NodeSpec + Discovery/Scanning | Grafo extraído del código del objetivo |
| Alcance | Mismo artículo | Demostrado en 45 sistemas agénticos, cinco dominios |
| Defensas evaluadas | Mismo artículo | Eliminación de descripción, prompt sandwiching, delimitadores de datos como referencias |
| Cobertura independiente | Digest de Adversa AI, 2 jul 2026 | Registro público del trabajo |
La conclusión duradera es un replanteamiento: la seguridad de un agente es una propiedad de su arquitectura, no solo de su filtro de prompt. Una prueba que empieza por cartografiar cómo está construido el sistema encontrará las debilidades a nivel de interacción que el red-teaming limitado al prompt estructuralmente no puede ver.