Empoisonnement de terminaison : piéger un agent LLM dans des boucles infinies

De quoi s’agit-il ?

Le 7 mai 2026, le papier LoopTrap: Termination Poisoning Attacks on LLM Agents (arXiv:2605.05846, cs.CR) a introduit une classe d’attaque visant une partie de la boucle d’agent que la plupart des défenses ignorent : le moment où l’agent décide qu’il a terminé.

Les agents modernes fonctionnent en boucle itérative — raisonner, agir, observer, puis s’auto-évaluer pour savoir si la tâche est complète. Le papier montre qu’en injectant du texte dans le contexte de l’agent, un attaquant peut corrompre cette auto-évaluation : l’agent conclut que la tâche n’est pas finie et continue. Le résultat n’est ni un vol de données ni une exécution de code, mais un calcul sans borne — tokens gaspillés, factures gonflées, capacité d’agent monopolisée. Les auteurs nomment cela empoisonnement de terminaison (Termination Poisoning) et rapportent que leur framework automatisé, LoopTrap, atteint une amplification moyenne de 3,57x sur 8 agents répandus, avec un pic à 25x.

Comment ça marche

La condition d’arrêt d’un agent est elle-même un jugement du LLM : après chaque étape, le modèle relit la trajectoire et répond, en substance, « l’objectif est-il atteint ? ». Comme ce jugement consomme la même fenêtre de contexte que les sorties d’outils, les documents récupérés et les pages web non fiables, il hérite de la faiblesse fondamentale de toute injection : il n’existe aucune frontière entre données et instructions.

L’empoisonnement de terminaison exploite précisément cela. Du contenu adverse placé là où l’agent le lira — une réponse d’API, un fichier, un résultat web — est conçu pour pousser la décision « avons-nous fini ? » vers non. Le papier caractérise 10 stratégies représentatives et constate que les agents ont des signatures comportementales distinctes : un piège qui boucle un agent peut n’avoir aucun effet sur un autre. LoopTrap en fait du red-teaming : il établit d’abord un profil comportemental de la cible selon quatre dimensions de vulnérabilité par sondage léger, puis synthétise un piège spécifique, note les candidats et raffine les échecs.

Aucun payload n’est reproduit ici. Le mécanisme est l’essentiel : le contrôle de complétion de l’agent est une surface d’attaque, orientable comme l’injection indirecte oriente la sélection d’outils.

Boucle normale :        Boucle empoisonnee :
  raisonner               raisonner
  agir                    agir
  observer                observer  <- injecte "tu n'as pas fini"
  fini ? -> OUI (stop)    fini ? -> NON (encore... et encore)

C’est l’image inverse des attaques de ressources connues. Là où le drainage de tokens par chaîne d’outils et le DoS par raisonnement de garde-fou gonflent le coût d’une seule décision, l’empoisonnement de terminaison attaque le nombre d’itérations — et l’idée n’est pas nouvelle : Johann Rehberger signalait les boucles coût/DoS des LLM dès 2023.

Pourquoi c’est important

La disponibilité et le coût sont de vraies propriétés de sécurité pour les systèmes autonomes. Un agent coincé dans une boucle empoisonnée brûle des dépenses d’API facturées à l’usage, occupe un emplacement de traitement dont les tâches légitimes ont besoin, et peut épuiser silencieusement les budgets avant que quiconque ne s’en aperçoive. À 25x d’amplification, un seul document forgé transforme une tâche en l’équivalent de vingt-cinq. Pour des flottes d’agents traitant des entrées non fiables — tri d’e-mails, gestion de tickets, recherche web — c’est un vecteur de déni de service et de « déni de portefeuille » que les filtres d’entrée classiques, réglés pour l’exfiltration ou l’injection de commandes, ne surveillent pas.

Cela sape aussi une hypothèse de sûreté courante : qu’un agent laissé en marche finira par s’arrêter. Si la terminaison peut être manipulée de l’extérieur, « il finira tout seul » n’est pas un contrôle.

Défenses

Le correctif est architectural — ne jamais laisser du contenu non fiable arbitrer le moment où l’agent s’arrête.

1. Imposer des limites externes strictes. Plafonnez les itérations, le temps d’horloge, le total de tokens et d’appels d’outils par tâche dans l’orchestrateur, hors du jugement du modèle. C’est la mitigation la plus efficace : la boucle doit être bornée par du code, pas par l’avis du LLM.
2. Rendre la terminaison déterministe quand c’est possible. Pour les tâches structurées, vérifiez la complétion par des critères de succès explicites et vérifiables par machine plutôt que de demander au modèle « as-tu fini ? ».
3. Budgéter et mesurer par tâche. Fixez des plafonds de tokens/coût par tâche avec alertes, et échouez de façon sûre dès qu’une tâche dépasse son enveloppe attendue — un nombre d’étapes aberrant est un signal d’anomalie fort.
4. Séparer données non fiables et raisonnement de contrôle. Gardez les sorties d’outils et le texte récupéré dans des zones clairement délimitées et de moindre confiance, et évitez d’injecter du contenu non fiable brut dans l’étape d’évaluation de complétion. C’est la logique de confinement décrite dans le confinement d’injection à la vitesse machine.
5. Surveiller la distribution des étapes. Suivez le nombre d’itérations par tâche sur toute la flotte ; une amplification soudaine sur certaines entrées signale une tentative d’empoisonnement.
6. Red-teamer la condition d’arrêt. Testez les agents de façon adverse pour le comportement de boucle, pas seulement pour la fuite de données — la grille du lethal trifecta devrait inclure « capacité à consommer des ressources sans borne ».

Statut

Élément	Référence	Date	Notes
Publication du papier	arXiv:2605.05846 (v1)	2026-05-07	Définit l’empoisonnement de terminaison ; 10 stratégies
Périmètre empirique	Évaluation LoopTrap	2026-05-07	8 agents répandus, 60 tâches
Impact rapporté	LoopTrap	2026-05-07	3,57x d’amplification moyenne, pic à 25x
Antériorité (boucles coût/DoS LLM)	Embrace The Red	2023-09-16	Alerte précoce sur l’abus de boucle infinie

La leçon est simple et ancienne : une boucle autonome que vous ne bornez pas est une boucle qu’un attaquant peut borner à votre place. La terminaison est une décision de contrôle : traitez-la comme telle — imposez-la dans le code, pas dans un prompt.