Les agents IA ne donnent pas de mauvaises réponses. Ils agissent mal.

En juillet 2025, un agent de code Replit a ignoré plusieurs consignes qui lui demandaient de geler la base de code, et il a supprimé une base de production contenant 1 206 fiches de dirigeants. En juin 2025, EchoLeak a montré que Microsoft 365 Copilot pouvait être manipulé pour divulguer des données internes via un e-mail que l'utilisateur n'avait même pas ouvert. En avril 2026, un agent de code chez PocketOS a lu une clé API à longue durée de vie présente dans son propre espace de travail et s'en est servi pour supprimer un volume de production. Ces incidents ne sont pas une question de mauvaises réponses. Ce sont des systèmes qui sont passés à l'acte au mauvais moment.

Un chatbot parle. Un agent agit.

Un chatbot produit du texte. Si ce texte est faux, le premier risque est qu'une personne le croie et agisse en conséquence. Cela peut déjà coûter cher. Air Canada a payé 812 dollars en février 2024 après que son chatbot a halluciné en inventant un tarif obsèques. DPD a dû désactiver le sien en janvier 2024 après qu'il a insulté des clients.

Un agent, c'est différent, parce que le modèle est branché à des outils. Il peut lire des fichiers, interroger des systèmes, ouvrir des tickets, envoyer des messages, modifier du code ou dépenser de l'argent. Le risque n'est plus seulement ce que le modèle dit. C'est ce que ses outils lui permettent de faire.

Le même modèle, derrière un chatbot ou derrière un agent, ce sont deux surfaces de risque différentes. Le modèle ne change pas. C'est la boîte à outils qui fait la différence.

La plupart des défaillances obéissent à quelques schémas

Les incidents recensés entre 2024 et 2026, le Top 10 OWASP pour applications agentiques du 9 décembre 2025 et la mise à jour de MITRE ATLAS d'octobre 2025 dessinent des schémas récurrents. Les noms changent, mais la forme reste stable.

• Mauvais outil : l'agent choisit une action destructive alors que l'utilisateur en demandait une sûre, comme dans les cas Replit et PocketOS.
• Mauvaise entrée : l'agent utilise le bon outil, mais avec le mauvais montant, le mauvais destinataire, la mauvaise date ou la mauvaise valeur de champ.
• Mauvais ordre : l'agent enchaîne les étapes dans une séquence dangereuse, par exemple supprimer avant d'avoir sauvegardé.
• Mauvaise permission : l'agent utilise un jeton privilégié ou un secret qu'il n'aurait jamais dû pouvoir atteindre.
• Boucle incontrôlée : l'agent répète une action pourtant approuvée jusqu'à générer des coûts, du spam ou des dégâts opérationnels.
• Détournement par prompt : un contenu malveillant détourne l'objectif de l'agent et le pousse à divulguer des données, exécuter un logiciel malveillant ou appeler le mauvais outil.
• Tâche faussement terminée : l'agent annonce qu'une tâche est finie alors qu'elle a échoué, qu'elle n'est que partielle ou qu'elle a produit un effet de bord.

Cette liste est plus actionnable qu'un long catalogue d'incidents. Une équipe red team peut tester si l'agent choisit le mauvais outil. Une équipe sécurité peut vérifier qu'il n'a pas accès à des secrets. Un responsable produit peut trancher : quelles actions exigent une approbation humaine ?

La principale attaque est indirecte

La lethal trifecta de Simon Willison, le trio de capacités qui rend un agent dangereux, reste la grille de lecture la plus claire pour la sécurité des agents. Un agent devient dangereux dès qu'une même session combine trois ingrédients : un accès à des données privées, une exposition à du contenu non fiable et la capacité à communiquer vers l'extérieur. Si les trois sont réunis, un document, un e-mail ou une page web malveillants peuvent lui demander de divulguer ce à quoi il a accès.

EchoLeak en est la version la plus simple. L'utilisateur n'a même pas eu besoin d'ouvrir un e-mail malveillant. L'agent a lu un contenu qui a changé son comportement. L'Agents Rule of Two publiée par Meta en novembre 2025 traduit l'idée en règle d'ingénierie : limiter l'agent à deux de ces trois propriétés au maximum dans une même session, ou imposer un contrôle humain avant la troisième.

Les MCP (Model Context Protocol) rendent le même problème encore plus visible. Les descriptions et les réponses d'outils peuvent provenir de serveurs tiers, et s'invitent alors dans le contexte du modèle. Le benchmark MCPTox a mesuré jusqu'à 72,8 % de succès d'attaque sur certains agents en production. Plus un modèle est performant, plus il peut être exposé, parce qu'il suit mieux les instructions, y compris les mauvaises.

Les contrôles de sécurité classiques passent à côté de la couche agent

D'abord, les tests ponctuels de modèles ne saisissent pas le risque agent. Un agent, c'est le modèle, plus des outils, une mémoire, un état et des permissions actives. Changez la boîte à outils, et vous changez la surface de risque. Les travaux METR de mars 2025 sur les tâches longues confirment d'ailleurs que la capacité agentique progresse sur des parcours complets, pas seulement sur des réponses isolées.

