AuthGraph : alignement à double graphe contre l'injection sur agents

De quoi s’agit-il ?

AuthGraph est un cadre défensif pour les agents LLM outillés, décrit dans un préprint arXiv (2605.26497, cs.CR) publié le 26 mai 2026 par Peiran Wang et ses collègues de l’UCLA. Il vise l’injection de prompt indirecte : l’attaque par laquelle un agent lit une source de données externe qu’il ne contrôle pas — un e-mail, une page web, un fichier — et où cette source porte des instructions cachées qui le poussent à une action non autorisée, comme virer des fonds vers un compte contrôlé par l’attaquant.

La thèse du papier est que les défenses existantes partagent un angle mort structurel. Les vérificateurs de valeurs d’appel d’outil inspectent les arguments sans suivre leur origine. Les analyseurs de graphe de trace construisent un seul graphe de l’exécution et l’inspectent a posteriori — mais si l’injection a déjà manipulé l’agent pendant la construction de ce graphe, le graphe enregistre fidèlement la vue manipulée, sans rien à quoi la comparer. La contribution d’AuthGraph est de construire un second graphe indépendant, que l’injection ne peut atteindre, et de détecter l’attaque en comparant les deux.

Comment ça marche

AuthGraph construit deux graphes complémentaires sur une même tâche d’agent. Le premier est le graphe de raisonnement injecté (IRG) : la provenance de l’information reconstruite à partir de la trajectoire d’exécution réelle, délibérément exposée à tout ce que l’agent a lu, y compris le contenu injecté. Il enregistre la « vue subjective » de l’agent sur l’origine de chaque valeur — manipulation comprise.

Le second est le graphe d’autorisation. Il est dérivé de l’intention initiale de l’utilisateur dans un contexte isolé et propre qui ne voit jamais les données non fiables. Les auteurs décrivent cette référence comme impossible à influencer par injection au sens de la théorie de l’information : le planificateur qui la construit n’est tout simplement pas exposé aux octets contrôlés par l’attaquant. Ce graphe opère au niveau de la source des paramètres (il contraint non seulement quels outils peuvent s’exécuter, mais d’où chaque argument a le droit de provenir), respecte le moindre privilège et reste extensible à l’exécution.

Un vérificateur d’alignement de graphes compare alors structurellement les deux. Parce que le graphe d’autorisation est une référence infalsifiable de « ce que l’agent devrait faire » et que l’IRG capture « ce que l’agent a réellement fait », un écart révèle l’injection — au niveau de l’outil (une action jamais autorisée) comme au niveau de la source du paramètre (une action autorisée dont l’argument a été silencieusement tiré de données empoisonnées). Surtout, le verdict final repose sur les preuves brutes de la trajectoire, et non sur un LLM raisonnant sur un texte potentiellement empoisonné.

L’exemple fil rouge est un appel frauduleux book_flight(flight_id="EVIL-123") : une vérification de valeur appel par appel ou une trace à graphe unique ne peut détecter que le flight_id a été injecté, alors qu’une comparaison structurelle avec une base d’autorisation propre le peut.

Pourquoi c’est important

C’est le problème du député confus au cœur de la sécurité des agents : l’agent est autorisé à agir, mais les données qu’il a consultées ont été corrompues, si bien qu’il exécute fidèlement un plan avec des paramètres choisis par l’attaquant. C’est le même trio létal — données privées, contenu non fiable et canal d’action externe dans une seule tâche — que Simon Willison documente de longue date.

Les chiffres rapportés justifient l’attention. Sur le benchmark AgentDojo, AuthGraph fait chuter le taux de succès d’attaque de 40 % à 1 % tout en conservant 76 % de complétion de tâche sur GPT-4o ; sur AgentDyn, il passe de 39 % à 2 % de succès d’attaque en préservant 51 % d’utilité. Les auteurs annoncent surpasser des défenses récentes de type plan-puis-vérification et contrôle de flux d’information, dont CaMeL, DRIFT et Progent. La surface concernée est tout agent qui lit du contenu accessible à un attaquant et peut ensuite agir : paiements, e-mails, déploiements, écritures de fichiers.

Défenses

L’enseignement pour les équipes est architectural et dépasse cette implémentation précise. Dérivez une spécification d’autorisation à partir de l’intention de l’utilisateur avant que l’agent ne touche aux données non fiables, et maintenez cette spécification dans un contexte où ces données ne peuvent jamais entrer — une base de référence sans injection n’est fiable que si elle est structurellement isolée, et non simplement priée d’ignorer les instructions. Suivez la provenance au niveau de la source des paramètres, et pas seulement par appel d’outil, pour qu’une valeur issue d’une entrée empoisonnée ne devienne pas discrètement l’argument d’une action sensible. Fondez la décision finale d’autoriser ou de refuser sur les preuves de la trajectoire plutôt que sur un modèle résumant un texte déjà potentiellement compromis. Ces idées prolongent la direction « traçabilité et moindre privilège » de travaux voisins comme les défenses à graphe de provenance et les design patterns pour sécuriser les agents LLM (Beurer-Kellner et al., juin 2025), qui soutiennent que l’injection de prompt doit être contenue architecturalement plutôt que résolue au niveau du modèle.

Limites à garder à l’esprit avant de s’y fier : AuthGraph est une couche de détection et d’alignement évaluée sur des benchmarks, pas un produit déployé ; elle suppose de pouvoir dériver un graphe d’autorisation fidèle en contexte propre et de reconstruire la provenance depuis la trajectoire ; et le succès d’attaque résiduel est réduit, pas nul. Elle contient et détecte la manipulation plutôt que d’empêcher un modèle d’être manipulé au départ.

Statut

Le travail est un préprint du 26 mai 2026 (arXiv:2605.26497v1) de l’UCLA, évalué sur les benchmarks d’injection AgentDojo et AgentDyn avec GPT-4o et comparé à CaMeL, DRIFT et Progent. Aucun CVE n’y est associé, car AuthGraph décrit une défense, pas une vulnérabilité. Les équipes qui exploitent des agents en production peuvent adopter dès maintenant le principe sous-jacent — une base d’autorisation isolée, au niveau de la source des paramètres, comparée structurellement à la provenance d’exécution — indépendamment de ce prototype particulier.