Attaques contre les agents IA : 5 techniques réelles en 2026

Les attaques contre les agents IA ne relèvent plus de la démonstration de laboratoire : entre 2025 et 2026, des agents en production chez OpenAI, Microsoft, Google ou GitHub ont été détournés par des contenus piégés, des descriptions d'outils falsifiées ou des mémoires empoisonnées. OpenAI a lui-même reconnu que l'injection de prompt dans les navigateurs agentiques ne serait probablement jamais totalement résolue. Cet article passe en revue les cinq familles de techniques documentées publiquement en 2026 : l'injection dans les navigateurs agentiques, l'empoisonnement des outils MCP, le détournement des agents de développement, l'empoisonnement de la mémoire et des hooks, et l'exfiltration zero-click via les connecteurs. Pour chacune, il explique le mécanisme sans détail d'exploitation, cite les cas réels et détaille les contre-mesures concrètes à déployer. Il s'adresse aux RSSI, architectes et équipes SOC qui intègrent des agents dans leur système d'information et complète notre analyse de la surface d'attaque de l'IA agentique.

Pourquoi les attaques contre les agents IA explosent en 2026

Un agent IA ne se contente pas de répondre : il lit des pages web, des courriels et des documents, appelle des outils et agit dans des systèmes métier. Chaque nouvelle source de données et chaque nouvel outil élargit ce que l'attaquant peut influencer et ce que l'agent peut faire en son nom. La généralisation des connecteurs, des serveurs Model Context Protocol et des navigateurs agentiques a multiplié ces surfaces en moins de deux ans.

Selon l'analyse de Simon Willison sur la trifecta létale, dès que ces trois éléments sont réunis dans un même agent, un attaquant peut en pratique lui faire divulguer des données, car le modèle ne distingue pas de façon fiable les instructions légitimes des instructions cachées dans les données qu'il traite.

Les cinq familles d'attaques présentées ci-dessous sont autant de manières de réunir ces trois conditions. Les reconnaître permet de comprendre pourquoi les contre-mesures efficaces sont architecturales plutôt que fondées sur la seule détection.

Technique 1 : l'injection de prompt dans les navigateurs agentiques

Les navigateurs agentiques, comme ChatGPT Atlas, naviguent sur le web pour l'utilisateur : ils lisent des pages, remplissent des formulaires et cliquent sur des liens. Chaque page consultée devient une entrée pour le modèle. Un site malveillant ou compromis peut contenir des instructions, visibles ou dissimulées dans le texte, que l'agent risque d'interpréter comme une demande de l'utilisateur.

Le mécanisme ne nécessite aucune vulnérabilité logicielle au sens classique. L'attaquant exploite le fait que le modèle traite le contenu de la page et la consigne de l'utilisateur dans le même flux de texte. Une fois détourné, l'agent peut naviguer vers d'autres sites, divulguer des informations de la session ou effectuer des actions dans des comptes où l'utilisateur est connecté.

OpenAI a publiquement reconnu la difficulté. Comme le rapporte CyberScoop, l'éditeur a indiqué que l'injection de prompt, à l'image des arnaques et de l'ingénierie sociale sur le web, ne serait probablement jamais totalement « résolue ». Il a publié un correctif pour Atlas après qu'un attaquant automatisé fondé sur un modèle, entraîné par apprentissage par renforcement, a découvert une nouvelle classe d'injections que les campagnes de red teaming humaines n'avaient pas identifiée.

Contre-mesures pour les navigateurs agentiques

• Réserver les navigateurs agentiques à des tâches de lecture, sans connexion aux comptes sensibles (messagerie, banque, administration).
• Utiliser un profil de navigation dédié, sans sessions ouvertes ni mots de passe enregistrés.
• Exiger une confirmation explicite avant toute action d'écriture, d'achat ou d'envoi.
• Activer les modes de sécurité renforcée proposés par l'éditeur pour les usages sensibles.
• Restreindre par politique d'entreprise les domaines accessibles à l'agent.

Ce qu'OpenAI a changé : red teaming automatisé et mode verrouillé

La réponse d'OpenAI illustre l'évolution des stratégies de défense chez les éditeurs. Plutôt que de promettre un filtre parfait, l'éditeur combine la recherche automatisée de failles, la réduction des capacités dans les contextes à risque et l'information de l'utilisateur.

