Command Palette
Search for a command to run...
NVIDIA Et al. Proposent EvoSafeHarness, Qui Personnalise Automatiquement Les Défenses De Sécurité Pour Différents Agents IA, Réduisant Le Taux De Réussite Des Attaques De 45,6 % À 10,0 %
À mesure que les grands modèles de langage passent du statut d'outils de dialogue à celui d'agents capables d'appeler des fichiers, des comptes, des bases de données et des services externes, la sécurité de l'IA commence également à faire face à des conséquences concrètes plus tangibles. Une simple erreur de jugement d'un modèle ordinaire peut ne générer qu'une réponse incorrecte ; lorsque le modèle est capable d'appeler des outils et d'exécuter des actions, la même erreur peut pourtant entraîner des transferts de fonds, des fuites de données, la suppression de fichiers et d'autres impacts réels. À ce stade, les problèmes de sécurité ne se limitent plus au contenu des réponses, mais s'étendent à l'ensemble du processus d'exécution des tâches : l'agent doit non seulement comprendre l'intention de l'utilisateur, mais aussi éviter d'exécuter des opérations non autorisées sous l'influence d'instructions erronées ou de contenus malveillants.
Ce type de risque ne provient pas uniquement des utilisateurs. Un attaquant peut dissimuler des instructions malveillantes dans des contenus externes tels que des e-mails, des pages web ou des documents ; après lecture par l'agent, ces informations qui devraient être traitées comme des données peuvent être confondues avec de nouvelles instructions — c'est ce qu'on appelle l'injection indirecte de prompts. L'autre type de risque provient directement de la requête de l'utilisateur lui-même, par exemple lorsque celui-ci demande à l'agent d'exécuter des opérations dangereuses ou non autorisées. Face à ces problèmes, les chercheurs déplacent progressivement la ligne de défense de l'intérieur du modèle vers la couche système, en insérant un Harness de sécurité entre le modèle et les outils, afin de restreindre le comportement réel via le contrôle des permissions, la vérification des appels d'outils et la surveillance des traces d'exécution.
Le problème réside dans le fait que les Harness existants sont pour la plupart conçus à l'avance par des experts, puis réutilisés pour différents modèles et environnements métier. Les capacités de résistance aux attaques varient considérablement d'un modèle à l'autre, et les risques à surveiller diffèrent selon les domaines. Le système de fichiers s'intéresse davantage à la circulation des commandes, des chemins et des données sensibles, tandis que le système financier implique la destination des fonds, l'ordre des transactions et l'état des comptes. Si l'on applique uniformément le même ensemble de règles, des restrictions trop laxistes ne parviennent pas à bloquer les attaques, tandis que des restrictions trop strictes nuisent aux tâches normales.
C'est dans ce contexte que l'équipe de recherche de l'Université Johns Hopkins, NVIDIA, l'Université de Californie à Berkeley et d'autres institutions a proposé EvoSafeHarness, faisant du Harness de sécurité lui-même un objet d'optimisation automatique. Pour différents modèles et domaines d'application, le système recherche séparément des politiques de sécurité en langage naturel et une logique de code exécutable, puis ajuste continuellement en fonction des échecs réellement exposés par le modèle. La recherche ne se limite pas à savoir si le taux de réussite des attaques peut être réduit, mais inclut également la question de savoir si l'agent peut toujours accomplir normalement ses tâches après l'ajout de la défense.
Les résultats de cette recherche, intitulés « EvoSafeHarness: Evolving Model- and Domain-Specific Harnesses for Securing Agents », ont été publiés sur la plateforme de prépublication arXiv.
Voir l'article :
https://hyper.ai/papers/2609.05903
4 types de benchmarks de sécurité couvrant 3 scénarios métier
Cette étude ne concentre pas l'évaluation sur un seul ensemble de données, mais utilise quatre types de benchmarks de sécurité pour agents : DecodingTrust-Agent, Agent-SafetyBench, AgentDojo / AgentDyn et AgentCanary. Ils couvrent respectivement les attaques transversales aux modèles et aux domaines, les problèmes de sécurité au-delà des appels d'outils, le transfert vers des environnements non vus, ainsi que les attaques adaptatives où l'attaquant ajuste activement ses stratégies.
Parmi eux, DecodingTrust-Agent Platform (DTAP) constitue la principale plateforme expérimentale. L'étude sélectionne trois scénarios parmi ses 14 domaines : le système de fichiers OS, la finance et les télécommunications, tout en testant à la fois les attaques directes et l'injection indirecte de prompts. Les objectifs malveillants des attaques directes proviennent de la requête de l'utilisateur elle-même, tandis que les attaques indirectes dissimulent des instructions dans des fichiers, des tickets, des enregistrements ou des messages. Chaque domaine comprend 60 tâches de recherche, dont 20 tâches normales, 20 attaques directes et 20 attaques indirectes ; 100 tâches de mise de côté indépendantes sont en outre utilisées pour le test final, et cette partie des données est inaccessible pendant le processus de recherche.
Agent-SafetyBench complète les risques au-delà des appels d'outils, comme les demandes dangereuses directement formulées par l'utilisateur, ou la propagation d'informations erronées par l'agent dans sa réponse finale. L'étude utilise 48 tâches pour la recherche, puis teste sur 240 tâches indépendantes respectivement l'environnement propre, la pollution contextuelle, l'injection indirecte, la falsification d'outils, l'injection de mémoire et les attaques combinées, formant ainsi 1 440 épisodes de test.
AgentDojo et AgentDyn servent à observer si la défense peut se transférer. Le Harness n'est recherché que sur AgentDojo, qui inclut des tâches bancaires, Slack, de voyage et d'espace de travail, puis est utilisé directement, sans modification, dans les environnements d'AgentDyn couvrant les achats, GitHub et la vie quotidienne. Étant donné que les outils et les flux de travail de ce dernier n'ont jamais participé à la recherche auparavant, cette configuration permet d'éviter de confondre « mémoriser des noms d'outils spécifiques » avec une véritable capacité de généralisation.
AgentCanary, quant à lui, augmente encore l'intensité des attaques. L'attaquant modifie continuellement ses prompts en fonction de la réponse réelle de l'agent au tour précédent, cherchant à découvrir de nouvelles voies de contournement. Ce qui est testé n'est donc plus seulement l'efficacité de la défense contre un lot fixe d'échantillons d'attaque, mais bien la capacité de sécurité que le Harness peut conserver face à un attaquant activement adaptatif.
EvoSafeHarness : gel du modèle cible, optimisation conjointe des politiques en langage naturel et du code exécutable
EvoSafeHarness ne procède à aucun ajustement de sécurité du grand modèle de langage cible ; les paramètres du modèle restent entièrement gelés pendant tout le processus de recherche. Ce qui change réellement, c'est le Harness situé entre l'utilisateur, le modèle et les outils, c'est-à-dire la logique de la couche système qui contrôle la manière dont les informations entrent dans le modèle, dont les appels d'outils sont exécutés et dont les résultats sont renvoyés.
La recherche divise le Harness en deux parties : une stratégie en langage naturel et un code exécutable. La stratégie en langage naturel sert principalement à préciser quelles informations sont fiables, comment le contenu externe doit être traité, et quelles situations nécessitent un refus ; le code exécutable peut directement vérifier, modifier ou bloquer les appels d'outils, tout en enregistrant les actions précédentes, en traçant les flux de données et, si nécessaire, en faisant appel à un modèle de jugement auxiliaire. Ainsi, une partie des contraintes de sécurité peut être directement appliquée au niveau de l'exécution, sans dépendre entièrement du fait que le modèle ait mémorisé les exigences contenues dans l'invite.
L'ensemble du processus de recherche est réalisé en collaboration par le Designer, le Criticizer, l'environnement de test en cascade (Cascade Test Environment) et l'Analyzer. Le Designer lit les spécifications du domaine, les Harness existants, les scores historiques et les traces d'exécution des échecs précédents du modèle, puis modifie le plan en conséquence. Les ajustements peuvent consister en une nouvelle règle, ou impliquer la méthode d'enregistrement des états, la position des vérifications ou l'ensemble du flux de contrôle.
La recherche automatique est sujette à un problème : le système peut involontairement apprendre à créer des règles spécifiquement pour l'ensemble de test. Par exemple, si un type d'attaque répète le même nom de fichier dangereux, ajouter directement ce nom de fichier à une liste noire peut rapidement améliorer le score, mais un attaquant peut le contourner en le renommant légèrement. Pour éviter ce surajustement, la recherche intègre un Criticizer indépendant. Il tente de modifier les chemins, de déplacer les fichiers ou de reformuler les instructions d'attaque afin de vérifier si la règle candidate reste efficace. Si la défense repose sur une chaîne de caractères spécifique plutôt que sur des relations relativement stables comme « cette action est-elle autorisée par l'utilisateur » ou « d'où provient cette information », le plan candidat doit être encore modifié.
Après validation, le Harness entre dans l'environnement de test en cascade. Les tests commencent par vérifier si le code s'exécute correctement avec un petit nombre de tâches, puis s'étendent progressivement ; les plans manifestement médiocres sont arrêtés prématurément afin de ne pas continuer à consommer des ressources d'évaluation. L'Analyzer enregistre séparément les performances sur les tâches normales, les attaques directes et les attaques indirectes, tout en sauvegardant les traces d'échec spécifiques, puis les transmet au Designer pour le cycle d'ajustement suivant.
Lors de l'évaluation, la recherche ne s'est pas uniquement intéressée au taux de réussite des attaques. Sinon, la solution de sécurité la plus simple serait de refuser toutes les opérations ; les attaques ne pourraient effectivement pas réussir, mais l'agent perdrait également toute utilité. EvoSafeHarness examine donc à la fois l'accomplissement des tâches normales et le succès des attaques. Ce n'est qu'en réduisant le taux de réussite des attaques tout en préservant fondamentalement les capacités opérationnelles que le plan candidat obtient une meilleure évaluation.
La recherche ne part pas non plus d'une page entièrement blanche. La recherche a extrait quelques expériences de base des méthodes de sécurité existantes, par exemple que la sortie des outils doit être considérée par défaut comme des données non fiables, et qu'avant d'exécuter une action, il convient de vérifier si elle est conforme à la demande initiale de l'utilisateur. Mais ces expériences ne servent que de point de départ ; la recherche ultérieure peut les conserver, les réorganiser ou les supprimer. Certains Harness finaux reposent encore principalement sur des stratégies en langage naturel, d'autres s'appuient davantage sur des règles programmatiques, et certains ajoutent un enregistrement d'état inter-étapes et un traçage des flux de données.
On voit ici aussi l'idée fondamentale de ce travail : les structures de risque dans les domaines des systèmes de fichiers, de la finance, des télécommunications, etc., ne sont pas identiques, et les habitudes comportementales du modèle lui-même influencent également la méthode de défense. Les systèmes de fichiers nécessitent de vérifier les commandes, les chemins et les flux de données sensibles ; les scénarios financiers se préoccupent davantage du sens des transactions, des flux de fonds et des relations entre plusieurs opérations. Plus précisément, certains modèles, après un refus, tentent à plusieurs reprises, d'autres cherchent des chemins alternatifs, et d'autres encore lancent plusieurs appels simultanés ; le Harness doit donc s'adapter différemment.
Prenons l'exemple du système de fichiers OS : face à une même instruction malveillante de copie de fichier, Sonnet 4.6 n'a besoin que d'un rappel sur la provenance et de quelques vérifications sémantiques ; GLM-5 nécessite en revanche d'ajouter des vérifications des commandes dangereuses, des emplacements sensibles, des informations confidentielles et des flux de données. Si l'on fixe GLM-5 et qu'on passe au scénario financier, le Harness se mettra à vérifier les sorties de fonds, les destinataires des paiements et l'historique des transactions, car le risque peut provenir de plusieurs opérations qui, prises individuellement, semblent normales mais dont la combinaison pose problème.
14 des 15 combinaisons « modèle × domaine » affichent les meilleures performances
Les chercheurs ont d'abord testé cinq modèles — Sonnet 4.6, GLM-5, Kimi-K2.5, Qwen3.7-plus et DeepSeek-V4-Flash — sur DTAP, et ont recherché un Harness dans trois domaines : système de fichiers OS, finance et télécommunications, formant ainsi 15 combinaisons « modèle × domaine ».
Sans défense, les cinq modèles présentent déjà de grandes différences de sécurité. Le taux de réussite moyen des attaques (ASR) de Sonnet 4.6 n'est que de 4,8 %, tandis que DeepSeek-V4-Flash atteint 71,0 %. L'efficacité des défenses fixes est également influencée par le domaine ; CaMeL et DRIFT performent relativement bien dans les systèmes de fichiers, mais voient leur capacité de défense nettement diminuer dans les scénarios financiers et de télécommunications.
EvoSafeHarness obtient le score composite le plus élevé dans 14 des 15 combinaisons. Le taux de réussite moyen des attaques passe de 45,6 % sans défense à 10,0 %, tandis que l'utilité des tâches normales ne diminue que de 3,3 points de pourcentage. En comparaison, les ASR moyens de CaMeL et DRIFT restent à 37,7 % et 42,4 % ; Progent parvient à réduire l'ASR à 10,5 %, mais l'utilité des tâches normales chute également à 56,4 %, contre 79,8 % pour EvoSafeHarness. En examinant séparément les deux types d'attaques, l'ASR des attaques directes passe de 50,9 % à 12,6 %, et celui des attaques indirectes de 40,4 % à 7,4 %.
Ces résultats correspondent aux différences entre les modèles évoquées précédemment. Face aux mêmes attaques sur le système de fichiers, Sonnet 4.6 parvient à obtenir un ASR plus faible grâce à un jugement sémantique plus léger, tandis que GLM-5 nécessite davantage de vérifications déterministes et de suivi d'état. Lorsque le domaine change, l'objet du jugement de sécurité évolue également : pour le système de fichiers, il s'agit principalement de vérifier si une action touche à des commandes dangereuses ou à des données sensibles ; dans le scénario financier, il faut en plus tenir compte de l'historique des transactions pour déterminer si plusieurs actions combinées constituent un délit de wash trading ou un retrait de fonds.
Sur Agent-SafetyBench, la recherche continue de tester les problèmes de sécurité qui ne se manifestent pas nécessairement par des appels d'outils. En moyenne sur les 3 modèles, le taux de comportements dangereux d'EvoSafeHarness est de 12,3 %, le taux de réussite des attaques de 7,4 %, et l'utilité des tâches en environnement hostile atteint 63,4 %. D'après les résultats, l'amélioration des indicateurs de sécurité ne s'accompagne pas d'un rejet massif et visible des tâches normales.
L'expérience de transfert, quant à elle, examine plus directement si le Harness dépend des outils vus lors de l'entraînement. EvoSafeHarness n'effectue de recherche que sur AgentDojo, où il obtient 82,8 % d'utilité et 0 % d'ASR ; en appliquant ensuite le même Harness directement à AgentDyn, il maintient 75,0 % d'utilité et 0 % d'ASR. CaMeL atteint également 0 % d'ASR sur AgentDyn, mais l'utilité des tâches normales chute en parallèle à 0 %, ce qui montre qu'il n'est pas difficile de tout bloquer d'un coup — la difficulté réside dans le fait de continuer à laisser l'agent accomplir son travail normal tout en se protégeant des attaques.
Lors des attaques adaptatives d'AgentCanary, en conditions d'attaque statique, l'ASR passe de 23,6 % à 9,7 %. À mesure que l'attaquant modifie ses invites en fonction des retours du système, le taux de réussite des attaques remonte ; avec un maximum de 16 itérations de modification autorisées, l'ASR moyen des 3 attaquants est de 19,5 %. Bien que certaines attaques aient trouvé de nouvelles contournements, la défense ne s'effondre pas rapidement face aux variations de formulation des attaques.
Enfin, la recherche effectue un test statistique sur les 1 050 tâches d'attaques appariées dans DTAP. Sur les 15 combinaisons modèle-domaine, 13 présentent une baisse significative du taux de réussite des attaques ; dans les 2 autres combinaisons, les modèles étaient déjà capables de repousser la grande majorité des attaques. Sur l'ensemble des tâches, EvoSafeHarness a bloqué 385 attaques qui auraient autrement réussi, et n'a ajouté que 11 nouveaux cas de réussite d'attaques, et les résultats statistiques indiquent que cette variation n'est pas due au hasard.
Parallèlement, les intervalles de confiance de l'utilité des tâches normales dans les 15 combinaisons chevauchent tous ceux de l'état sans défense. Autrement dit, l'amélioration de la sécurité observée dans l'article n'est pas obtenue en affaiblissant massivement les capacités des tâches normales. Pour les agents qui doivent réellement être déployés dans des environnements réels, cela importe davantage que la simple recherche d'un taux de réussite d'attaques plus bas.
Conclusion
EvoSafeHarness propose une approche différente du « garde-fou unifié » : une fois l'agent intégré dans un environnement métier concret, les contraintes de sécurité peuvent être redéfinies en fonction du comportement du modèle et des risques du domaine, plutôt que d'appliquer le même ensemble de règles à tous les systèmes. Cette recherche montre également que ce qui influence réellement l'efficacité de la défense n'est souvent pas le nombre de règles, mais leur adéquation aux risques réels, le bon positionnement des vérifications, et la capacité du système à conserver suffisamment de contexte d'état.
Bien entendu, cette approche a aussi ses limites : pour les risques qui se manifestent principalement au niveau du contenu, comme les erreurs factuelles ou les expressions trompeuses, en l'absence d'actions, de permissions ou de relations d'état directement vérifiables, un Harness au niveau système reste difficilement en mesure de tout résoudre. À mesure que les agents s'intègrent davantage aux systèmes métier réels, la question de savoir comment faire collaborer les capacités de sécurité propres du modèle, les règles de domaine et les contraintes d'exécution pourrait devenir un sujet de recherche de plus en plus pertinent.