Boucles d'agent infinies : détecter les feedback paths non bornés

De quoi s’agit-il ?

Les agents LLM modernes fonctionnent en boucle : ils planifient, appellent un modèle, invoquent un outil, lisent le résultat, mettent à jour leur état et décident de l’étape suivante — en répétant jusqu’à ce que la tâche soit terminée. Un article publié sur arXiv le 2 juillet 2026, When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents (2607.01641), nomme la défaillance qui survient lorsque cette boucle ne s’arrête jamais : une boucle d’agent infinie (Infinite Agentic Loop, IAL).

Une IAL n’est pas un simple while(true) de programmation. Elle émerge de l’interaction entre la logique de l’agent, la sémantique du framework, les observations au runtime et les mécanismes de terminaison. Une seule requête utilisateur peut être amplifiée en une série non bornée d’appels au modèle, d’invocations d’outils, de transitions de workflow ou de passages de main entre agents — provoquant, selon les auteurs, épuisement des coûts, déni de service du modèle, croissance du contexte et effets de bord externes répétés. La contribution de l’article est défensive : une définition de cette classe de défaillance, plus un analyseur statique, IAL-Scan, qui détecte ces boucles dans le code avant le déploiement.

Pour mesurer l’ampleur du problème, les auteurs ont exécuté IAL-Scan sur 6 549 dépôts d’agents réels. L’outil a remonté 74 candidats, dont une revue manuelle a confirmé 68 véritables défaillances IAL réparties sur 47 projets, pour une précision annoncée de 91,9 %.

Comment ça marche

Le constat gênant est que la plupart des frameworks concernés embarquent déjà des mécanismes de contrôle de boucle — max_iterations de LangChain, la limite de récursion de LangGraph, le plafond de tours maximal de l’OpenAI Agents SDK, max_iter de CrewAI — et que les IAL surviennent malgré tout. Selon l’article, les développeurs omettent ces bornes, les utilisent mal, les configurent avec des valeurs inefficaces, ou les placent en dehors du feedback path réel, si bien qu’elles ne se déclenchent jamais. Pire, certaines conditions de terminaison sont sémantiquement fragiles : la poursuite de la boucle est en fin de compte décidée par les sorties du modèle, les observations des outils, l’état externe, les exceptions ou les choix de délégation, qu’un compteur fixe ne contraint pas de façon fiable.

Détecter cela statiquement est difficile pour trois raisons que l’article pointe. Le comportement de l’agent s’exprime à travers des interfaces de framework plutôt que par des appels directs au niveau du code source, si bien que le même concept « appeler le modèle » ou « dispatcher un outil » se cache derrière des API différentes. Une seule boucle peut traverser de nombreux éléments de programme et de framework — prédicats de routage, gestionnaires de retry, mises à jour de messages, passages de main entre agents — de sorte que le feedback path doit être reconstruit à travers le code d’enrobage et la logique du framework. Et la vraie question n’est pas « une limite existe-t-elle ? » mais « une borne effective couvre-t-elle le chemin répété ? », puisque les boucles sont normales et souvent légitimes dans les agents.

IAL-Scan y répond en transformant du code d’agent hétérogène en une Agent IR indépendante du framework, en construisant un Agentic Loop Dependence Graph (ALDG) qui reconstitue à la fois les boucles explicites et les feedback paths induits par le framework, puis en vérifiant si un chemin atteignable peut atteindre de façon répétée des opérations coûteuses ou faisant croître l’état sans borne qui le couvre réellement. L’outil prend en charge huit frameworks d’agents grand public. Aucun exploit ni payload d’attaque n’est publié — il s’agit d’une étude de mesure et d’un détecteur, la même posture « cartographier la surface de défaillance » que dans l’analyse par graphe de dépendances d’agents, et distincte de l’empoisonnement de terminaison adverse, où un attaquant empêche délibérément un agent de s’arrêter.

Pourquoi c’est important

