RIFT-Bench : red-teamer les agents en cartographiant leur code, pas leurs prompts

De quoi s’agit-il ?

RIFT-Bench est une méthodologie de red-teaming pour les systèmes d’IA agentiques, publiée sur arXiv le 22 juin 2026 par une équipe de Fujitsu Research of Europe et Fujitsu Research of India. Son argument : la plupart des tests de sécurité des agents LLM ont hérité des mauvaises hypothèses du red-teaming des LLM. Ils traitent le prompt utilisateur comme seule surface d’attaque et ne jugent le succès qu’à la sortie texte finale du modèle. Cette vision convient à un chatbot. Elle ne convient pas à un système qui appelle des outils, conserve une mémoire, coordonne plusieurs agents et agit réellement dans un environnement.

L’observation centrale de l’article est que les vulnérabilités des agents émergent des interactions entre entrées non fiables, outils, mémoire et actions privilégiées — pas d’un prompt isolé. Pour tester un agent de façon utile, il faut donc d’abord comprendre comment il est réellement construit. RIFT-Bench fait de cette compréhension structurelle le point de départ de l’évaluation, et non une réflexion après coup.

Comment ça marche

Le cadre fonctionne en deux phases automatisées. La première, Discovery, lit le code du système cible et en extrait une représentation structurée que les auteurs nomment NodeSpec : un graphe hiérarchique qui capture chaque composant agentique, la façon dont les composants interagissent, et les blocs de code d’implémentation qui ancrent chaque nœud. Discovery met aussi en place une émulation d’outils configurable, pour exécuter les tests sans solliciter réellement les services externes — une mesure de sûreté et de coût qui évite les effets de bord réels.

La seconde phase, Scanning, utilise le graphe NodeSpec pour instancier des attaques adaptées au système précis, puis les exécute, les trace et les note, produisant un rapport de vulnérabilités. Ce qui rend l’approche réutilisable sur des agents très différents est une hiérarchie de surface d’attaque à quatre niveaux. Une surface est une classe de point d’entrée : outils, mémoire, ressources externes, entrée utilisateur. Un suite est une configuration opérationnelle au sein d’une surface, comme l’injection via les sorties d’outils. Un probe est un modèle réutilisable et agnostique au système, associé à ses évaluateurs. Un attempt est l’instanciation concrète d’un probe sur les outils et arguments réels d’un système. Le même probe peut donc être ré-instancié automatiquement sur de nombreuses architectures, et couplé à un second axe d’objectifs adverses : effectuer une action non voulue, empêcher l’accomplissement de la tâche, exfiltrer des informations internes ou surcharger les ressources.

Comme RIFT-Bench évalue le système lui-même plutôt qu’un substitut simulé, ses probes atteignent des modes de défaillance que les tests limités au prompt manquent — par exemple une surface d’outil malveillant exprimée en injection au niveau de la description, en actions non autorisées ou en manipulation de sortie, chacune un suite distinct avec ses propres modèles.

Pourquoi c’est important

Le problème récurrent de la sécurité des agents est que les évaluations sont liées à un framework ou à un environnement de benchmark, de sorte que les résultats ne se transfèrent pas. Un jeu d’attaques écrit pour une implémentation ne peut être réutilisé sur une autre, et les comparaisons entre systèmes hétérogènes deviennent impossibles. L’apport de RIFT-Bench est la généralité : les auteurs démontrent le pipeline sur 45 systèmes agentiques couvrant cinq domaines — finance, médical, assistant personnel, voyage et tâches ouvertes « wild » — et rapportent des taux de succès d’attaque ventilés par surface d’attaque, architecture, framework, objectif de l’attaquant et type d’évaluateur. Ces taux varient fortement selon les domaines et les objectifs, ce qui est justement le propos : un chiffre unique masque l’endroit où un système donné est réellement faible.

Pour les défenseurs, l’intérêt pratique est une manière reproductible de demander « où cet agent est-il exposé ? » plutôt que « cet agent échoue-t-il à une suite de tests figée ? ». À mesure que les agents passent du prototype aux flux de travail d’entreprise, ce basculement du test centré sur le prompt vers un test centré sur la structure est ce qui permet à la sécurité de suivre le rythme de systèmes câblés de façons très diverses.

Défenses

RIFT-Bench est lui-même un outil défensif, et l’article intègre l’évaluation des défenses au cadre plutôt que de la traiter à part.

Testez les défenses en situation, pas dans l’abstrait. Les défenseurs peuvent définir une logique d’intervention personnalisée que RIFT-Bench intègre automatiquement au système cible, de sorte qu’une mitigation soit mesurée contre les mêmes probes que le système non défendu. L’article fournit une défense simple de suppression de description (retirer les descriptions d’outils avant exécution) et intègre le prompt sandwiching et les délimiteurs de données de travaux antérieurs comme références.

Défendez à deux niveaux. Les auteurs distinguent les mitigations au niveau composant (filtrage entrée/sortie embarqué dans des modules) et au niveau système (modifier la logique d’orchestration entre agents et outils pour que les injections n’atteignent pas les actions privilégiées). Un agent robuste a généralement besoin des deux : un bon classifieur sur un module ne sert à rien si la conception route quand même une sortie d’outil non fiable vers une action à forte autorité.

Cartographiez d’abord votre propre surface d’attaque. La leçon plus profonde dépasse cet outil : on ne sécurise pas ce qu’on n’a pas modélisé. Recenser où entrent les entrées non fiables — prompts utilisateur, sorties d’outils, mémoire, ressources externes — et où résident les actions privilégiées est le préalable à tout test utile.

Pesez explicitement les compromis. Comme le cadre mesure ensemble robustesse, surcoût de calcul et utilité de la tâche, il rend visible le coût de chaque défense. Traitez la mitigation comme un arbitrage d’ingénierie à mesurer, pas comme une case à cocher.

Statut

Élément	Référence	Notes
Article de référence	arXiv:2606.23927, 22 juin 2026	Fujitsu Research (Europe et Inde)
Méthode	NodeSpec + Discovery/Scanning	Graphe extrait du code de la cible
Portée	Même article	Démontré sur 45 systèmes agentiques, cinq domaines
Défenses évaluées	Même article	Suppression de description, prompt sandwiching, délimiteurs de données comme références
Couverture indépendante	Digest Adversa AI, 2 juil. 2026	Recensement public du travail

L’enseignement durable est un recadrage : la sécurité d’un agent est une propriété de son architecture, pas seulement de son filtre de prompt. Un test qui commence par cartographier la construction du système trouvera les faiblesses au niveau des interactions que le red-teaming limité au prompt ne peut structurellement pas voir.