Contexte Technique
J'aime particulièrement ce type d'attaques : en apparence, rien de « malveillant » ne se produit, mais l'agent dévie quand même. Dans cet article, les auteurs montrent un nouveau vecteur contre le RAG multi-sauts, où ils brisent non pas les faits, mais la saillance. Pour ceux qui construisent l'automatisation IA et l'intégration IA avec recherche documentaire, c'est une catégorie d'erreurs très désagréable.
Le principe est simple et sournois. Le texte reste factuellement vrai, mais on en modifie l'ordre, l'emphase, la proximité des fragments, la formulation et le cadrage pour que le modèle associe les mauvais attributs lors du raisonnement multi-sauts. Autrement dit, on attaque non pas la véracité, mais la saillance, et de nombreux pipelines sont complètement aveugles à cela.
J'ai examiné la mécanique annoncée : les auteurs proposent six classes d'édition de saillance et un pipeline itératif proposeur-vérificateur avec des contraintes de véracité et de furtivité. Ce n'est plus une injection de prompt « sale » que l'on peut attraper par des filtres d'instructions. Ici, l'agent lit un texte normal et commet ses propres erreurs de liaison d'entités.
Les chiffres sont également désagréables. Avec un budget d'édition de 30 %, ils atteignent un taux de réussite d'attaque de 83,3 % sur plusieurs familles de modèles, dont GPT, Claude, Gemini, DeepSeek et Qwen, ainsi que sur des agents ReAct, Reflexion et avec appels d'outils. Le plus révélateur pour moi : la défense de base la plus forte laisse encore un ASR post-défense de 75,7 %.
J'ai été particulièrement intrigué par la défense de Normalisation de Saillance. Elle est côté entrée, c'est-à-dire qu'elle peut être intégrée sans remanier complètement l'architecture IA, et dans l'article elle réduit l'ASR à 15,3 %, voire à 23,6 % sous attaque adaptative. Si ces résultats se confirment en pratique, ce n'est plus une broutille académique, mais une couche de défense tout à fait applicable.
Ce que cela Change pour les Entreprises et l'Automatisation
Premièrement : « contexte véridique » ne rime plus avec « contexte sûr ». Si votre agent RAG compile des réponses à partir de CRM, de bases de connaissances, de tickets et de sources externes, vérifier l'absence de faits faux et d'instructions ne suffit plus.
Deuxièmement : ce sont les scénarios multi-sauts qui sont particulièrement menacés. Plus l'agent est complexe dans la liaison d'entités entre documents, plus le risque d'erreur silencieuse mais convaincante est élevé. Pour le support, la conformité, l'analyse et les copilotes internes, cela fait plus mal qu'un simple bruit de récupération.
J'ajouterais d'ores et déjà au pipeline la normalisation de la représentation du contexte, des tests de mauvaise liaison et des ensembles red-team incluant non seulement l'injection, mais aussi la manipulation de saillance. Chez Nahornyi AI Lab, nous résolvons ce genre de problèmes pour les clients au niveau du développement de solutions IA : nous ne faisons pas que brancher le RAG, nous vérifions où l'on peut égarer un agent sans une seule ligne fausse.
Si vous avez déjà un agent de récupération en production et que les réponses semblent parfois « logiques mais occasionnellement bizarres », je ne mettrais pas cela sur le compte du hasard. Avec Vadym Nahornyi et Nahornyi AI Lab, vous pouvez rapidement analyser votre pipeline contextuel et mettre en place une protection pour une automatisation IA réelle, avant qu'une attaque aussi silencieuse ne se transforme en une coûteuse erreur système.