GuardAgent : Application déterministe de la sécurité pour les agents LLM via l'exécution de code

Le problème central de sécurité pour tout agent avec droit d'écriture est le suivant : comment l'empêcher de prendre une action qu'il n'était jamais censé prendre ? GuardAgent (Xiang et al., ICML 2025) propose un agent garde-fou dédié — un agent LLM séparé qui vérifie chaque action de l'agent cible par rapport à un ensemble de politiques de sécurité avant son exécution. Pour Bean Labs, où la question de savoir si « l'agent peut écrire dans le grand livre sans violer les règles comptables ? » est non négociable, cet article se situe au cœur de notre programme de recherche.

L'article

GuardAgent : Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning, par Zhen Xiang et ses collègues de l'UIUC, Emory et UC Berkeley, introduit ce que les auteurs affirment être le premier agent garde-fou polyvalent pour les systèmes LLM. L'idée de base est simple : plutôt que d'intégrer des contraintes de sécurité directement dans le prompt de l'agent cible (où elles peuvent être ignorées ou oubliées), GuardAgent fonctionne comme un agent indépendant qui intercepte les actions de l'agent cible et les vérifie par rapport aux politiques énoncées.

Le mécanisme comporte deux étapes. Premièrement, le LLM lit la politique de sécurité et l'entrée ou la sortie proposée par l'agent cible, puis rédige un plan d'action étape par étape décrivant ce qu'il faut vérifier. Deuxièmement, il convertit ce plan en code Python exécutable à l'aide d'une boîte à outils prédéfinie de fonctions appelables. Un interpréteur Python externe exécute le code, produisant un verdict déterministe oui/non. Un module de mémoire stocke les triplets de tâches passés (politique, plan, code) et récupère des exemples antérieurs similaires en utilisant la distance de Levenshtein, permettant un apprentissage en contexte (few-shot) sans aucun réglage fin supplémentaire. L'article évalue l'approche sur deux nouveaux benchmarks introduits par les auteurs.

Idées clés

• L'exécution de code l'emporte sur les verdicts en langage naturel. Lorsque les décisions de sécurité sont rendues sous forme de code plutôt que de texte LLM, le résultat est déterministe : le moteur Python autorise ou bloque, sans risque d'hallucination lors de l'étape de décision finale. Le LLM doit seulement générer un code correct, et non une réponse finale correcte.
• Deux benchmarks personnalisés. EICU-AC (316 exemples) teste le contrôle d'accès pour EHRAgent sur une base de données de santé avec trois rôles d'utilisateur et dix bases de données. Mind2Web-SC (200 exemples) teste six politiques de sécurité pour l'agent web SeeAct. Les deux ont été créés par les auteurs spécifiquement pour cet article.
• Précision de l'étiquetage de 98,7 % et 90,0 % (GPT-4) sur EICU-AC et Mind2Web-SC respectivement. De manière critique, la précision de la réponse finale — à savoir si l'agent cible termine toujours sa tâche lorsqu'il devrait y être autorisé — reste à 100 % dans les deux contextes.
• Les règles de sécurité codées en dur échouent lamentablement. L'intégration des politiques directement dans le prompt système de l'agent cible n'atteint que 81,0 % / 77,5 % de précision sur les deux benchmarks, et provoque l'échec de l'agent cible dans 29,2 % / 71,0 % de ses tâches légitimes — un compromis utilité-sécurité inacceptable.
• LlamaGuard n'est pas l'outil approprié ici. La base de référence de modération de contenu atteint environ 50 % de précision — proche du hasard — car elle a été conçue pour le texte nuisible, et non pour raisonner sur la violation d'une règle spécifique de contrôle d'accès par une action d'un agent.
• La suppression de la boîte à outils coûte environ 8 points. Sans la bibliothèque de fonctions appelables, GuardAgent passe de 98,7 % à 90,8 % sur EICU-AC, bien qu'il compense partiellement en définissant de manière autonome les fonctions nécessaires (68 % des sorties génèrent du code même sans instruction explicite, ce que les auteurs considèrent comme une preuve de la pertinence de la conception basée sur la génération de code).

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