Le principe du mode verrouillé consiste à désactiver ou restreindre les fonctionnalités qui permettent l'exfiltration, comme certains outils ou la consultation de contenus externes, lorsque l'utilisateur traite des informations sensibles. Le red teaming automatisé, lui, permet de rechercher en continu de nouvelles variantes d'attaque à une échelle impossible pour des équipes humaines.

Pour une entreprise, la leçon est double. D'une part, la sécurité d'un agent ne peut pas reposer uniquement sur les protections de l'éditeur du modèle. D'autre part, la réduction des capacités selon le contexte est une mesure efficace que chaque organisation peut appliquer à ses propres agents, comme le détaille notre guide de modélisation des menaces d'un agent IA.

Le cadre de référence s'est également structuré : l'OWASP a publié en décembre 2025 son Top 10 for Agentic Applications 2026, qui place l'injection et le détournement d'objectif au cœur des risques propres aux applications agentiques, dans la continuité des travaux du projet OWASP GenAI Security.

Technique 2 : l'empoisonnement des outils MCP

Le Model Context Protocol permet à un agent de découvrir et d'appeler des outils exposés par des serveurs. Chaque outil est accompagné d'une description en langage naturel que le modèle lit pour savoir quand et comment l'utiliser. Cette description n'est généralement pas affichée à l'utilisateur, ce qui en fait un emplacement idéal pour dissimuler des instructions.

L'attaque, baptisée Tool Poisoning Attack, a été formalisée par Invariant Labs en avril 2025. Un serveur MCP malveillant, ou un serveur légitime compromis, publie des outils dont la description contient, à côté d'une fonction anodine, des consignes invitant le modèle à lire des fichiers sensibles ou à transmettre des données à un autre outil. L'utilisateur voit un outil inoffensif ; le modèle, lui, lit et suit les consignes cachées.

Selon le Cloud Security Alliance, l'équipe de recherche en sécurité de Microsoft a montré le 30 juin 2026 que la modification des descriptions d'outils MCP pouvait conduire un agent à collecter et exfiltrer des données sensibles alors que chaque action individuelle semblait autorisée. Le benchmark académique MCPTox mesure désormais la robustesse des agents face à ces attaques sur des serveurs MCP réels.

Variantes : rug pull et contamination entre serveurs

Deux variantes aggravent le risque. Le rug pull consiste à publier un outil sain, à attendre qu'il soit approuvé, puis à modifier sa description ou son comportement lors d'une mise à jour. La contamination entre serveurs exploite le fait que toutes les descriptions d'outils chargées partagent le même contexte : un serveur malveillant peut influencer la manière dont l'agent utilise les outils d'un autre serveur, pourtant légitime.

Contre-mesures pour les outils MCP

1. Tenir un inventaire des serveurs MCP autorisés et interdire l'ajout libre de serveurs par les utilisateurs.
2. Épingler les versions des serveurs et relire les descriptions d'outils à chaque mise à jour, avec détection automatique des changements.
3. Isoler les agents par périmètre : un agent qui accède à des données sensibles ne doit pas charger de serveurs MCP tiers non audités.
4. Exécuter les serveurs locaux dans un environnement isolé, sans accès au système de fichiers ni au réseau au-delà du nécessaire.
5. Imposer une authentification forte aux serveurs distants et journaliser chaque appel d'outil avec ses paramètres.

Les risques propres au protocole sont détaillés dans notre guide sur la sécurité du Model Context Protocol et dans notre analyse des injections via les outils MCP.

Technique 3 : le détournement des agents de développement

Les assistants de code agentiques, capables de lire un dépôt, d'exécuter des commandes et de proposer des modifications, sont devenus une cible de choix. Ils traitent en permanence des contenus rédigés par des tiers : issues, pull requests, commentaires, fichiers de documentation, dépendances. Tout ce texte peut porter des instructions.

D'après les recherches compilées par la Cloud Security Alliance, une équipe de l'université Johns Hopkins a montré en avril 2026 qu'il était possible de détourner Claude Code, Gemini CLI et GitHub Copilot en plaçant des instructions malveillantes dans des titres de pull requests GitHub, et que l'attaque était restée indétectée pendant plusieurs semaines dans les environnements concernés. Les mêmes sources signalent que des scanners d'infrastructure publics indexaient début 2026 des serveurs MCP exposés donnant accès à des identifiants et à des historiques de conversation.

