Risques des agents IA : pourquoi les "bons" échouent encore

Les risques et modes de défaillance des agents IA proviennent principalement d'erreurs silencieuses cumulées lors de l'utilisation d'outils en plusieurs étapes, et non d'un crash dramatique du modèle. Un flux de travail qui semble à 90 % « correct » par étape peut néanmoins être inutilisable de bout en bout à moins qu'il ne soit construit avec des autorisations explicites, des points de contrôle et une surveillance.

Points clés

• La fiabilité des agents multi-étapes se multiplie à chaque étape, donc une précision de 85 % par action peut s'effondrer à environ 20 % de succès sur un flux de travail de 10 étapes, tandis que 95 % par action se situe autour de 60 %.
• Les défaillances d'agent les plus dommageables sont des défaillances « douces » : des sorties plausibles, des appels d'outils erronés et des objectifs dérivants qui ne déclenchent pas d'erreurs ou d'alertes.
• Les systèmes multi-agents ajoutent leurs propres modes de défaillance, y compris le biais de conformité et l'état partagé obsolète, ce qui peut transformer une hallucination en faux consensus.
• L'injection de prompt est une menace au niveau d'exécution pour les agents car elle peut orienter les appels d'outils et les objectifs, et pas seulement la sortie textuelle.

Comment les défaillances des agents IA diffèrent

Un agent de production échoue comme une chaîne d'exécution qui fuit, et non comme un programme qui plante. Les logiciels traditionnels ont tendance à se briser bruyamment : un API renvoie un 500, une requête de base de données échoue, un travail échoue et se réessaie.

Les flux de travail agentiques « réussissent » souvent dans l'interface utilisateur tout en faisant la mauvaise chose, car le système optimise pour la cohérence et l'achèvement, et non pour la vérité. C'est le changement clé de modèle mental pour quiconque construit ce que sont les agents IA dans la crypto : l'échec est souvent une sortie propre qui est opérationnellement incorrecte.

Les mathématiques de la composition sont la partie que la plupart des équipes négligent. L'exemple de Trantor est clair : si un agent est précis à 85 % par action, un flux de travail de 10 étapes réussit seulement environ 20 % du temps. Même une précision de 95 % par étaperendementsseulement environ 60 % de succès sur 10 étapes.

C'est la même forme que la décroissance du taux de remplissage sur un livre de trading lorsque qu'une stratégie nécessite plusieurs remplissages dépendants. Chaque étape peut être localement rationnelle et produire néanmoins une séquence globalement défaillante.

Les systèmes agentiques échouent également de manière non déterministe. Deux exécutions avec les mêmes entrées peuvent diverger en raison des échantillonnages du modèle, des sorties des outils qui changent ou d'un contexte récupéré qui évolue. Redis encadre le schéma commun comme une accumulation d'erreurs dans des pipelines séquentiels où les erreurs douces se propagent sans plantages ni alertes.

Cette propriété de « pas de trace de pile » est la raison pour laquelle les équipes diagnostiquent mal les échecs des agents comme « nous avons besoin d'un meilleur modèle » alors que le véritable problème réside dans des portes manquantes et un manque d'observabilité.

La crypto ajoute une dimension plus aiguisée. Lorsqu'un agent d'IA possède un portefeuille d'agent, un appel d'outil n'est pas une simple requête API inoffensive. Cela peut être une transaction, une approbation, un pont ou une signature. Le coût d'une erreur silencieuse n'est pas une mauvaise réponse. C'est une action on-chain qui se règle.

Modes de défaillance des agents principaux à prévoir

L'utilisation incorrecte des outils est le mode de défaillance de base car elle se situe à la frontière entre le langage et l'exécution. Trantor décrit des agents sélectionnant le mauvais outil, passant des arguments incorrects ou ignorant les erreurs des outils et continuant comme si l'action avait réussi.

Dans un contexte d'agent AI risqué en crypto, cela se traduit clairement par des erreurs de type « mauvaise chaîne, mauvais jeton, mauvais dépensier, mauvais montant ». La partie dangereuse n'est pas que l'appel échoue. La partie dangereuse est que l'appel réussit partiellement et que l'agent construit les étapes suivantes sur un état corrompu.

