AGrail : Des garde-fous de sécurité adaptatifs pour les agents LLM qui apprennent à travers les tâches

J'ai suivi de près la course aux armements des garde-fous pour les agents LLM — GuardAgent en 2024, ShieldAgent à l'ICML 2025 — et AGrail (Luo et al., ACL 2025) est l'étape suivante que je devais lire. Il s'attaque à l'écart de scalabilité qu'aucun de ses prédécesseurs n'a résolu : que se passe-t-il lorsqu'un système de garde-fou unique doit protéger des agents à travers de nombreuses tâches différentes, chacune avec son propre vocabulaire de politique et sa propre surface de risque, sans être pré-programmé pour chacune d'elles ?

L'article

Weidi Luo, Shenghong Dai, Xiaogeng Liu, Suman Banerjee, Huan Sun, Muhao Chen et Chaowei Xiao présentent AGrail — « Un garde-fou d'agent à vie avec une détection de sécurité efficace et adaptative » — publié dans la section des articles longs de l'ACL 2025. Le problème central est double : les agents LLM sont confrontés à des risques spécifiques aux tâches définis par l'administrateur (ex. : « ne pas supprimer de fichiers dans ce répertoire ») et à des risques systémiques provenant de vulnérabilités de conception (injection de prompt, attaques environnementales), et les garde-fous existants gèrent au mieux l'une de ces catégories et nécessitent une spécification manuelle de la politique par tâche. La réponse d'AGrail est un système coopératif à deux LLM — un Analyseur et un Exécuteur — qui génère, teste et affine de manière itérative les contrôles de sécurité au moment de l'inférence via l'adaptation au temps de test (TTA), en stockant les contrôles affinés dans un module de mémoire qui transfère l'apprentissage aux tâches futures.

Idées clés

• Coopération entre deux LLM : L'Analyseur récupère les contrôles de sécurité pertinents de la mémoire, les révise et propose des ensembles de contrôles mis à jour. L'Exécuteur évalue chaque contrôle proposé — décidant s'il faut invoquer un outil externe, s'appuyer sur son propre raisonnement ou rejeter un contrôle redondant. Cette boucle s'exécute de manière itérative jusqu'à ce que l'ensemble des contrôles converge.
• Mémoire avec incitation par recul (step-back prompting) : Les actions sont stockées à la fois en langage naturel et sous forme de commandes d'outils en utilisant l'incitation par recul. Lors de l'inférence, seule la forme en langage naturel est affichée (pour éviter les interférences de la syntaxe brute des commandes), mais les deux sont utilisées pour la récupération. La mémoire converge vers la quatrième itération TTA, avec une similarité cosinus de plus de 98 % sur différentes graines aléatoires.
• Benchmark Safe-OS : Les auteurs introduisent un nouvel ensemble de données de 100 scénarios simulant des interactions réelles d'agents avec un système d'exploitation via Docker — 23 injections de prompt, 30 sabotages de système, 20 attaques environnementales et 27 cas normaux — car aucun benchmark existant ne combinait les trois types de risques systémiques.
• 96 % de préservation des actions bénignes pour un taux de succès d'attaque (ASR) par injection de prompt de 0 % : Sur Safe-OS avec Claude-3.5-Sonnet, AGrail ne bloque que 4,4 % des actions bénignes (95,6 % de préservation) tout en atteignant un taux de succès d'attaque de 0 % contre l'injection de prompt. Les modèles de base concurrents bloquent jusqu'à 49,2 % des actions bénignes.
• Résultats sur les risques spécifiques aux tâches : Sur Mind2Web-SC (agent web), AGrail atteint un F1=94,1 avec 95,8 % de concordance. Sur EICU-AC (confidentialité des soins de santé), F1=98,5 avec 100 % de concordance.
• Instabilité des modèles faibles : GPT-4o-mini utilisé comme moteur principal montre une instabilité à travers les séquences d'entrée ; Claude-3.5-Sonnet est nécessaire pour des performances fiables, ce qui constitue un prérequis de calcul implicite que l'article minimise.

Ce qui tient la route — et ce qui ne la tient pas

Le résultat qui m'impressionne le plus est la comparaison des faux positifs : GuardAgent et LLaMA-Guard bloquent jusqu'à 49,2 % des actions légitimes de Safe-OS. C'est une catastrophe en termes d'utilisabilité — un garde-fou qui signale la moitié du travail normal est un garde-fou que personne ne laissera activé. Le taux de blocage de 4,4 % d'AGrail sur les actions bénignes est nettement meilleur.

