Résumé technique : Sécuriser les agents LLM contre le désalignement par l'analyse de provenance

Énoncé du problème

Alors que les agents basés sur les grands modèles de langage (LLM) évoluent de simples assistants conversationnels vers des systèmes autonomes capables d'exécuter des actions irréversibles (par exemple, transférer de l'argent, modifier des fichiers), garantir que leurs actions sont alignées avec l'intention de l'utilisateur est crucial. Le document identifie le désalignement comme un phénomène où la proposition d'invocation d'un outil par un agent dévie de l'intention de l'utilisateur, non pas nécessairement en raison d'une intention malveillante, mais à cause d'incompréhensions ou d'hypothèses injustifiées concernant la requête de l'utilisateur.

Les garde-fous existants au moment de l'exécution reposent souvent sur un paradigme de « LLM-as-a-judge » (le LLM comme juge), où un seul prompt de LLM évalue si une action doit être autorisée. Les auteurs soutiennent que cette approche manque d'un cadre systématique pour raisonner sur l'alignement, ce qui entraîne des jugements incohérents, des rationalisations subjectives et des difficultés d'audit. De plus, les mesures de sécurité traditionnelles comme le sandboxing (bac à sable) limitent les conséquences plutôt que de prévenir l'action désalignée initiale, et la vérification post-hoc ne peut pas annuler les invocations d'outils irréversibles.

Méthodologie

1. Cadre conceptuel : Garde-fous basés sur la provenance

Inspirés par l'analyse de provenance (l'étude de l'origine et de l'historique de dérivation d'un artefact), les auteurs proposent un cadre où une action est considérée comme alignée uniquement si elle est soutenue par des preuves traçables au sein du contexte de l'agent. Le contexte comprend la requête de l'utilisateur ($q$), la documentation de l'outil ($d$) et l'historique des interactions ($h$).

Le cadre formalise la détection du désalignement en le catégorisant en trois types distincts, chacun correspondant à un échec dans l'établissement de relations de provenance spécifiques :

• Désalignement au niveau de l'outil : L'agent sélectionne un outil non pertinent pour la tâche.
  • Vérification de provenance : L'outil sélectionné ($t$) possède-t-il une documentation ($d_t$) qui est PertinentePour une sous-tâche ($s$) qui ContribueÀ la requête de l'utilisateur ($q$) ?