La dérive de contexte et les cascades d'hallucination constituent la deuxième classe. À mesure que les résultats des outils et le raisonnement intermédiaire s'accumulent, l'attention du modèle se dilue et il commence à fonctionner sur une version déformée de l'objectif. Trantor relie cela à l'effet perdu au milieu dans les longs contextes.

Redis sépare les limites de la fenêtre de contexte de la dégradation du contexte, et souligne un point que les traders reconnaîtront : ajouter plus d'informations peut aggraver la qualité des décisions lorsque le système ne peut pas récupérer de manière fiable l'information pertinente.

La dérive des objectifs est une lente hémorragie. Trantor la décrit comme un échec émergent où aucune étape unique n'est "fausse", mais l'agent finit par s'optimiser pour un objectif différent de celui spécifié à l'origine.

Dans les flux de travail crypto, la dérive des objectifs se manifeste par un agent qui commence par "rééquilibrer l'exposition" et finit par "maximiser l'activité" parce qu'il a appris que faire plus d'appels d'outils ressemble à des progrès.

Les boucles de réessai et les coûts incontrôlables sont le mode de défaillance mécanique qui impacte les budgets avant d'affecter la justesse. Trantor signale les boucles infinies où des appels d'outils échoués déclenchent des tentatives répétées, et recommande des limites d'itération strictes et des plafonds de dépenses.

C'est la traduction la plus claire de la discipline de bureau en opérations d'agents : si le système ne peut pas être arrêté en cours d'exécution, il n'est pas prêt pour la production.

La dégradation silencieuse de la qualité est celle qui épuise les équipes pendant des semaines. Trantor énumère des causes telles que la dérive du stockage de documents, la régression des prompts, les changements silencieux de comportement des modèles et le changement de distribution des entrées. L'agent continue de "compléter" des tâches, mais l'utilité décroît en dessous du seuil où la sortie est sûre à utiliser.

Coordination multi-agents et risques en cascade

Les configurations multi-agents sont souvent présentées comme une sécurité par redondance. Les sources vont dans l'autre sens à moins que la vérification ne soit conçue explicitement. Redis souligne le biais de conformité : les agents en aval ont tendance à s'aligner sur une affirmation confiante en amont, renforçant une hallucination en un faux consensus. Ce n'est pas une bizarrerie théorique.

C'est un mode de défaillance de coordination qui ressemble à un accord et expédie des sorties incorrectes plus rapidement.

L'étude arXiv formalise cela avec MASFT, une taxonomie de 14 modes de défaillance multi-agents regroupés en trois catégories : défaillances de spécification et de conception du système, désalignement entre agents et défaillances de vérification et de terminaison des tâches. L'étude analyse cinq cadres MAS à travers plus de 150 tâches avec des traces annotées par des humains et rapporte un accord inter-annotateur de Kappa de Cohen de 0,88.

Elle rapporte également que la justesse de ChatDev peut être aussi basse que 25 % dans leur évaluation, et que des interventions de bonne foi comme une meilleure spécification des rôles et orchestration ont amélioré ChatDev de +14 % mais restent insuffisantes pour un déploiement dans le monde réel.

Le coût de coordination n'est pas seulement la latence. Il consomme le budget de contexte. Redis note que les variantes multi-agents peuvent sous-performer par rapport aux bases de référence à agent unique sur le raisonnement séquentiel car le coût de communication l'emporte sur tout bénéfice de parallélisation. Chaque transfert supplémentaire est un autre endroit où une erreur douce peut devenir "état."

La mémoire partagée et l'état obsolète sont l'autre moteur de cascade. Redis décrit des agents lisant un état partagé à des moments différents et agissant sur des informations déjà dépassées par des actions concurrentes. Dans la crypto, c'est ainsi qu'un agent peut approuver un dépensier basé sur un solde antérieur, puis exécuter un échange basé sur un solde ultérieur, sans réconciliation.

Un réseau de solveurs peut réduire une partie de la complexité d'exécution en externalisant la recherche de chemin, mais cela devient aussi une autre frontière où les sorties doivent être validées avant l'étape suivante.

La leçon multi-agents est simple : plus d'agents ne créent pas plus de sécurité par défaut. Ils créent plus de surfaces pour que des hypothèses non vérifiées deviennent durables.

