Quand un chatbot se trompe, on peut généralement le remarquer et reposer la question. Quand un agent autonome se trompe, l’erreur peut s’accumuler à travers les étapes, les outils et la mémoire avant que quiconque ne s’en aperçoive. C’est pourquoi une enquête de mai 2026 sur les défaillances d’agents importe pour quiconque déploie des agents sur des données et de l’argent réels.

Douze chercheurs dirigés par Jinhu Qi (dont Irwin King) ont publié "Towards Trustworthy Agentic AI: A Comprehensive Survey of Safety, Robustness, Privacy, and System Security" (arXiv:2605.23989 ; Academia AI and Applications, 2026). Ils cartographient les défaillances des systèmes agentiques, les défenses existantes et les failles qui subsistent.

Ce qui change quand le système agit, et pas seulement répond

Un modèle standard prend un prompt et renvoie du texte. Un agent prend un objectif et agit : il planifie, appelle des outils, stocke des résultats intermédiaires, enchaîne des actions et s’adapte à ce que lui renvoie l’environnement.

Cette conception crée des défaillances que les tests prompt-réponse ne détectent pas. Un seul appel d’outil malveillant peut empoisonner toutes les étapes suivantes. La mémoire peut stocker une fausse croyance et continuer à agir en conséquence. Des étapes anodines peuvent se combiner en un résultat nuisible. Le monde évolue au fur et à mesure que l’agent agit, et ces changements influencent la décision suivante.

Sécurité et robustesse

Ici, le risque est la trajectoire propre de l'agent. Les attaques ne sont pas seulement des invites utilisateur. Un document malveillant que l'agent lit en cours de tâche peut orienter le reste de l'exécution sans que l'utilisateur le sache. C'est une injection d'invite depuis l'environnement.

Le changement de distribution est plus grave pour les agents que pour les chatbots. Un chatbot confronté à un cas inconnu donne une réponse moins bonne. Un agent dans la même situation enchaîne des actions assurées qui peuvent aggraver la situation à chaque étape.

Le fossé des métriques

La plupart des benchmarks d'agents demandent encore si la tâche est terminée. Bien moins demandent si les contraintes ont été respectées tout au long. Un système peut « réussir » tout en enfreignant les règles à chaque exécution. Le hub de métriques unifiées de l'enquête est utile car il suit à la fois le résultat et le processus : réussite de la tâche, violations de contraintes, traces incomplètes, taux de succès des attaques.

Confidentialité et sécurité des systèmes

Ici l'adversaire contrôle une partie de l'environnement. L'étude documente de véritables défaillances dans les piles d'agents open source, pas seulement des attaques jouets.

La mémoire à long terme pose un problème de confidentialité que les chatbots évitent en grande partie. Un agent qui mène des recherches sur plusieurs tours peut accumuler des secrets, puis les divulguer via des appels d’outils ou des injections. L’empoisonnement de la mémoire (altération du contexte stocké pour orienter le comportement ultérieur) n’a pas d’équivalent propre en un seul tour.

Les configurations multi-agents élargissent le trou. Un agent compromis peut pousser des déchets via les canaux pairs normaux. Les filtres conçus pour les entrées utilisateur peuvent faire confiance aux agents pairs par défaut.

Ce qui reste non résolu

1
Agents auto-évolutifs. Les systèmes qui réécrivent leur propre comportement à partir de l'expérience peuvent laisser derrière eux leurs propriétés de sécurité originales. Les tests de systèmes fixes ne couvrent pas une cible mouvante. La vérification continue est encore mince.
2
Surveillance à l'exécution. La plupart des agents déployés manquent de vérifications continues des traces d’exécution par rapport aux règles de sécurité. Les tests de sortie ponctuels ne détectent pas les dérives entre sessions.
3
Mémoire utile sans coffre-fort qui fuit. Les agents ont besoin de contexte pour aider. La plupart des conceptions actuelles abandonnent soit la mémoire (et perdent en utilité), soit conservent une mémoire facile à exploiter.

L'objection populaire

L’objection la plus forte est que tout cela n’est que la cybersécurité d’hier avec une étiquette neuve : sandboxer les outils, journaliser les actions, livrer. C’est en partie vrai. Les bacs à sable et les journaux comptent. Mais l’enquête souligne que les agents introduisent des enchaînements longs, des attaques issues de l’environnement et des mécanismes de confiance entre pairs que les checklists classiques de sécurité applicative sous-estiment encore. Traiter le risque agent comme « juste une API de plus » est la meilleure façon de le rater.

Que faire de la carte

Les équipes qui placent déjà des agents sur des données clients, de l’argent ou des outils externes ont besoin de métriques de processus, de surveillance en temps réel et d’un examen indépendant de la conception des outils et de la mémoire, et pas seulement d’une évaluation de sortie qui vérifie si la tâche de démonstration a été accomplie.

Pour la Fondation, les cartes d’échec d’agent constituent une couche à court terme. Elles ne remplacent pas la tâche principale. Un monde qui court vers l’intelligence artificielle superintelligente a toujours besoin de limites contraignantes, règles de puissance de calcul et vérification afin que les capacités ne dépassent pas le contrôle. Utilisez l'enquête pour renforcer les agents que vous déployez maintenant. Utilisez la voie du traité afin que l'état final ne soit pas un agent que personne ne peut révoquer. Article complet: arXiv:2605.23989.