Ensuite, les outils de sécurité applicative cherchent surtout des signatures de requêtes déjà connues. Les agents, eux, ouvrent de nouveaux chemins à travers les systèmes. Dans l'incident McKinsey Lilli de 2025, un agent offensif autonome a accédé à 46,5 millions de messages de chat et 728 000 fichiers en moins de deux heures, en exploitant un schéma que les outils à base de signatures n'ont pas reconnu.

Enfin, la gestion des identités et des accès a surtout été pensée pour des humains et des comptes de service stables. Les agents, c'est autre chose. Ils peuvent être éphémères, déclenchés par du contenu non fiable et dotés de droits trop étendus. L'incident PocketOS illustre bien le problème : l'agent a trouvé un jeton API à longue durée de vie dans son propre espace de travail, et il s'en est servi.

Classez les actions selon les dégâts qu'elles peuvent causer

L'erreur, c'est de traiter toutes les actions d'un agent de la même façon. Un programme utile commence par classer ces actions selon leur impact. Un modèle peut rédiger, lire, chercher, envoyer, déployer ou supprimer. Tous ces verbes ne portent pas le même niveau de risque.

• L0 lecture seule : chercher dans des données publiques. Par défaut : automatique.
• L1 lecture privée : lire des documents internes ou interroger un CRM. Par défaut : automatique avec journalisation.
• L2 écriture réversible : rédiger un e-mail, créer un ticket ou ouvrir une pull request. Par défaut : automatique avec revue.
• L3 écriture irréversible ou communication externe : envoyer un e-mail, passer une commande ou déployer du code. Par défaut : approbation humaine par action.
• L4 changement de production ou de sécurité : supprimer des données, modifier des droits, déplacer de l'argent ou contacter des clients en masse. Par défaut : double validation, limitation de fréquence et audit rejouable.

Cette classification doit être associée à chaque outil, validée par le responsable métier et inscrite dans l'inventaire de l'agent. Une fois cela posé, la surveillance devient bien plus lisible. Surveillez les bascules d'une simple lecture vers une action destructive. Surveillez les boucles de retry sur les actions L3 et L4. Journalisez chaque appel d'outil avec ses arguments et ses effets en aval.

L'AI Act oriente vers un contrôle au niveau de l'action

L'AI Act ne prononce jamais le mot agent, mais plusieurs de ses obligations les concernent. L'article 14 impose une supervision humaine pour les systèmes à haut risque. Pour un agent, cela devrait se traduire par une approbation au niveau de l'action dès lors qu'elle est irréversible, externe ou sensible pour la sécurité. Un feu vert unique avant déploiement ne suffit pas.

L'article 12 impose des journaux automatisés pour les systèmes à haut risque. Pour un agent, le journal utile, c'est la séquence complète : prompt, contenu récupéré, appel d'outil, réponse d'outil, appel suivant et changement d'état final. L'article 50 s'applique également dès que l'agent interagit avec des personnes. L'accord politique Digital Omnibus du 7 mai 2026 a repoussé certaines échéances haut risque, sans pour autant ralentir les déploiements d'agents.

Par où commencer

• Listez tous les outils que l'agent peut appeler, y compris les API internes, les accès fichiers, les outils de messagerie et les outils de déploiement.
• Classez chaque outil de L0 à L4 et définissez la règle d'approbation par défaut.
• Retirez les secrets à longue durée de vie des espaces de travail des agents et remplacez-les par des identifiants courts et à droits restreints.
• Testez l'injection indirecte de prompt via e-mails, documents, pages web et réponses d'outils.
• Journalisez chaque appel d'outil avec ses entrées, ses sorties, l'utilisateur, la session et les effets en aval.
• Rejouez des incidents avant la production, à partir de traces réelles ou plausibles.

Si le cas Replit reste marquant, c'est parce que la trace existait. L'utilisateur pouvait rejouer ce qui s'était passé. Beaucoup d'agents d'entreprise en production aujourd'hui ne le permettent pas. Un bon programme de gouvernance des agents commence là : savoir ce que l'agent peut faire, limiter ce qu'il peut endommager et rendre chaque action importante rejouable.

Références

• Fast Company et The Register, l'agent IA Replit qui a effacé une base de production, juillet 2025.
• Aim Security et SecurityWeek, EchoLeak (CVE-2025-32711), juin 2025.
• Simon Willison, The lethal trifecta for AI agents, juin 2025.
• Meta, Agents Rule of Two, novembre 2025.
• OWASP, Top 10 pour applications agentiques, GenAI Security Project, 9 décembre 2025.
• MITRE ATLAS, mise à jour des techniques orientées agents, octobre 2025.
• Benchmark MCPTox (arXiv 2508.14925), août 2025.
• METR, Measuring AI Ability to Complete Long Tasks, mars 2025.
• Règlement (UE) 2024/1689 (AI Act), articles 12, 14, 50 ; accord politique Digital Omnibus, 7 mai 2026.