Cybersécurité : comment vos propres outils peuvent exécuter les ordres de pirates invisibles
L’OWASP classe le détournement d’objectifs (ASI01) en première position des risques propres aux agents IA. Des instructions malveillantes suffisent à détourner un agent et à exploiter les droits qui lui ont été confiés. Le Top 10 for Agentic Applications 2026, publié le 9 décembre 2025 par son GenAI Security Project, reprend ce constat.
- Les agents IA peuvent être détournés via des instructions malveillantes dans leurs contenus.
- Les attaques exploitent le flux d'entrée secondaire, souvent non contrôlé par la sécurité classique.
- Des incidents réels montrent que des agents font confiance à des commandes codées dans des messages.
- La sécurité doit limiter les droits, surveiller en production et tester régulièrement les agents.

Un risque qui change de nature
Des chercheurs d’Aim Security ont montré qu’un simple e-mail pouvait faire sortir des données internes par Microsoft 365 Copilot dès juin 2025. Le destinataire n’avait même pas besoin d’ouvrir le message : l’assistant le lisait en arrière-plan, comme les autres messages, et exécutait les commandes invisibles mais encodées dans le texte. Microsoft a corrigé la faille, appelée EchoLeak (CVE-2025-32711).
Les agents disposent désormais d’un pouvoir d’action réel. Ils lisent des boîtes de réception, consultent des bases de données, exécutent du code, appellent des API et, de plus en plus, déclenchent des paiements. Un agent établit un plan et le suit étape par étape, souvent sans demander d’approbation au préalable.
Le détournement d’objectifs ne se confond pas avec l’injection de prompt classique, qui fausse une réponse à un moment donné. Il modifie toute la mission de l’agent, son plan, l’ordre de ses étapes et les outils qu’il utilise. L’image retenue est celle d’un GPS reprogrammé en cours de trajet, et non d’un panneau mal lu.
Pourquoi les défenses actuelles ne voient rien
Un modèle de langage ne distingue pas une instruction d’une donnée. La consigne d’un collègue, le corps d’un e-mail et une page web consultée arrivent dans la même fenêtre de contexte, sous forme de texte. N’importe quel passage peut donc être pris pour un ordre.
L’OWASP décrit un mécanisme précis : l’attaquant modifie les objectifs de l’agent à travers les contenus qu’il traite, sans toucher à son code. L’agent continue de croire qu’il sert son utilisateur, ce qui rend l’attaque plus difficile à détecter. Les flux d’entrée se répartissent en deux canaux. Le flux reçu, qui correspond à la demande de l’utilisateur, passe par l’authentification, les contrôles d’accès et le pare-feu. Le flux récupéré, qui regroupe pages web, e-mails, tickets, documents indexés par le RAG et réponses d’autres agents, échappe en grande partie à ces contrôles. C’est par ce second canal que passe l’attaque.
Des attaques déjà observées en conditions réelles
En mai 2026, Bankrbot a pris un message codé envoyé à Grok pour un ordre de transfert. Résultat : 3 milliards de jetons DRB détournés, soit 150 000 à 200 000 dollars, et une chute du cours de 40 %. Aucun système n’a été piraté : deux agents se sont simplement fait confiance.
Selon Unit 42, en mars 2026, certains sites web cachent des instructions destinées à tromper les IA de modération, à déclencher des paiements ou à supprimer des données. Les chercheurs ont identifié 22 techniques de dissimulation. En août 2025, des paquets npm malveillants utilisant Claude Code, Gemini CLI et Amazon Q ont servi à voler des secrets. Selon Wiz, plus de 2 300 secrets ont été exposés et 1 700 utilisateurs touchés, tandis qu’une seconde vague a divulgué 6 700 dépôts privés.
Aucun correctif ne règle durablement le problème, qui tient au fonctionnement même des modèles. Le cadre OWASP organise la réponse autour de la limitation des droits, de la méfiance envers les contenus lus et de la surveillance en production. Chaque agent ne doit disposer que des droits nécessaires à sa mission, et toute action irréversible ou coûteuse, comme un virement ou une suppression, doit recevoir une validation humaine. Chaque contenu lu doit être traité comme potentiellement piégé. Enfin, un comportement habituel doit être défini pour repérer les écarts : un agent comptable qui appelle l’API de paiement à 3 heures du matin doit déclencher une alerte.
Avant toute mise en production, les agents doivent être testés en préproduction, avec les mêmes connecteurs et habilitations, mais avec des données de test. Le red-teaming place des instructions malveillantes dans les contenus lus par l’agent, tandis que le test d’intrusion vise ses API, ses connecteurs et la gestion de ses secrets. Ces tests doivent être refaits à chaque changement de modèle, de consignes, d’outil ou de source de données.
Avant de déployer un agent, chaque comité exécutif devrait se poser deux questions : quelles sources cet agent consulte, et qui peut écrire dans ces sources ? Où se trouve le rapport de red-teaming qui montre qu’il résiste aux tentatives de détournement ?





