Les agents d’intelligence artificielle ne se contentent plus de répondre à une question : ils naviguent sur le web, lisent des e-mails, analysent des dépôts GitHub, cliquent sur des boutons et peuvent parfois lancer des commandes locales. Cette autonomie ouvre un nouveau front de sécurité. Une classe d’attaque décrite par des chercheurs de la Seoul National University, de l’University of Illinois Urbana-Champaign et de Largosoft montre qu’un agent peut être trompé sans recevoir d’ordre malveillant explicite.
Cette technique, appelée Agent Data Injection ou ADI, ne cherche pas à dire à l’IA « ignore tes instructions » comme dans une injection de prompt classique. Elle falsifie plutôt les petites données que l’agent utilise comme repères fiables : l’identifiant d’un bouton, le nom d’un expéditeur, l’auteur supposé d’un commentaire GitHub ou le résultat d’un contrôle technique. L’agent poursuit alors la tâche demandée par l’utilisateur, mais sur une base contaminée.
Le risque est concret : un agent chargé de résumer des avis produits pourrait être amené à cliquer sur « Acheter » au lieu de « Lire la suite ». Un assistant de développement pourrait exécuter une commande provenant d’un attaquant parce qu’un commentaire imite l’identité d’un mainteneur. Dans les deux cas, l’utilisateur a l’impression que l’agent agit normalement.
Pourquoi l’Agent Data Injection est différente d’une injection de prompt classique
Les attaques par prompt injection sont désormais bien connues : un attaquant cache une instruction dans un contenu consulté par l’IA, par exemple dans une page web ou un e-mail, afin de modifier son comportement. Les défenses modernes sont de plus en plus entraînées à détecter ces consignes dissimulées, surtout lorsqu’elles ressemblent à des ordres directs.
L’ADI fonctionne à un niveau plus discret. Elle n’insère pas nécessairement une nouvelle consigne. Elle modifie la manière dont l’agent interprète les données qu’il lit pendant son travail. Pour un agent, une page web, un fil GitHub ou un message e-mail ne sont pas de simples blocs de texte : ils sont souvent transformés en structures internes avec des champs, des identifiants, des délimiteurs et des métadonnées.
Le problème apparaît lorsque des données contrôlées par un tiers sont présentées à l’agent dans un format qui ressemble à des informations internes fiables. Un nom d’auteur falsifié peut paraître légitime. Un identifiant de bouton peut sembler correspondre à une action autorisée. Un faux résultat de test peut être lu comme une étape déjà validée.
La faille centrale : des délimiteurs que le modèle croit reconnaître
Les chercheurs décrivent une méthode appelée probabilistic delimiter injection. Les agents utilisent souvent des signes de ponctuation ou des marqueurs pour séparer les champs : guillemets, accolades, balises, crochets, retours à la ligne. Dans un logiciel classique, ces séparateurs sont interprétés par un parseur strict. Dans un modèle de langage, l’interprétation reste probabiliste : le modèle estime ce que la structure semble signifier.
Un attaquant peut donc glisser dans un champ contrôlé des caractères qui ressemblent à des séparateurs de structure. Même si ces caractères ne sont pas strictement valides, le modèle peut les traiter comme s’ils délimitaient un nouveau champ, un nouvel élément ou une nouvelle entrée fiable.
Selon les tests rapportés, des éléments comme un guillemet échappé, un guillemet typographique ou même un caractère inattendu peuvent suffire à faire croire au modèle qu’une nouvelle structure existe. Là où un programme traditionnel verrait du texte ordinaire, l’agent IA peut voir un faux bouton, un faux e-mail ou un faux résultat d’outil.
Trois scénarios d’attaque observés sur des outils réels
Les chercheurs ont construit plusieurs preuves de concept sur des outils déjà disponibles. L’intérêt de ces scénarios est qu’ils ne reposent pas sur une hypothèse abstraite : ils visent précisément les usages qui se généralisent dans les navigateurs IA et les assistants de codage.
Un agent web qui clique sur le mauvais bouton
Dans le premier scénario, un avis produit piégé réutilise l’identifiant d’un bouton réel sur une page. L’agent pense cliquer sur un élément inoffensif, par exemple « Lire la suite », mais déclenche en réalité une action plus sensible comme « Acheter maintenant ».
Des outils comme Claude dans Chrome, Google Antigravity ou Nanobrowser ont été cités dans les tests. Le point faible vient notamment du fait que certains agents numérotent les éléments de page de manière prévisible. Si l’attaquant peut deviner ou reconstituer l’identifiant d’un bouton, il peut tenter de le faire apparaître dans un contenu qu’il contrôle.
Un assistant de code qui exécute une commande étrangère
Le deuxième scénario concerne les assistants de développement comme Claude Code, OpenAI Codex ou Gemini CLI. Un commentaire GitHub malveillant peut falsifier une ligne d’auteur pour donner l’impression qu’un mainteneur du projet recommande une correction. Si l’utilisateur demande à l’agent d’appliquer le correctif proposé par le mainteneur, l’agent peut intégrer l’instruction de l’attaquant dans son raisonnement et proposer d’exécuter une commande dangereuse.
Le danger est accentué par le contexte de travail des développeurs : les agents de code manipulent des fichiers locaux, des dépendances, des scripts et parfois des secrets d’environnement. Une validation trop rapide peut donc avoir des conséquences importantes.
Une pull request qui simule un contrôle réussi
Le troisième scénario falsifie l’historique d’un contrôle que l’agent croit avoir déjà exécuté. Une pull request malveillante peut ainsi faire apparaître un résultat propre dans la mémoire ou le contexte de l’agent. Celui-ci analyse ensuite ce faux résultat, juge le code acceptable et peut recommander la fusion de la modification.
Dans ce type d’attaque, l’agent ne devient pas « rebelle ». Il suit au contraire son objectif apparent : examiner le changement, vérifier les résultats et aider à fusionner. Le problème est que les preuves qu’il consulte ont été fabriquées.
Pourquoi les demandes de confirmation ne suffisent pas toujours
Beaucoup d’agents demandent déjà une confirmation avant une action risquée : cliquer, acheter, exécuter une commande, modifier un dépôt. C’est indispensable, mais les chercheurs montrent que cela ne règle pas entièrement le problème.
Si la demande de confirmation se contente d’indiquer que l’agent veut cliquer sur un élément, sans expliquer clairement lequel, pourquoi et depuis quelle donnée il a été sélectionné, l’utilisateur reste aveugle. De même, un assistant de code peut afficher un raisonnement cohérent, mais ce raisonnement peut être construit sur des faits falsifiés.
En pratique, l’utilisateur voit une action qui paraît routinière. Il peut approuver parce que l’agent semble avoir suivi la bonne procédure. L’ADI rend donc les validations humaines moins efficaces lorsqu’elles ne montrent pas la provenance exacte des informations utilisées.
Des modèles majeurs vulnérables dans les tests
D’après les résultats rapportés dans l’étude, plusieurs modèles de premier plan se sont révélés vulnérables à différents degrés, notamment des modèles d’OpenAI, Anthropic et Google cités dans la source. Les chercheurs mentionnent GPT-5.2, GPT-5-mini, Claude Opus 4.5, Claude Sonnet 4.5, Gemini 3 Pro et Gemini Flash.
Les taux de réussite observés varient selon les formats et les environnements. Sur des données structurées, l’attaque aurait fonctionné dans une fourchette d’environ 31 % à 43 % des cas. Sur des données de pages web, les résultats vont d’environ un tiers des tentatives à la totalité dans certains scénarios. Face à des défenses conçues contre les injections de prompt classiques, l’écart est notable : ces défenses bloquent très bien les ordres cachés traditionnels, mais l’ADI peut encore réussir jusqu’à 50 % du temps dans les tests rapportés.
Ce point est essentiel : les protections existantes ne sont pas inutiles, mais elles ne visent pas le même mécanisme. Elles cherchent surtout les instructions malveillantes. L’ADI, elle, manipule les faits supposés fiables sur lesquels l’agent fonde sa décision.
Ce qui semble mieux résister à l’attaque
Les chercheurs ont aussi identifié des approches plus robustes. L’une des plus efficaces consiste à rendre les identifiants internes imprévisibles. Par exemple, ChatGPT Atlas aurait résisté au scénario de clic parce qu’il attribue aux éléments de page des identifiants aléatoires difficiles à deviner, plutôt qu’une simple numérotation séquentielle.
Une défense plus légère, consistant à ajouter de courts marqueurs aléatoires aux noms de champs, aurait réduit le taux de réussite d’environ 49 % à 29 % dans certains tests, tout en conservant une bonne utilisabilité. L’idée est simple : si l’attaquant ne peut pas deviner la forme exacte des champs internes, il devient plus difficile de fabriquer une donnée qui se fait passer pour un élément fiable.
Une protection plus lourde consiste à suivre précisément l’origine de chaque donnée manipulée par l’agent. Cette approche de traçabilité aurait bloqué les attaques dans les tests, mais avec un coût important : les agents ne parvenaient plus à terminer qu’environ un tiers de leurs tâches ordinaires. Autrement dit, la sécurité progresse, mais l’utilisabilité chute.
Les contre-mesures à privilégier
- Utiliser des identifiants aléatoires et non prédictibles pour les éléments d’interface et les champs internes.
- Séparer strictement les données fiables et non fiables dans le contexte transmis au modèle.
- Afficher la provenance des informations dans les demandes de confirmation utilisateur.
- Éviter les confirmations vagues du type « l’agent veut cliquer » ou « l’agent veut exécuter une commande ».
- Mettre en place des politiques d’exécution qui empêchent un agent de lancer certaines commandes sans contrôle renforcé.
- Tester les agents avec des benchmarks dédiés aux attaques sur les données, et pas seulement aux injections d’instructions.
Une attaque encore expérimentale, mais à prendre au sérieux
À ce stade, les chercheurs parlent de preuves de concept. Aucune exploitation publique d’Agent Data Injection dans des attaques réelles n’est signalée dans les informations disponibles. L’équipe indique avoir prévenu les fournisseurs concernés avant publication. OpenAI, Google et Anthropic auraient accusé réception des signalements, tandis que Nanobrowser n’avait pas répondu au moment mentionné par la source.
Le chercheur Woohyuk Choi, cité par The Hacker News, indique que les fournisseurs ont confirmé la validité de l’attaque. Selon ses déclarations, l’équipe n’aurait toutefois pas été informée de correctifs déjà déployés ou planifiés au moment de l’échange.
L’étude souligne aussi une difficulté pratique pour l’attaquant : il doit connaître le format dans lequel l’agent emballe ses données. Pour un outil open source ou local, ce format peut être déduit du code ou par rétro-ingénierie. Pour un service cloud, c’est plus difficile. Les chercheurs affirment néanmoins avoir pu récupérer certains formats côté serveur via des techniques de jailbreak multi-tours, avec des résultats variables selon les modèles.
Pourquoi les agents IA amplifient ce type de risque
Un chatbot classique peut se tromper dans une réponse. Un agent, lui, peut agir : cliquer, envoyer, modifier, exécuter, fusionner. Cette capacité transforme une erreur d’interprétation en action concrète. Plus les agents sont connectés à des outils sensibles, plus la frontière entre « mauvaise réponse » et « incident de sécurité » devient fine.
L’ADI révèle une faiblesse de conception plus générale : les agents mélangent souvent, dans un même contexte, des données de confiance très différente. Le nom d’un expéditeur, le corps d’un e-mail, un commentaire public, le résultat d’un outil local et une instruction système peuvent se retrouver représentés sous une forme textuelle proche. Pour un modèle de langage, cette proximité est dangereuse.
Le principe de sécurité à appliquer n’est pas nouveau : séparer le code des données, puis séparer les données fiables des données non fiables. Les logiciels traditionnels ont appris cette leçon à travers les injections SQL, XSS et autres classes d’attaques. Les agents IA doivent maintenant l’intégrer dans leur architecture.
Un contexte déjà marqué par EchoLeak et les attaques GitHub contre les assistants IA
L’Agent Data Injection s’inscrit dans une série de recherches récentes sur la sécurité des assistants IA. En juin 2025, Aim Security a révélé EchoLeak, identifié comme CVE-2025-32711, une faille affectant Microsoft 365 Copilot. Elle montrait qu’un e-mail spécialement conçu pouvait pousser l’assistant à divulguer des fichiers internes sans interaction de l’utilisateur. Microsoft a corrigé le problème, et aucune exploitation active n’a été signalée publiquement.
En mai 2025, Invariant Labs a également montré qu’une issue GitHub publique pouvait orienter un agent vers la lecture d’un dépôt privé et provoquer une fuite. D’autres tests inter-éditeurs ont visé Claude Code, Gemini CLI ou Copilot via des issues et pull requests, parfois en contournant les garde-fous ajoutés pour limiter ces abus.
La différence importante est que beaucoup de ces attaques reposaient sur des instructions cachées. L’ADI franchit une étape supplémentaire : elle ne se contente pas de dire à l’agent quoi faire, elle falsifie ce que l’agent croit savoir.
Ce que les équipes produit et sécurité doivent faire maintenant
Pour les éditeurs d’agents IA, la priorité est de revoir la représentation interne des données. Les champs issus d’un utilisateur externe, d’une page web, d’un e-mail ou d’un commentaire public ne doivent jamais pouvoir imiter une métadonnée vérifiée. Les interfaces de confirmation doivent aussi devenir plus explicites : l’utilisateur doit comprendre l’action, la cible, la source de l’information et le niveau de confiance associé.
Pour les entreprises qui déploient déjà des agents, il est prudent de limiter les permissions par défaut. Un agent qui lit le web ne devrait pas pouvoir acheter, valider une pull request ou exécuter une commande locale sans garde-fou adapté. Les actions sensibles doivent être soumises à des règles indépendantes du raisonnement du modèle.
- Cartographier les agents qui accèdent à des contenus modifiables par des tiers : web, e-mail, tickets, issues, pull requests, chats externes.
- Limiter les actions irréversibles ou coûteuses : achats, suppressions, fusions de code, exécution de scripts, envoi de données.
- Exiger des confirmations détaillées, avec affichage de la cible réelle et de la source de chaque donnée clé.
- Mettre en quarantaine les contenus non fiables avant qu’ils n’entrent dans le contexte de décision de l’agent.
- Surveiller les journaux d’actions des agents pour repérer des clics, commandes ou validations incohérents.
Le vrai enjeu : construire des agents qui savent d’où viennent leurs informations
L’Agent Data Injection rappelle une évidence souvent sous-estimée : un agent IA n’est fiable que si les données qu’il utilise le sont aussi. Tant qu’un commentaire public peut ressembler à une métadonnée interne, ou qu’un faux résultat peut se glisser dans l’historique de travail, les agents resteront exposés à des manipulations subtiles.
La solution ne viendra pas d’un simple filtre de prompt. Elle nécessitera une combinaison d’architecture sécurisée, de traçabilité des données, d’identifiants non devinables, de permissions minimales et d’interfaces de validation plus transparentes. À mesure que les agents IA deviennent capables d’agir dans des environnements réels, cette séparation entre le fiable et le non fiable devient une condition de sécurité fondamentale.
Pour les utilisateurs, le conseil immédiat est simple : ne pas approuver aveuglément une action proposée par un agent, surtout lorsqu’elle touche au code, aux achats, aux fichiers locaux ou aux données internes. Pour les éditeurs, le message est plus structurel : les agents doivent apprendre à ne pas croire une donnée simplement parce qu’elle ressemble au bon format.