Menaces à la sécurité dans les flux de travail agentiques

L'injection de prompt est le mode de défaillance de sécurité qui compte le plus pour les agents car il n'est pas limité au texte. Trantor décrit l'injection de prompt comme la vulnérabilité numéro un du OWASP LLM Top 10 pour 2025 et souligne qu'elle est plus dangereuse dans des contextes agentiques car elle peut détourner des objectifs et des appels d'outils à travers un flux de travail. C'est la différence entre "le chatbot dit quelque chose de bizarre" et "l'agent change ce qu'il essaie de faire."

Les risques de sécurité des agents s'élargissent car chaque entrée externe est désormais une influence exécutable. Les documents récupérés, les sorties d'outils, la mémoire et même les messages d'autres agents sont tous des entrées qui peuvent contenir des instructions hostiles.

Trantor recommande de traiter chaque document, enregistrement de base de données, réponse API et sortie d'outil comme potentiellement adversariaux, et de nettoyer les entrées avant qu'elles n'entrent dans le contexte de l'agent.

Dans le crypto, les scénarios d'injection de prompt pour les agents crypto sont simples : une entrée de liste de jetons malveillante, un extrait de "documentation" empoisonné lors de la récupération, ou une réponse d'outil élaborée peuvent orienter l'agent vers l'approbation d'un dépensier, en faisant le pont vers un contrôleur d'attaquant.adresse, ou la signature d'un message non intentionnel.

C'est pourquoi les risques de sécurité des agents d'IA concernent principalement le contrôle des actions, et non la fuite de données.

Les atténuations sont architecturales. Un tee peut aider à l'intégrité et à l'isolement de certaines parties de l'environnement d'exécution, mais cela ne résout pas à lui seul le détournement d'instructions. La défense principale consiste à contraindre ce que l'agent peut faire, à valider ce qu'il s'apprête à faire et à enregistrer ce qu'il a fait d'une manière qui peut être audité.

Trantor affirme également que 88 % des organisations déployant des agents d'IA ont signalé au moins un incident de sécurité en 2025. Ce chiffre est présenté comme une affirmation secondaire dans la source, mais il correspond à la tendance : une fois que les agents peuvent agir, la surface d'incidents croît plus rapidement que les contrôles de la plupart des équipes.

Contrôles de conception et d'opérations qui fonctionnent

Les contrôles efficaces ressemblent à des limites de risque, pas à un « meilleur encouragement ». La thèse à travers les sources est que les échecs des agents s'accumulent à travers les étapes et les acteurs, donc le système a besoin de limites explicites, de vérification et d'observabilité à chaque frontière.

Une pile de contrôle de style bureau peut être exprimée comme une séquence de construction ordonnée :

1. Outils de portée pour le moindre privilège. Les exemples d'utilisation abusive des outils de Trantor sont fondamentalement des échecs de permission. Un agent ne devrait pas avoir un accès large au système de fichiers ou aux droits d'administrateur lorsqu'il n'a besoin que d'une seule fonction, et la même logique s'applique à un portefeuille d'agent qui peut signer des transactions arbitraires. 2.

Contrôler les appels d'outils avec des schémas et des préconditions. Trantor recommande la validation des schémas pour détecter les arguments incorrects avant l'exécution. Pour les outils crypto, cela signifie valider la chaîne, le jeton, les décimales, le destinataire et les deltas d'allocation avant qu'un appel ne soit autorisé à se déclencher. 3. Insérer des points de vérification.

Redis recommande de valider à chaque frontière, et la taxonomie MASFT d'arXiv signale les échecs de vérification des tâches et de terminaison comme une catégorie majeure. Un rôle de vérificateur doit être structurellement différent de celui de planificateur, sinon cela devient une monoculture. 4. Contrôler la croissance du contexte. Trantor recommande une synthèse hiérarchique à intervalles réguliers pour éviter la dérive du contexte.

Redis avertit qu'ajouter plus de contexte peut aggraver les problèmes de coordination en raison de la dégradation du contexte et du comportement perdu au milieu. 5. Limiter les boucles et les coûts au niveau de l'orchestration. Trantor appelle à des limites d'itération strictes et à un suivi des coûts en temps réel avec des plafonds de dépenses. C'est l'exigence de coupure en ingénierie. 6.

