Loopjacking : quand l'opération validée n'est pas celle qui s'exécute

De quoi s’agit-il ?

La validation humaine — le human-in-the-loop — est le garde-fou vers lequel tout le monde se tourne. Quand un agent s’apprête à virer de l’argent, supprimer un bucket ou lancer une commande shell, la réponse consensuelle est : affichez l’opération à une personne et attendez son clic. Un papier soumis à arXiv le 17 septembre 2026 et annoncé dans la liste cs.CR du 21 septembre 2026 — Loopjacking: Hijacking Human-in-the-Loop Approval (arXiv:2609.21081), signé Adithyan Arun Kumar — pose la question qui suit : l’opération relue par un humain est-elle bien celle que le système exécute ensuite ?

Dans plusieurs produits d’agents déjà publiés, rapporte l’auteur, elle ne l’est pas. Le papier nomme cette classe de défaillance Loopjacking : un humain valide ce qu’il comprend comme l’opération A, tandis que la logique du produit utilise cette décision pour autoriser une opération B matériellement différente. La validation est réelle, le clic est authentique, le journal d’audit indique qu’un humain a dit oui — et l’effet qui atteint le point d’exécution est tout autre.

Comment ça marche

Le papier énonce un invariant de liaison d’approbation : une décision ne peut autoriser une opération que si l’opération complète évaluée au moment de l’usage est matériellement équivalente à celle que l’humain a relue, et tant que la décision reste valide pour le principal, la tâche et le périmètre courants. « Opération complète » signifie l’action, chaque argument matériel, la ressource cible, le principal et le périmètre de tâche, ainsi que tout contexte d’exécution susceptible de modifier l’effet. Deux façons de rompre cet invariant sont distinguées.

• Loopjacking par représentation. B est déjà encodé dans la requête avant la décision, mais le produit affiche ou canonicalise un A matériellement incomplet. La validation est exacte — pour le mauvais objet. Le cas du wrapper shell l’illustre proprement : l’événement d’approbation ne représentait que la charge utile en ligne, alors que le vecteur complet d’arguments positionnels, préparé avant l’approbation, portait les arguments supplémentaires sélectionnant la vraie commande et la vraie destination.
• Substitution d’état post-approbation. L’humain voit et valide exactement A. Avant que la décision ne soit consommée, un acteur disposant d’une capacité étroite de mise à jour d’état mute la tâche, le fil ou l’état de continuation en attente vers B. L’exécution évalue alors le B courant tout en conservant la décision prise pour A.

Le modèle d’attaquant est délibérément modeste. Aucun contrôle du modèle, aucune course contre le validateur, aucune confirmation forgée : seulement une asymétrie d’autorité — un initiateur de tâche peu privilégié, un contributeur de dépôt ou un agent distant capable de mettre à jour un état en attente mais qui ne pourrait jamais invoquer B directement. L’auteur exclut explicitement les cas où B s’exécute avant toute décision, où l’invite de validation est contournée, ou encore où un humain valide sciemment un B visible. Les expériences mesurent la liaison système, pas la susceptibilité humaine : le rôle de validateur est scripté et ne procède qu’après que le test a constaté et enregistré la vue produit exacte de A.

Quatre chemins produits ont été évalués, comme un ensemble raisonné et non comme un échantillon. La substitution post-approbation a été reproduite sur sept points de version d’Agno AgentOS jusqu’à la 3.0.9 incluse, où une route de continuation vérifie l’identité de l’appel mais ne compare pas les arguments d’outil courants au descripteur du dossier approuvé. Elle a également été reproduite sur douze versions d’une composition conditionnelle de LangGraph Agent Server en mémoire, jusqu’à la 0.14.0, via la surface de mise à jour de commande A2A livrée, sous une politique d’autorisation où un initiateur peut mettre à jour un fil partagé en attente mais non le reprendre. Le décalage de représentation a été reproduit sur OpenClaw 2026.2.23 et rejeté par la 2026.2.24, qui a ajouté un contrôle de cohérence sur le vecteur d’arguments complet.

Le résultat le plus utile est le témoin négatif. Le SDK OpenAI Agents 0.22.0 et 0.22.2 a rejeté la mutation à chaque essai : la continuation sérialisée préserve une liaison exacte par appel, et une invocation au même identifiant modifiée vers B a levé une erreur, le registre restant vide. La continuation et la sérialisation ne sont donc pas, en elles-mêmes, la cause de la défaillance — la liaison l’est.

Pourquoi c’est important

La validation est le garde-fou sur lequel les organisations s’appuient précisément quand les enjeux sont les plus élevés, et c’est le seul qui survive à tout modèle de menace bâti sur l’hypothèse « le modèle peut être compromis ». Le Loopjacking s’attaque à la plomberie située en dessous. Trois raccourcis de liaison sont désignés comme insuffisants : ne lier qu’un identifiant d’appel, quand un réducteur peut remplacer les arguments attachés à cet identifiant ; ne lier qu’un drapeau « approuvé » au niveau du run, quand une continuation peut installer une exécution d’outil différente ; et ne vérifier qu’au moment de l’affichage, quand l’état peut changer avant la dépêche. Ces trois raccourcis sont courants, et tous trois produisent un système qui paraît correct en démonstration.