Une boucle non bornée est un problème de déni de service et de coût qui n’a pas besoin d’un attaquant pour se déclencher — une tâche malformée, un outil instable ou un modèle qui « réessaie » sans fin suffisent. Dans un déploiement facturé à l’usage, cela se traduit directement par des factures d’API et du temps GPU qui s’emballent ; dans un service multi-locataires, cela peut affamer les autres utilisateurs. Les 47 projets confirmés montrent qu’il s’agit d’une propriété structurelle de la façon dont on construit les agents aujourd’hui, et non d’une poignée de dépôts bogués.

L’angle sécurité se durcit dès que la boucle a des effets de bord. Un feedback path qui rappelle sans cesse un outil externe peut envoyer le même e-mail, ouvrir le même ticket ou solliciter le même endpoint payant des centaines de fois ; un contexte qui grossit sans borne finit par dégrader le raisonnement du modèle lui-même. Cette classe de défaillance correspond exactement à OWASP LLM10:2025, Unbounded Consumption, élargie depuis l’ancienne entrée « Model Denial of Service » précisément pour couvrir l’expansion récursive du contexte et les coûts incontrôlés — et elle aggrave les risques d’épuisement de ressources déjà documentés dans l’assèchement de jetons par chaîne d’outils et le déni de service par raisonnement de garde-fou.

Défenses

Traitez tout feedback path d’agent comme quelque chose qui doit être borné de façon prouvable, et placez la borne sur le chemin, pas à côté.

Ne comptez pas sur le fait que la limite par défaut d’un framework suffise. Vérifiez que max_iterations, les limites de récursion ou les plafonds de tours sont bien définis, avec des valeurs effectives, et qu’ils se situent à l’intérieur de la boucle qu’ils sont censés contraindre plutôt qu’autour d’un enrobage externe qui ne réentre jamais. Bornez plus que le nombre d’itérations : imposez des budgets globaux sur le cumul de jetons, le temps d’horloge, les appels d’outils et la dépense totale par requête, et déclenchez un disjoncteur dès que l’un est dépassé. Considérez la poursuite pilotée par le modèle comme non fiable — si la répétition de la boucle dépend de la sortie du modèle, du résultat d’un outil ou d’une décision de délégation, ajoutez une condition d’arrêt externe indépendante plutôt que de faire confiance à l’agent pour décider de s’arrêter. Rendez les actions externes répétées idempotentes ou dédupliquées, afin qu’une boucle qui se déclenche deux fois ne double ni la facturation ni l’envoi. Instrumentez pour repérer la signature au runtime : des appels d’outils successifs quasi identiques, un contexte qui croît de façon monotone et un compteur d’itérations qui tend vers le plafond sont autant de signaux précoces. Enfin, exécutez en CI une analyse statique du type de celle que démontre cet article, en recherchant spécifiquement les feedback paths qui atteignent des opérations coûteuses sans couverture de borne effective — la même discipline de « shift-left » prônée dans tout le cycle de vie de la sécurité des agents.

Statut

Élément	Détail
Divulgation	Préprint arXiv 2607.01641, 2 juillet 2026 (étude de mesure + détecteur)
Nature	Boucles d’agent infinies — feedback paths non bornés provoquant épuisement des coûts, déni de service du modèle, croissance du contexte, effets de bord répétés
Détecteur	IAL-Scan — Agent IR indépendante du framework + Agentic Loop Dependence Graph (ALDG) + vérification de couverture de borne ; 8 frameworks pris en charge
Échelle	6 549 dépôts d’agents réels scannés ; 74 candidats, 68 défaillances IAL confirmées sur 47 projets ; 91,9 % de précision
Concernés	Agents bâtis sur LangChain, LangGraph, CrewAI, OpenAI Agents SDK et frameworks itératifs similaires
Classe	OWASP LLM10:2025 — Unbounded Consumption

Ces résultats reflètent l’étude citée. Un analyseur statique remonte des chemins non bornés faisables, pas des pannes avérées en production — validez les boucles signalées au regard de votre propre déploiement et de ses bornes configurées avant de conclure sur un agent précis.