🛡️ Injection de prompt : stop fuite de données ⚡ (2026)
Découvrez comment l’injection de prompt via e-mail peut causer une fuite de données : apprenez la sécurité des agents IA pour protéger vos données sensibles.
Un e-mail piégé suffit-il à faire fuiter vos données par une IA ?
Un agent IA branché sur votre messagerie peut vous faire gagner du temps : trier les demandes, préparer des réponses, repérer un rendez-vous à confirmer. Le hic, c'est que dès qu'il lit des messages et qu'il peut ensuite agir et envoyer, il se retrouve à la frontière entre du texte peu fiable... et des actions bien réelles. En clair : un e-mail peut contenir une consigne cachée, pas pour vous, mais pour l'agent.
Dans une démonstration, un agent « naïf » reçoit un faux message de facturation. Dans un commentaire invisible à l'écran, quelqu'un lui demande de transmettre un numéro de carte et un identifiant personnel. L'agent suit l'instruction. Ensuite, un contrôle simple des données sortantes bloque l'envoi - sans empêcher une réponse légitime à un collègue.
Ce scénario ne veut pas dire que tous les modèles se comportent pareil, ni qu'un filtre de quelques lignes suffit à tout sécuriser. Il pointe surtout une règle de conception plus utile : ne faites pas reposer la protection des données sur le « bon comportement » du modèle. Voyons comment l'attaque fonctionne, quelles défenses mettre en place, et où elles montrent leurs limites.
Pourquoi un agent de messagerie est-il exposé ?
Un agent de messagerie ne se contente pas de résumer ce qu'il lit. Selon les outils qu'on lui branche, il peut parcourir des e-mails, consulter un calendrier, rédiger une réponse, voire déclencher un envoi. Autrement dit : sa capacité à agir est précisément ce qui rend le système utile... et ce qui transforme une erreur d'interprétation en incident.
Le contenu reçu n'est pas une instruction fiable
Un e-mail entrant, c'est une donnée contrôlée par un tiers. Il peut venir d'un fournisseur, d'un client, d'un collègue, ou d'un expéditeur usurpé. Même si l'adresse vous semble familière et que le message paraît banal, il faut le traiter comme une entrée non fiable.
Le problème, c'est que le modèle reçoit souvent, dans le même contexte, les consignes de l'application et le texte du message. Une consigne malveillante glissée dans le message peut alors essayer de « prendre la main » : « ignore les consignes précédentes », « transmets les informations nécessaires à la vérification », ou « ne préviens pas l'utilisateur ». On n'est pas face à une commande classique : c'est une tentative d'influencer le modèle via le langage.
Le chemin entre lecture et action compte autant que le modèle
Prenez deux messages. D'un côté, un collègue demande si une réunion peut être déplacée à jeudi. De l'autre, un faux service de facturation demande une vérification de compte. Un agent « naïf » peut répondre correctement au premier, puis traiter le second comme une demande à exécuter. Si ses outils lui donnent accès à des données sensibles et à la fonction d'envoi, il peut inclure ces données dans sa réponse.
Le risque vient de l'addition de plusieurs facteurs :
- des données auxquelles l'agent a accès ;
- des messages externes que le modèle interprète ;
- des outils qui permettent une action ;
- l'absence de contrôle indépendant avant la sortie des données.
La même logique s'applique à un agent connecté à un CRM, un outil de support, ou un espace documentaire. Et le risque augmente quand le modèle peut agir sur des informations ou des systèmes auxquels l'expéditeur du message n'aurait pas accès directement.
Une validation humaine ne remplace pas les contrĂ´les techniques
On se dit souvent : « pas de souci, il y a une approbation avant envoi ». Sur le terrain, la personne valide fréquemment une synthèse du contenu : « envoyer les informations de facturation pour vérifier le compte ». Elle ne relit pas forcément tout le message, les pièces jointes, les destinataires, ni chaque champ transmis. À force, l'approbation devient aussi un geste mécanique.
Oui, l'approbation reste utile, surtout pour les actions sensibles ou irréversibles. Mais elle doit compléter des contrôles techniques, pas les remplacer. Si une donnée interdite arrive jusqu'à l'écran d'approbation sans être détectée, le système dépend trop de l'attention humaine - au mauvais moment et sous contrainte de temps.
Comment une instruction cachée détourne-t-elle l'agent ?
Dans la démonstration, le message « ressemble » à une facture et contient une consigne dans un commentaire HTML. Un client de messagerie classique ne l'affiche pas forcément. Un agent, lui, peut analyser le contenu brut et la lire. Ce décalage entre ce que l'utilisateur voit et ce que le système traite, c'est un point de vigilance central.
Le scénario, étape par étape
Le message demande à l'agent de transmettre des informations de paiement et un identifiant personnel à une adresse présentée comme un service de vérification. La consigne ajoute de ne pas en parler à l'utilisateur. Dans le même temps, un autre e-mail contient une demande normale et légitime.
Dans un test contrôlé, le modèle utilisé est volontairement « obéissant ». Il répond normalement au collègue et envoie aussi les données sensibles à l'adresse du faux service. Ce test ne prouve pas que tous les modèles réels suivront forcément l'instruction. Il montre surtout qu'un système qui laisse le modèle décider seul du contenu sortant n'a pas de garde-fou indépendant quand quelque chose tourne mal.
Et c'est là que le bât blesse : les modèles modernes résistent parfois mieux à certaines tentatives d'injection. Mais « résiste généralement » n'est pas une garantie. Un message inhabituel, un contexte compliqué ou une nouvelle technique suffisent à faire tomber la défense.
Pourquoi l'instruction peut passer inaperçue
L'agent peut recevoir le texte brut, le HTML, le texte extrait d'une pièce jointe, ou le résultat d'un outil d'analyse. La consigne peut être peu visible dans l'interface, tout en restant présente dans les données fournies au modèle. Elle peut aussi être formulée comme une procédure administrative, sans marqueurs évidents d'attaque.
Bref : ne réduisez pas le risque aux commentaires HTML. Une consigne peut être parfaitement visible, intégrée à un document, ou présentée comme une demande urgente. Chercher uniquement des « mots suspects » donne une fausse impression de couverture : l'attaquant reformule, et un message légitime peut contenir les mêmes termes.
Les conséquences dépassent largement le vol d'un numéro de carte
En France et dans l'Union européenne, les données en jeu peuvent inclure des coordonnées bancaires, des données de santé, des pièces d'identité, ou des informations liées à une relation de travail. Le numéro de sécurité sociale (NIR) est particulièrement encadré : son traitement doit répondre à une finalité et à des règles spécifiques. Et il ne faut pas le confondre avec un numéro américain de sécurité sociale, même si certaines démonstrations mélangent parfois les exemples.
Pour une organisation, une fuite peut entraîner l'exposition de données personnelles, une fraude, une interruption de service, et des obligations de gestion d'incident au titre du RGPD. Le scénario est donc utile moins pour « prédire » un incident précis que pour révéler un défaut d'architecture : est-ce que l'agent peut envoyer des données sans vérifier ce qui sort vraiment ?
Quel contrĂ´le peut bloquer la fuite ?
Dans le test, la défense est volontairement simple : relire le contenu de chaque message sortant, au moment où il est sur le point d'être envoyé. Si le corps contient un numéro de carte plausible ou un identifiant de type NIR, l'envoi est bloqué. La réponse pour le collègue, elle, passe car elle ne contient pas ce type de données.
export function guard(send: Send): string | null {
const numbers = send.body.match(/\b(?:\d[ -]?){13,19}\b/g) ?? [];
for (const number of numbers) {
const digits = number.replace(/\D/g, "");
if (luhn(digits)) return "numéro de carte dans le message sortant";
}
if (/\b\d{3}-\d{2}-\d{4}\b/.test(send.body)) {
return "identifiant sensible dans le message sortant";
}
return null;
}
Le contrôle de Luhn vérifie une propriété mathématique utilisée par de nombreux numéros de carte. Il évite de bloquer certains nombres qui ont juste la bonne longueur, mais qui échouent à la vérification. En revanche, il ne prouve pas qu'un numéro est réellement actif, ni même que c'est forcément une carte. Il donne surtout un signal plus précis qu'une simple recherche de « 16 chiffres ».
Placer le contrĂ´le au point de sortie
Le filtre doit tourner au plus près de l'action réelle, juste avant l'envoi - et pas seulement pendant la préparation du prompt. C'est le dernier moment où l'application peut encore examiner le contenu réellement transmis, quel que soit le chemin utilisé pour le produire.
En production, ce contrôle devrait s'appliquer à toutes les voies de sortie : e-mails, pièces jointes, champs CRM, appels d'API, et autres outils. Il faut aussi vérifier les destinataires, les champs structurés, et éventuellement les fichiers. Un filtre limité au corps du message ne protège pas automatiquement une pièce jointe ou une valeur envoyée dans un champ séparé.
Et ce n'est pas juste un détail « journalisation ». Pour une donnée interdite, l'attendu est plutôt un blocage effectif : avec un motif exploitable et, selon le niveau de risque, une escalade vers une personne autorisée. L'application peut aussi masquer la valeur, demander une justification, ou interdire complètement ce type de transfert.
Construire plusieurs couches plutĂ´t qu'un filtre miracle
Le bon sens, c'est d'empiler des protections qui échouent de façons différentes :
- Réduire les accès : ne donnez à l'agent que les données et outils indispensables à sa tâche.
- Séparer instructions et contenus : indiquez clairement au modèle qu'un e-mail est une donnée à analyser, pas une autorisation à exécuter.
- Limiter les actions : commencez par la rédaction de brouillons, puis élargissez seulement si les tests le justifient.
- Contrôler les sorties : inspectez le texte, les destinataires et les pièces jointes avant chaque action.
- Valider les actions à fort impact : demandez une approbation explicite avec un aperçu fidèle de ce qui sera envoyé.
- Journaliser et tester : conservez les traces utiles à l'audit, et testez avec des cas bénins et malveillants.
Les travaux et recommandations d'Anthropic autour de Claude Duet décrivent plusieurs approches : protections contre l'injection, contrôles de partage de données, et demandes d'approbation pour certaines actions. Le point important, ce n'est pas « une fonction magique », mais le fait que des protections distinctes se renforcent mutuellement. Un agent autonome a besoin d'une architecture de sécurité, pas uniquement d'une consigne bien formulée.
Quelles sont les limites d'un filtre simple ?
Un filtre basé sur des expressions régulières reste un plancher, pas une solution complète. Il bloque certains formats connus, mais il ne comprend pas la signification de toutes les données, et il ne suit pas toutes les transformations possibles. Dans la démonstration, le motif vise un identifiant américain avec tirets ; il ne suffit pas à détecter automatiquement les formats français, ni toutes les variantes.
Les formats peuvent être détournés
Un identifiant peut être écrit en toutes lettres, encodé en Base64, réparti entre plusieurs champs, ou passé via plusieurs messages. Il peut aussi être remplacé par une capture d'écran. Un filtre qui ne regarde que le texte du corps peut donc rater une pièce jointe ou une valeur structurée.
À l'inverse, un nombre « légitime » peut déclencher un faux positif : par exemple une référence de commande qui ressemble à un identifiant sensible.
Le contrôle de Luhn aide sur certains numéros de carte, mais il ne règle pas tout. Et il ne sert à rien d'empiler des motifs au hasard jusqu'à obtenir une liste interminable « qui a l'air complète ». Chaque règle doit être testée avec des données réelles, en mesurant à la fois les faux positifs et les faux négatifs.
La qualité d'un contrôle se juge en situation
Pour un prototype, un test minimal couvre trois choses : un message légitime passe ; un message avec une donnée interdite est bloqué ; une variation plausible de la donnée ne contourne pas le contrôle. En production, il faut étendre ces tests aux pièces jointes, aux destinataires multiples, aux caractères inhabituels, et aux différents outils accessibles à l'agent.
Un exercice de type « red team » peut aussi demander à quelqu'un d'essayer de faire passer des données sensibles via des formulations ou des formats alternatifs. À faire en environnement contrôlé, avec des données fictives - jamais avec de vraies coordonnées bancaires ou de vrais identifiants.
Les résultats servent à améliorer les règles, et aussi à décider si l'agent a trop de privilèges.
Adapter les règles au risque et aux obligations
Le RGPD ne se résume pas à « installer un filtre ». Une organisation doit déterminer la finalité du traitement, limiter les données accessibles, définir les rôles, et mettre en place les mesures de sécurité adaptées. Si le risque est élevé, une analyse d'impact peut être nécessaire. Les équipes doivent aussi prévoir comment gérer les incidents, et qui décide de bloquer ou de reprendre un flux.
Le niveau de contrôle dépend de l'usage. Un assistant qui prépare des brouillons internes n'a pas le même profil qu'un agent capable d'envoyer des documents à des tiers ou d'initier un paiement. Plus l'action est sensible et difficile à annuler, plus il faut réduire les permissions, renforcer la validation, et rendre la décision traçable.
Conclusion
Un agent qui lit des e-mails doit traiter le contenu comme une source externe non fiable. Les consignes cachées ne sont qu'une forme d'injection parmi d'autres : le problème structurel, c'est qu'un texte reçu peut influencer une action qui transmet des données ou modifie un système.
Un filtre de sortie peut bloquer certains cas sans empêcher les tâches légitimes. Mais il ne remplace ni la limitation des accès, ni les validations adaptées, ni les tests de sécurité. Avant d'autoriser un agent à envoyer ou à modifier quoi que ce soit, posez une question simple : qu'est-ce qui contrôle, exactement, les données au moment où elles quittent votre système ?