Un second résultat, convergent, mérite d’être lu en parallèle. Silence Is Endorsement: Verification-Status Laundering in LLM Agent Pipelines (arXiv:2609.20211), soumis le 25 juillet 2026 et annoncé dans la liste du 18 septembre 2026, examine le même écart un étage plus haut, là où c’est un moniteur LLM et non un humain qui fait office de garde-barrière. Lorsque la mention indiquant qu’une revendication d’autorisation était non vérifiée est effacée — par un résumeur, un compresseur de mémoire, un simple passage de relais — l’approbation d’actions risquées passe, dans les expériences rapportées, de 5 % à 60 % sur Llama-3.1-8B et de 9 % à 98 % sur Qwen2.5-14B, un pipeline complet proposeur–résumeur–mémoire–moniteur atteignant 57 à 81 % sur trois moniteurs en aval. Instruire explicitement les moniteurs de rejeter une autorisation non vérifiée n’est pas, selon l’étude, un correctif fiable d’un modèle à l’autre.

Les deux papiers pointent dans la même direction. Les décisions d’autorisation dans les systèmes d’agents circulent aujourd’hui comme du texte et des drapeaux dans des pipelines à perte, alors qu’elles devraient circuler comme un état structuré lié à l’effet exact.

Défenses

La prescription du papier tient en une règle : conservez l’opération que l’humain a validée, reconstruisez l’opération qui va réellement s’exécuter, et comparez leurs descripteurs canoniques complets au dernier point d’autorisation — après tout parsing, templating, réduction d’état, continuation, insertion de valeurs par défaut, expansion de wrapper et résolution d’arguments.

Rendez le dossier d’approbation canonique. Il doit lier l’identité de l’action ou de l’outil et chaque argument matériel, la ressource cible et la classe d’effet de bord, le principal initiateur et le périmètre de tâche, le principal validateur, un nonce avec date de création, expiration et statut de consommation, ainsi qu’une empreinte du descripteur complet présenté à l’humain. L’affichage doit être généré à partir de ce descripteur, et non d’une chaîne de commodité pendant que l’exécution utilise un objet plus riche.

Faites la vraie vérification au moment de l’usage, pas au moment du rendu. La procédure proposée, juste avant de libérer l’effet : rejeter si la décision est absente, expirée, révoquée, consommée ou hors périmètre ; rejeter ou redemander une validation si l’opération courante diffère matériellement du descripteur approuvé ; réévaluer la politique courante sur l’effet résolu ; consommer la décision de façon atomique avec la libération de l’effet, ou enregistrer un jeton de commit idempotent empêchant le rejeu ; consigner descripteur approuvé, descripteur courant, décision et effet dans un enregistrement d’audit.

Accordez une attention particulière aux wrappers shell et commandes. Charges utiles en ligne, arguments positionnels, modifications d’environnement, répertoire de travail, drapeaux d’interpréteur et redirections modifient tous l’effet. Une vue condensée peut rester utile, mais l’approbation doit soit exposer les champs matériels masqués, soit refuser de les autoriser.

Traitez la prévention des mutations comme de la profondeur, pas comme la réponse. Interdire à un non-validateur de mettre à jour un fil partagé en attente a bloqué la variante par substitution d’état dans la composition LangGraph testée, et cela vaut la peine d’être fait là où les rôles métier le permettent. C’est spécifique à la composition, et cela ne remplace pas la liaison exacte à l’action partout où des mises à jour légitimes, des reprises ou des migrations peuvent modifier l’état de l’opération.

Testez-le en régression, à chaque version. Capturez la vue d’approbation et la requête complète, mutez un champ matériel via chacune des surfaces post-relecture supportées, et vérifiez l’opération exacte au point d’exécution. Suite minimale : A inchangé réussit ; un refus n’a aucun effet ; B direct est indisponible à l’attaquant ; une substitution A vers B est rejetée ou re-autorisée ; un périmètre erroné échoue ; une approbation consommée ou expirée ne peut être rejouée.

Transportez la provenance d’autorisation comme un état structuré. La conclusion de l’étude compagnon s’applique aux moniteurs LLM autant qu’aux humains : le fait qu’une revendication ait été vérifiée ou non doit voyager attaché à la revendication, dans un champ qu’un résumeur ne peut pas silencieusement supprimer.

Status

Aspect	Détail
Source principale	Loopjacking: Hijacking Human-in-the-Loop Approval (arXiv:2609.21081), soumis le 17 septembre 2026, annoncé le 21 septembre 2026
Classe	Défaillance de liaison d’approbation — la décision n’est pas liée à l’opération évaluée au moment de l’usage
Variantes	Par représentation (vue incomplète à l’approbation) ; substitution d’état post-approbation (état en attente muté avant consommation)
Reproduit	Substitution post-approbation : sept points de version d’Agno AgentOS jusqu’à 3.0.9 ; douze versions d’une composition conditionnelle de LangGraph Agent Server en mémoire jusqu’à 0.14.0. Décalage de représentation : OpenClaw 2026.2.23
Corrigé / rejeté	OpenClaw 2026.2.24 (contrôle de cohérence sur le vecteur d’arguments complet). SDK OpenAI Agents 0.22.0 / 0.22.2 en témoin négatif — mutation rejetée à chaque essai
Sans correctif établi	Le papier indique qu’aucune version corrigée d’Agno ni aucune version LangGraph corrigée par l’éditeur n’est établie à sa date de clôture ; le contrôle exact-action sur Agno est écrit par le chercheur, et le résultat sûr sur LangGraph repose sur une politique supportée interdisant la mise à jour
Réserves de périmètre	Ensemble raisonné et non aléatoire ; résultats spécifiques à une configuration et à une version ; aucune estimation de prévalence ; aucun CWE ni CVSS attribué ; un seul chercheur, pas de reproduction indépendante ; déploiement Postgres de production non évalué
Travaux liés	Silence Is Endorsement (arXiv:2609.20211), soumis le 25 juillet 2026, annoncé le 18 septembre 2026 — le même écart de liaison là où le garde-barrière est un moniteur LLM
Clôture de l’étude	Preuves et revue des sources publiques arrêtées au 10 septembre 2026