L'impact potentiel est élevé, car ces agents s'exécutent souvent avec les droits du développeur : accès au code source, aux secrets de développement, aux jetons de déploiement et parfois aux pipelines d'intégration continue. Un agent détourné peut modifier du code, divulguer des secrets ou introduire une porte dérobée dans une contribution apparemment légitime.

Contre-mesures pour les agents de développement

• Exécuter les agents de code dans un conteneur ou une machine virtuelle dédiée, sans accès aux secrets de production.
• Désactiver l'exécution automatique de commandes et exiger une validation pour toute commande réseau ou d'installation.
• Traiter les issues, pull requests et commentaires externes comme des entrées non fiables, en particulier dans les workflows automatisés.
• Ne jamais donner à un agent déclenché par un événement public des jetons d'écriture sur le dépôt ou des secrets de pipeline.
• Faire relire par un humain toute modification proposée par un agent, comme pour un contributeur externe.

Technique 4 : l'empoisonnement de la mémoire et des hooks

La mémoire persistante permet à un agent de retenir des préférences et des informations d'une session à l'autre. Elle offre aussi à l'attaquant un moyen de persistance : une instruction injectée une seule fois, par un document ou une page web, peut être enregistrée en mémoire puis influencer toutes les conversations futures, longtemps après la disparition du contenu initial.

Le phénomène a été démontré dès 2024 sur la mémoire de ChatGPT par le chercheur Johann Rehberger, et il fait désormais l'objet de travaux académiques systématiques, comme l'étude Bad Memory publiée en 2026, qui évalue les risques d'injection provenant de la mémoire dans les systèmes agentiques. Une information falsifiée mémorisée peut orienter les décisions de l'agent ou provoquer des fuites répétées.

Les hooks et fichiers de configuration des environnements d'agents constituent une seconde voie de persistance. Ces mécanismes exécutent des actions ou injectent du contexte à des moments précis du fonctionnement de l'agent. Des travaux publiés en 2026 montrent qu'un attaquant capable de contrôler les mises à jour de ces hooks peut orienter durablement un agent vers des comportements malveillants, comme le décrit l'étude sur les mises à jour de hooks contrôlées par un attaquant.

Contre-mesures pour la mémoire et les hooks

• Enregistrer la provenance de chaque élément mémorisé et interdire la mémorisation automatique d'informations issues de contenus externes.
• Permettre à l'utilisateur et aux administrateurs de consulter, auditer et supprimer la mémoire de l'agent.
• Fixer une durée d'expiration aux souvenirs non validés et cloisonner la mémoire par utilisateur et par client.
• Versionner et signer les fichiers de hooks et de configuration, et alerter sur toute modification.
• Désactiver la mémoire persistante pour les agents qui traitent des données sensibles lorsqu'elle n'est pas indispensable.

Les attaques ciblant les sources documentaires des agents sont approfondies dans notre article sur l'injection indirecte et l'empoisonnement RAG.

Technique 5 : l'exfiltration zero-click via les connecteurs

Les attaques les plus redoutées sont celles qui ne demandent aucune action de la victime. Un agent connecté à la messagerie, au stockage de documents ou à l'agenda lit ces contenus dans le cadre de sa tâche normale. Il suffit alors à l'attaquant d'envoyer un courriel ou de partager un document piégé : lorsque l'agent le traite, il exécute les instructions cachées et transmet des données vers l'extérieur.

Plusieurs cas publics de 2025 ont illustré ce scénario. EchoLeak a visé Microsoft 365 Copilot et a fait l'objet de la vulnérabilité CVE-2025-32711, corrigée par Microsoft. AgentFlayer, présenté par Zenity Labs, ciblait les connecteurs de ChatGPT au moyen d'un document partagé piégé. ShadowLeak, décrit par Radware, concernait l'agent de recherche approfondie de ChatGPT connecté à une messagerie, avec une exfiltration réalisée côté serveur, donc invisible pour les outils de sécurité de l'entreprise.

Le canal de sortie est souvent discret : une requête vers une URL contrôlée par l'attaquant, une image distante dont l'adresse contient les données, ou un appel d'outil légitime détourné. C'est pourquoi le contrôle des sorties est aussi important que le contrôle des entrées.

Contre-mesures contre l'exfiltration zero-click