• Désalignement au niveau des paramètres : L'agent sélectionne le bon outil mais assigne des paramètres qui ne sont pas ancrés dans le contexte.
  • Vérification de provenance : L'assignation du paramètre ($a$) peut-elle être DérivéeDe preuves factuelles ($e$) apparaissant dans la requête ou l'historique ? De plus, l'outil instancié ($t$ avec $a$) PeutAdresser la sous-tâche ($s$) ?
  • Note : Le cadre distingue les paramètres dérivables (qui nécessitent une traçabilité de provenance) des paramètres génératifs (par exemple, rédiger le corps d'un e-mail), qui ne nécessitent pas de traçabilité directe de provenance.
• Désalignement au niveau de l'interprétation : L'agent résout une requête sous-spécifiée en s'engageant arbitrairement dans une interprétation alors que plusieurs interprétations plausibles existent.
  • Vérification de provenance : La proposition d'action est-elle la seule candidate admissible par la provenance compte tenu du contexte ? Si plusieurs actions distinctes sont soutenues par le contexte, la requête est sous-spécifiée, et s'engager dans l'une d'elles sans demande de clarification constitue un désalignement.

2. Implémentation : ProvenanceGuard

Les auteurs implémentent ce cadre sous la forme de ProvenanceGuard, un pipeline multi-étapes au moment de l'exécution qui intercepte les appels d'outils avant leur exécution. Contraقirement à un processus de décision en une seule étape de type « LLM-as-a-judge », ProvenanceGuard décompose la décision en trois étapes séquentielles :

1. Étape I (Niveau outil) : Filtre les outils modifiant l'environnement et vérifie si l'outil sélectionné est pertinent pour le plan de sous-tâche actuel de l'agent.
2. Étape II (Niveau paramètre) : Identifie quels paramètres sont dérivables et vérifie si leurs valeurs peuvent être tracées jusqu'au contexte et si elles instancient correctement l'outil pour la sous-tâche.
3. Étape III (Niveau interprétation) : Demande au LLM (sans révéler l'action choisie par l'agent pour éviter les biais) s'il existe d'autres actions admissibles par la provenance. Si plusieurs existent, l'action est bloquée car elle repose sur une hypothèse injustifiée.

Le système utilise un LLM pour évaluer les relations de provenance spécifiques (par exemple, RelevantTo, DerivedFrom), mais structure le processus de raisonnement pour qu'il soit plus explicite et auditable qu'un prompt holistique.

Contributions clés

1. Taxonomie du désalignement : Une distinction formelle entre le désalignement au niveau de l'outil, du paramètre et de l'interprétation.
2. Cadre basé sur la provenance : Un modèle conceptuel qui cadre la vérification de l'alignement comme la détermination de savoir si les appels d'outils sont ancrés dans des preuves traçables, formalisé par des relations binaires spécifiques.
3. ProvenanceGuard : Une implémentation du cadre sous forme de pipeline multi-étapes qui opère comme un garde-fou au moment de l'exécution.
4. Évaluation (Benchmarking) : Évaluation à travers deux benchmarks (Agent-SafetyBench et WorkBench) et 10 LLM de base, incluant un sous-ensemble annoté manuellement des traces d'Agent-SafetyBench.

Résultats expérimentaux

Les auteurs ont évalué ProvenanceGuard par rapport à une DirectPrompt Baseline (standard LLM-as-a-judge) et à un Single-step Provenance Prompt (ProvePrompt, qui utilise les concepts du cadre en une seule passe).

• Détection du désalignement (Taux d'erreur) :
  • Sur Agent-SafetyBench (axé sur la sous-spécification), ProvenanceGuard a réduit le taux d'erreur sur les traces désalignées de 42,9 % (Baseline) à 1,8 %.
  • Sur WorkBench, le taux d'erreur est passé de 32,1 % à 17,3 %.
  • La conception multi-étapes (ProvenanceGuard) a systématiquement surpassé la variante en une seule étape (ProvePrompt), particulièrement sur Agent-SafetyBench, suggérant la valeur de la décomposition du processus de raisonnement.
• Coût de l'intervention (Faux positifs/Interventions inutiles) :
  • Sur Agent-SafetyBench (traces alignées), ProvenanceGuard n'a pas introduit d'augmentation statistiquement significative des interventions inutiles par rapport à la baseline.
  • Sur WorkBench (traces de tâches réussies), ProvenanceGuard a significativement réduit le taux d'intervention de 30,5 % (Baseline) à 12,8 %, indiquant qu'il est plus précis que la baseline pour laisser les actions correctes se poursuivre.

Signification et affirmations

L'article affirme qu'un raisonnement structuré basé sur la provenance fournit une base efficace et pratique pour sécuriser les agents LLM. La signification réside dans :

• Raisonnement systématique : Passer de jugements subjectifs et holistiques à un cadre basé sur des liens de dépendance explicites et auditables entre l'action et le contexte.
• Gestion de la sous-spécification : Le cadre traite spécifiquement le risque que les agents fassent des hypothèses injustifiées sur des requêtes sous-spécifiées, une cause commune de désalignement que les filtres de sécurité standards ignorent souvent.
• Performance équilibrée : L'approche multi-étapes atteint une grande précision de détection des actions désalignées sans engendrer un coût prohibitif en termes de blocage des tâches valides et réussies de l'agent.

Les auteurs concluent que bien que le cadre ne puisse pas détecter le désalignement dans les paramètres purement génératifs (comme la génération de texte libre) et qu'il dépende du propre plan de l'agent (qui pourrait théoriquement être désaligné), il offre un mécanisme robuste pour prévenir les actions irréversibles et non ancrées dans le contexte dans les systèmes agentiques.