Agents IA et injection de prompt : un simple courriel peut-il voler vos données? La réponse est oui.

Je vais vous donner la réponse tout de suite : oui.

En juin 2025, des chercheurs en sécurité ont démontré que l’envoi d’un seul courriel piégé à un utilisateur de Microsoft 365 Copilot suffisait à exfiltrer des données sensibles de son environnement. Sans clic. Sans téléchargement. Sans aucune action de la part de la victime.

Cette vulnérabilité a reçu l’identifiant CVE-2025-32711, baptisée EchoLeak. Microsoft a publié un correctif d’urgence côté serveur. Le concept derrière l’attaque, lui, reste valide pour tout système agentique mal cloisonné.

EchoLeak est la première démonstration documentée d’une injection de prompt « zero-click » dans un système d’IA en production.

Ce qu’est un agent dans le contexte qui nous concerne

Un agent d’IA, ce n’est pas seulement un chatbot qui répond. C’est un système qui EXÉCUTE des actions à votre place :

  • Lire vos courriels.
  • Écrire et envoyer des courriels.
  • Consulter vos fichiers SharePoint, OneDrive ou Google Drive.
  • Faire des recherches sur le web.
  • Naviguer vers des URL et charger leur contenu.

Microsoft 365 Copilot fait tout ça. Claude d’Anthropic avec Computer Use aussi. Les modèles d’OpenAI avec les outils GPT également.

C’est puissant. C’est aussi le vecteur d’attaque.

Le mécanisme d’EchoLeak, étape par étape

Voici comment ça fonctionne.

1. L’attaquant envoie un courriel ordinaire à la victime. Le courriel contient des instructions cachées dans le corps du message, formulées comme des consignes adressées à l’IA plutôt qu’à l’humain.

2. L’utilisateur n’ouvre même pas le courriel. Plus tard, il demande à Copilot une tâche banale : « résume mes derniers échanges avec Untel ».

3. Copilot, pour répondre, accède à la boîte aux lettres y compris le courriel piégé. Il lit les instructions cachées comme s’il s’agissait de commandes légitimes.

4. Les instructions disent à Copilot d’aller chercher des informations sensibles dans le contexte de l’utilisateur (notes internes, extraits de contrats, identifiants) et de les encoder dans une URL pointant vers un serveur contrôlé par l’attaquant.

5. Copilot insère cette URL dans sa réponse, sous forme de lien Markdown ou d’image qui contourne les filtres de sortie.

6. Le client de Copilot charge automatiquement l’image lors de l’affichage de la réponse. Le navigateur de la victime requête l’URL. Les données encodées dedans aboutissent sur le serveur de l’attaquant.

Aucun clic. Aucune alerte. Données exfiltrées.

Pourquoi c’est plus grave qu’un hameçonnage classique

Dans un hameçonnage traditionnel, l’attaquant doit convaincre un humain de cliquer sur un lien ou de fournir un mot de passe. Il existe un point de défense : la méfiance de la victime.

Avec un agent IA, ce point disparaît. L’IA n’a pas de méfiance. Elle ne se dit pas « ce courriel a l’air bizarre ». Elle exécute les instructions textuelles qu’elle trouve dans son contexte.

L’IA n’a pas de conscience du contexte de confiance. Pour elle, un courriel envoyé par un inconnu et une consigne de son propriétaire ont exactement le même poids.

C’est ce qu’on appelle une injection de prompt indirecte. L’attaquant ne parle pas directement à l’IA. Il insère son message dans une source de données que l’IA va consulter : courriel, document partagé, page web, ticket de support, profil de candidat.

Cinq vecteurs réalistes pour votre organisation

Si vous utilisez déjà Copilot, Gemini pour Workspace ou tout agent qui combine lecture de données internes et capacité d’envoyer ou publier vers l’extérieur, voici cinq vecteurs concrets :

  1. Le courriel d’un sous-traitant dont le compte a été compromis. Le courriel contient des instructions cachées qui ciblent VOTRE Copilot.
  2. Un document PDF déposé sur un canal Teams par un participant externe.
  3. Une fiche de candidat importée dans votre ATS, avec un prompt malicieux dans la zone « notes ».
  4. Un ticket client ouvert dans Zendesk ou Salesforce par un utilisateur anonyme.
  5. Une page web consultée par l’agent dans le cadre d’une recherche.

Chacun de ces canaux est une porte ouverte si l’agent a accès à la fois aux données internes et à une capacité de sortie : envoi de courriel, requête HTTP, génération de lien externe.

Trois principes à appliquer dès maintenant

1. Cloisonner les outils. Un agent qui lit vos données sensibles ne devrait PAS avoir de capacité d’envoi externe. Si vous avez besoin des deux fonctions, séparez-les en deux agents distincts sans communication directe.

2. Contrôler le trafic sortant. Mettez en place des règles d’egress restrictives. Bloquez les requêtes vers des domaines non approuvés. Les attaques d’exfiltration passent toutes par une URL qui sort. Coupez la sortie.

3. Approbation humaine pour les actions sensibles. Tout courriel sortant, toute requête vers un domaine externe, tout partage de document devrait nécessiter un clic humain explicite. Pas un consentement global. Un clic par action.

Vous ne pouvez pas vous fier au filtre interne du modèle. Les attaquants le contournent plus vite que les fournisseurs ne le corrigent.

Le parallèle avec ce qu’on connaît déjà

C’est exactement le même schéma que les injections SQL des années 2000. Le développeur faisait confiance aux entrées utilisateur. Il les mélangeait dans une commande. L’attaquant insérait du code malicieux dans le champ « nom ».

La leçon de l’époque tient en une phrase : ne jamais mélanger les données et les instructions.

Les LLM ne savent pas faire cette distinction. Pour eux, tout est du texte. Tout texte présent dans leur contexte est une instruction potentielle.

C’est la raison fondamentale pour laquelle on ne peut pas seulement « bien configurer » un agent. Il faut le cloisonner sur le plan architectural.

Ce qu’il faut retenir

Si votre organisation utilise un agent IA qui :

  • a accès en lecture à vos courriels, fichiers ou systèmes internes,
  • peut envoyer un courriel, faire une requête web ou afficher un contenu externe,

alors vous êtes vulnérable au schéma EchoLeak. Pas en théorie. Concrètement.

La question n’est pas « est-ce que ça peut arriver ». La question est : avez-vous mis en place les contrôles d’architecture pour limiter l’impact quand ça arrivera?

Sources