1. Limiter les connecteurs actifs au strict nécessaire et appliquer les droits de l'utilisateur lors de chaque accès.
2. Bloquer le rendu d'images et de liens vers des domaines externes non approuvés dans les réponses de l'agent.
3. Restreindre les requêtes réseau sortantes de l'agent à une liste blanche de destinations.
4. Appliquer les étiquettes de confidentialité et les politiques de prévention des fuites de données aux contenus accessibles par l'agent.
5. Séparer les agents qui lisent des contenus reçus de l'extérieur de ceux qui accèdent aux données sensibles.

Comparatif des cinq techniques d'attaque

Ce tableau met en évidence une tendance nette : plus l'agent est intégré au système d'information, moins l'attaque nécessite d'interaction de la victime. Les défenses doivent donc être placées dans l'architecture et non dans la vigilance de l'utilisateur.

Stratégie de défense globale : casser la trifecta létale

Les contre-mesures spécifiques à chaque technique reposent sur des principes communs. Le premier est de ne jamais réunir dans un même agent les trois éléments de la trifecta létale : si un agent doit lire des contenus non fiables, il ne doit ni accéder à des données sensibles ni disposer d'un canal de sortie libre. Cette séparation, décidée à la conception, est plus robuste que n'importe quel filtre.

La défense en profondeur d'un agent s'organise en cinq couches complémentaires :

1. Isolation des entrées : identifier toutes les sources non fiables et les traiter comme des données, jamais comme des instructions.
2. Moindre privilège : identité dédiée à l'agent, permissions minimales par outil, jetons de courte durée, aucun secret dans le contexte du modèle.
3. Contrôle des sorties : liste blanche de destinations réseau, blocage du rendu d'URL externes, filtrage des données sensibles.
4. Validation humaine : confirmation obligatoire pour les actions irréversibles ou sortantes, avec affichage des paramètres réels.
5. Supervision : journalisation de chaque décision et appel d'outil, détection des comportements anormaux et capacité de réponse rapide.

# Politique d'un agent de support (exemple de configuration défensive)
agent: support-client
identite: sa-agent-support          # compte dédié, pas de compte partagé
sources_non_fiables: [courriels_entrants, pieces_jointes]
outils_autorises:
  - crm.lecture
  - ticket.creation
outils_interdits: [messagerie.envoi_externe, fichiers.partage]
sorties_reseau: [api.crm.interne]   # aucune destination externe
validation_humaine: [ticket.cloture, remboursement]
memoire_persistante: false

L'isolation d'exécution complète ce dispositif en limitant ce qu'un agent compromis peut atteindre, comme le détaille notre guide sur le sandboxing des agents en production. La gestion des identités et des droits des agents est approfondie dans notre article sur les politiques d'identité des agents IA.

Détecter une attaque contre un agent IA dans le SOC

Même bien conçu, un agent peut être détourné. La capacité de détection repose sur la qualité des journaux : chaque requête utilisateur, chaque contenu externe traité, chaque appel d'outil et chaque réponse doivent être enregistrés avec un identifiant de corrélation commun, puis transmis au SIEM de l'organisation.

Les signaux d'alerte les plus pertinents sont les suivants :

• Appels d'outils sans rapport avec la tâche demandée ou en volume inhabituel.
• Requêtes sortantes vers des domaines jamais contactés, ou URL contenant des données encodées.
• Lecture de fichiers ou de messages sensibles juste après le traitement d'un contenu externe.
• Modification de la mémoire de l'agent, de ses hooks ou de sa configuration.
• Apparition ou mise à jour d'un serveur MCP, ou changement d'une description d'outil.

Le plan de réponse doit prévoir la suspension immédiate de l'agent, la révocation de ses jetons, l'analyse des journaux pour identifier le contenu déclencheur et la purge de la mémoire contaminée. Les exercices réguliers de red teaming des agents autonomes permettent de vérifier que ces mécanismes fonctionnent avant un incident réel.

Questions fréquentes

Conclusion

Les attaques contre les agents IA documentées en 2025 et 2026 suivent toutes le même schéma : un contenu non fiable influence un agent qui dispose d'accès sensibles et d'un canal de sortie. Navigateurs agentiques, serveurs MCP, agents de développement, mémoires et connecteurs ne sont que des variations de ce thème. Puisque l'injection de prompt ne peut pas être éliminée, la sécurité repose sur l'architecture : casser la trifecta létale, appliquer le moindre privilège, contrôler les sorties, valider les actions critiques et superviser chaque décision. Pour aller plus loin, consultez notre analyse des techniques avancées d'injection de prompt.