Cela dit, plusieurs lacunes méritent d'être soulignées. Premièrement, les chiffres concernant les attaques par injection environnementale (EIA) sont moins reluisants que les affirmations principales : l'ASR de génération d'actions est de 28 % — plus d'une attaque sur quatre réussit à passer. L'article occulte ce point par rapport au résultat de 0 % sur l'injection de prompt. Deuxièmement, le modèle de menace est étroit : Safe-OS couvre trois types d'attaques, mais l'article n'évalue pas les chaînes de raisonnement adverses qui contourneraient entièrement l'Analyseur, ni les cas où un contexte suffisamment long pousserait le module de mémoire vers des contrôles antérieurs erronés. Troisièmement, l'aspect apprentissage continu nécessite que l'agent rencontre des actions similaires de manière répétée pour que la mémoire converge — le résultat de convergence à la quatrième itération est valable dans la configuration contrôlée de l'article, mais il n'est pas évident de savoir à quelle vitesse la mémoire se stabilise lorsque les distributions d'actions sont très variées. Quatrièmement, le surcoût computationnel lié à l'exécution de deux LLM plus les itérations TTA par étape de l'agent n'est jamais quantifié. Dans les applications sensibles à la latence, ce coût compte.

Les auteurs reconnaissent honnêtement qu'ils dépendent de LLM généralistes plutôt que de modèles de garde-fous spécialisés, et que l'invocation d'outils est minimale. Ce qu'ils ne discutent pas, c'est la façon dont les propositions de contrôle de politique de l'Analyseur pourraient elles-mêmes être empoisonnées par un adversaire qui comprendrait le pipeline d'incitation par recul.

Pourquoi cela est important pour l'IA financière

La taxonomie des risques spécifiques aux tâches + risques systémiques s'applique directement aux agents comptables. Un agent d'écriture Beancount est confronté à des risques spécifiques aux tâches (règles de l'administrateur : « ne jamais valider sur une période verrouillée », « toujours exiger une approbation par deux parties pour les transactions supérieures à 10 000 $ ») ainsi qu'à des risques systémiques (une note malveillante dans un mémo de transaction qui injecte des instructions). L'approche d'AGrail est plus naturelle pour ce cas d'utilisation que les circuits de règles formels de ShieldAgent, car les comptables formulent les politiques en langage clair, et non en logique du premier ordre.

L'aspect apprentissage continu est particulièrement pertinent. Un déploiement unique pourrait protéger des dizaines de registres distincts — chacun ayant des politiques de plan comptable différentes, des limites d'exercice fiscal différentes, des hiérarchies d'approbation différentes. La capacité de transférer des contrôles de sécurité d'un registre à un autre, en les affinant via TTA plutôt qu'en repartant de zéro, pourrait réduire de manière significative la charge de configuration par registre. La question de savoir si l'implémentation actuelle atteint réellement cet objectif à l'échelle d'une véritable plateforme comptable multi-tenant reste sans réponse dans l'article — ses évaluations couvrent trois tâches d'agent distinctes, et non des dizaines.

Le taux d'échec de 28 % de la génération d'actions EIA est le chiffre sur lequel je reviens sans cesse. Pour un agent comptable, une attaque réussie de génération d'actions adverses signifie qu'une écriture de journal incorrecte est validée. Ce n'est pas récupérable sans un audit manuel. Un garde-fou qui échoue à 28 % contre les attaques EIA nécessiterait une couche de vérification secondaire — ce qui nous ramène au débat sur le multi-agent et aux conceptions de vérification formelle des lectures précédentes de cette liste.

Que lire ensuite

• M3MAD-Bench (arXiv:2601.02854) — l'audit le plus complet pour savoir si le débat multi-agent aide réellement à travers les modalités et les tâches ; directement pertinent si la conception LLM coopérative d'AGrail est envisagée pour les pipelines financiers.
• ShieldAgent (arXiv:2503.22738, ICML 2025) — l'approche de vérification formelle à laquelle AGrail est implicitement comparé ; lire les deux côte à côte clarifie le compromis entre adaptativité et garanties formelles.
• Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — combine l'analyse de processus STPA avec MCP pour produire des spécifications de sécurité exécutoires pour les agents appelant des outils, le complément existant le plus systématique à la vérification au moment de l'exécution d'AGrail.