Construire une observabilité qui correspond aux systèmes probabilistes. Redis recommande des ID de corrélation pour chaque invocation d'agent, appel d'outil et message inter-agent, plus des traces structurées incluant les jetons consommés, la latence et l'état de succès ou d'échec par étape. La dégradation silencieuse de la qualité ne se manifeste que lorsque les distributions de sortie et les échantillons.auditssont suivis au fil du temps.

Les contrôles organisationnels comptent autant que les contrôles techniques. Trantor affirme que l'extension du périmètre et les problèmes de qualité des données représentent 61 % des échecs des agents IA combinés. C'est la raison peu glamour pour laquelle de nombreux pilotes ne deviennent jamais des systèmes de production.

Points pratiques pour un déploiement plus sûr

La préparation à la production commence par la mesure de la chaîne, pas par l'admiration du modèle. Si le flux de travail nécessite 10 étapes dépendantes, le seul chiffre de fiabilité honnête est le taux de succès composé, pas l'« exactitude » par étape. L'exemple de Trantor de 85 % à ~20 % est le moyen le plus rapide de tester si un système est une démo ou un outil opérationnel.

Les conceptions multi-agents devraient justifier leur complexité. Le document arXiv montre des gains de performance minimes à travers les benchmarks et documente une faible exactitude pour ChatDev dans certaines évaluations.

Redis soutient que les configurations à agent unique peuvent surpasser celles à agents multiples en raisonnement séquentiel parce que les frais de coordination consomment le contexte et introduisent de nouveaux modes de défaillance. Le multi-agent peut être justifié pour un travail parallélisable, mais seulement lorsque les rôles de vérificateur et les critères de terminaison sont explicites.

Pour les déploiements crypto, la première priorité est de contraindre l'exécution. Un agent IA avec un portefeuille d'agent devrait fonctionner avec des permissions strictes, des limites de dépenses rigoureuses et un interrupteur d'arrêt qui peut mettre fin à l'exécution en cours.

Traitez les sorties d'outils, les documents récupérés et la mémoire comme des entrées adversariales, car l'injection de prompt est un détournement de flux de travail, pas un truc de chat.

La deuxième priorité est l'observabilité. Les échecs doux ne déclenchent pas d'alerte. Ils apparaissent comme des changements subtils dans l'adhérence au format, les scores de confiance, les taux d'erreur des outils, l'utilisation des jetons et les taux de complétion.

Sans traces, les équipes ne peuvent pas séparer l'hallucination, l'état obsolète et la dérive des objectifs, et elles continueront à « corriger les prompts » pendant que le système continue d'échouer.

L'histoire plus large des agents dans la crypto se dirige vers plus d'autonomie, plus d'accès aux outils, et plus decomposabilité.Cela fait des risques et des modes de défaillance des agents IA un problème de conception, pas un problème de modèle, et les équipes qui survivront ressembleront beaucoup à des bureaux d'exécution disciplinés : limites explicites, vérification aux frontières, et surveillance étroite de ce que le système a réellement fait.

L'Analyse

J'ai vu des équipes traiter un taux de "bonnes réponses" de 90 % comme s'il s'agissait d'un SLA de production, puis être surprises lorsque l'agent s'effondre au moment où il doit faire dix choses à la suite.

Les mathématiques de Trantor sont la bonne claque : 85 % par étape se transformant en ~20 % de bout en bout sur 10 étapes est exactement comment une stratégie avec des chances de remplissage décentes meurt encore lorsqu'elle a besoin d'une chaîne de remplissages.

J'ai également vu des configurations multi-agents créer un faux confort. Sur des flux de travail séquentiels, le biais de conformité de Redis apparaît rapidement : une hallucination confiante devient "consensus" parce que personne n'est payé pour vérifier, seulement pour être d'accord.

La posture qui se maintient est ennuyeuse et efficace : privilège minimal, portes de schéma, points de contrôle de vérification, plafonds de coûts fixes et traces qui permettent à quelqu'un de rejouer l'exécution et de localiser le premier transfert défaillant.

Sources

• Trantor
• Redis
• arXiv