L'idée architecturale centrale — l'exécution de code offre un point d'application déterministe — est véritablement utile, et les analyses d'ablation sont honnêtes. La comparaison avec les règles de sécurité codées en dur est particulièrement convaincante : elle montre que les conceptions naïves de type « ajoutez simplement des règles au prompt » dégradent l'utilité de la cible tout en échouant à appliquer la sécurité de manière fiable.

Mais l'évaluation présente des limites réelles. Les deux benchmarks sont de petite taille (316 et 200 exemples), et les auteurs ont construit les deux, ce qui crée un risque évident de surapprentissage (overfitting). EICU-AC est essentiellement une matrice de contrôle d'accès (rôle × base de données), ce qui est un problème structuré et énumérable — le genre de chose pour lequel le code est naturellement doué. Mind2Web-SC est plus complexe, et le chiffre de 90,0 % y est considérablement moins impressionnant qu'il n'y paraît au premier abord : les auteurs reconnaissent que la règle 5 (couvrant « les films, la musique et les vidéos ») cause le plus d'échecs car elle nécessite un raisonnement large sur le monde réel. C'est le genre de règle à laquelle un véritable agent financier serait constamment confronté.

Le module de mémoire récupère des démonstrations par similarité de chaînes de caractères, ce qui fonctionne bien pour des types de politiques répétés mais se dégradera sur des politiques véritablement nouvelles. De plus, l'ensemble du cadre suppose un « contexte de confiance » — les politiques de sécurité elles-mêmes doivent être fournies par un administrateur de confiance. Si un attaquant peut modifier les politiques, ou si la boîte à outils contient des fonctions non sécurisées, GuardAgent n'offre aucune protection. L'article ne modélise pas la manipulation adverse des politiques. Des travaux ultérieurs (ShieldAgent, arXiv:2503.22738 ; AGrail, arXiv:2502.11448) ont déjà mis en évidence ces lacunes, ShieldAgent signalant une amélioration moyenne de 11,3 % par rapport à GuardAgent sur des benchmarks plus larges.

Pourquoi cela est important pour l'IA financière

L'agent d'écriture Beancount a besoin de plus qu'un prompt de sécurité — il a besoin d'un mécanisme pour appliquer les règles comptables qui soit structurellement séparé de l'agent effectuant le travail. L'architecture de GuardAgent s'y prête directement : un agent de garde qui vérifie chaque écriture comptable proposée par rapport aux règles comptables (débit == crédit, pas d'écriture sur des périodes clôturées, pas de modification de transactions rapprochées) avant l'exécution de l'écriture. La couche d'application par exécution de code est particulièrement attrayante ici car l'arithmétique en partie double est exactement le type de vérification structurée et énumérable que le code gère de manière fiable et que le texte LLM ne gère pas.

La limite honnête est que GuardAgent suppose que vous pouvez énumérer vos politiques de sécurité à l'avance et les encoder dans une boîte à outils. Dans les déploiements Beancount en production, certaines contraintes sont implicites (respect des conventions du grand livre que l'utilisateur a établies au fil des ans) et d'autres sont dynamiques (les budgets changent, les structures de comptes sont restructurées). GuardAgent ne vous dit pas comment gérer les contraintes qui ne peuvent pas être spécifiées à l'avance. C'est le problème le plus difficile, et il reste ouvert.

Que lire ensuite

• ShieldAgent (arXiv:2503.22738, ICML 2025) — s'appuie sur GuardAgent avec un raisonnement vérifiable sur les politiques de sécurité et ShieldAgent-Bench (2 000 exemples dans six environnements web) ; signale une amélioration de 11,3 % par rapport à GuardAgent et une réduction de 64,7 % des appels d'API.
• AGrail (arXiv:2502.11448) — propose des contrôles de sécurité adaptatifs qui se transfèrent entre les tâches des agents plutôt que de nécessiter des démonstrations par tâche ; répond directement à la limitation de scalabilité de GuardAgent.
• ToolSafe (arXiv:2601.10156) — garde-fous proactifs au niveau de l'étape avec retour d'information pour les agents appelant des outils ; plus granulaire que le modèle d'interception entrée/sortie de GuardAgent.