Fuite de secrets dans les prompts d’un assistant IA public

Un mot de passe collé dans un assistant d’intelligence artificielle (IA) public quitte le périmètre de l’organisation à la seconde où la requête part, et aucune suppression ultérieure ne le fait revenir. Trois temps structurent le problème : ce qui part réellement, le filtrage en amont par prévention de fuite de données (DLP, Data Loss Prevention), et la réponse quand le secret est déjà dehors.

→ Lire l’explication complète de la marmotte

Ce qui part vraiment avec un prompt collé

Le chiffrement TLS (Transport Layer Security) protège le trajet, pas la destination. Une fois reçu, le prompt vit dans l’historique de conversation du compte, dans les journaux du fournisseur et, selon l’offre souscrite, dans des circuits de revue ou d’amélioration du modèle. La durée de conservation côté fournisseur relève d’une page à part ; ici, une seule règle compte : un secret collé est un secret compromis, parce que personne ne peut prouver qu’il n’a pas été lu.

Les secrets arrivent rarement seuls et presque jamais volontairement. Ils voyagent dans ce qu’on colle pour obtenir de l’aide : une trace d’exception qui contient la chaîne de connexion à la base, un fichier .env joint « pour le contexte », un extrait de journal avec un en-tête Authorization: Bearer, une capture d’écran de console que l’assistant lit par reconnaissance de caractères. Vingt ans de dépannage apprennent que le mot de passe le plus exposé d’un système d’information est celui qui figure dans le message d’erreur que tout le monde copie.

Les données clients suivent le même chemin, avec une différence de taille : elles ne se révoquent pas. Une clé d’accès se remplace en quelques minutes ; une liste de noms, d’adresses et de numéros de contrat envoyée à un tiers reste envoyée.

Filtrage DLP en amont : passerelle, navigateur, poste

Trois points d’interception existent, et chacun a son angle mort.

Passerelle web sécurisée (SWG, Secure Web Gateway) avec inspection TLS. Elle voit le corps des requêtes à condition de déchiffrer le trafic, donc de déployer une autorité de certification interne sur tous les postes. Les assistants envoient souvent le prompt en JSON (JavaScript Object Notation) dans une requête en flux ou sur WebSocket : une règle qui n’analyse que les formulaires classiques laisse tout passer.
Extension navigateur de DLP. Elle lit le champ de saisie avant chiffrement, sans casser le TLS. Elle ne couvre que les navigateurs gérés : un navigateur portable ou une application de bureau la contourne.
Agent DLP sur le poste. Il surveille le presse-papiers et les téléversements, applications de bureau comprises, au prix d’un agent de plus à maintenir partout.

Un CASB (Cloud Access Security Broker) branché par API (Application Programming Interface) sur l’espace entreprise analyse les conversations après coup : il détecte, il n’empêche pas.

Côté détecteurs, la hiérarchie est nette. Les secrets à préfixe fixe (clés AWS pour Amazon Web Services, jetons GitHub, clés privées au format texte, jetons Slack) donnent des faux positifs quasi nuls. La détection par entropie attrape aussi les empreintes et les identifiants aléatoires, avec assez de bruit pour que les utilisateurs apprennent à cliquer sur « continuer » sans lire. Les données personnelles structurées (IBAN, International Bank Account Number, avec sa clé de contrôle modulo 97 ; adresses électroniques en volume) se détectent correctement ; un nom de client isolé, jamais.

Le compromis central se joue entre blocage et avertissement. Bloquer coûte des tickets et pousse vers les contournements ; avertir laisse passer une bonne part des cas. Position : bloquer les secrets à préfixe fixe, avertir avec justification obligatoire sur les données personnelles, journaliser le reste. Le masquage automatique avant envoi brille sur les slides des éditeurs, mais il casse le contexte que l’utilisateur voulait transmettre et ne vaut que s’il est déterministe.

Ce que le filtrage ne garantit pas : la photo d’écran prise au téléphone, le secret découpé en trois messages, encodé en base64 ou retapé à la main. La DLP réduit l’accident ; elle n’arrête pas un utilisateur décidé, ce qui relève de la politique d’usage et du contrôle des comptes.

Exemple : tester les motifs de secrets avant d’écrire la règle DLP

Avant de charger des motifs dans une passerelle, les passer sur des données réelles donne la mesure des faux positifs. Ce sont des expressions régulières étendues POSIX (Portable Operating System Interface), transposables dans tout moteur DLP qui accepte ce format.

# Motifs à préfixe fixe : faux positifs quasi nuls, candidats au blocage
cat > motifs-secrets.txt <<'EOF'
AKIA[0-9A-Z]{16}
-----BEGIN ([A-Z]+ )?PRIVATE KEY-----
gh[pousr]_[A-Za-z0-9]{36}
xox[baprs]-[A-Za-z0-9-]{10,}
eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.
EOF

# Contrôle ponctuel du presse-papiers (session X11) avant un collage
xclip -selection clipboard -o | grep -En -f motifs-secrets.txt

# Mesure sur des journaux applicatifs : chaque ligne trouvée est un secret
# qui aurait pu partir dans un prompt (et qui traîne déjà hors du coffre)
grep -rEn -f motifs-secrets.txt /var/log/ 2>/dev/null | cut -c1-120 | head -n 20

Réponse quand le secret est parti

L’ordre compte, et il est contre-intuitif : révoquer d’abord, nettoyer ensuite. Supprimer la conversation rassure mais ne ferme rien, puisque les copies côté fournisseur suivent leur propre cycle de conservation. Seule la rotation rend le secret inexploitable.

Révoquer ou faire tourner le secret, puis invalider les jetons et sessions dérivés : changer un mot de passe ne coupe pas forcément les sessions déjà ouvertes.
Chercher un usage du secret entre l’heure du collage et l’heure de rotation, dans les journaux du système concerné (journal d’API du fournisseur cloud, journaux d’authentification de l’annuaire).
Supprimer la conversation, ainsi que tout lien de partage créé depuis elle.
Si des données personnelles sont parties, saisir le délégué à la protection des données (DPO, Data Protection Officer) : le RGPD (Règlement général sur la protection des données) prévoit 72 heures pour notifier une violation présentant un risque, et la qualification de ce risque lui revient.

Reste le cas qui fâche : le secret non révocable, par exemple le mot de passe partagé d’un équipement ancien. L’assistant n’a pas créé cette dette ; l’incident permet au moins de la chiffrer.

Condition d’exploitation souvent oubliée : les journaux DLP contiennent le secret intercepté. Une console qui affiche la valeur complète dans l’alerte devient le plus bel entrepôt de mots de passe du système d’information. Masquer la valeur (quelques caractères et une empreinte), restreindre l’accès aux analystes, fixer une rétention courte. Les mêmes règles valent pour la télémétrie des applications qui appellent un modèle, détaillées dans l’observabilité d’un grand modèle de langage (LLM, Large Language Model) en production ; la réponse à incident au sens large relève de Menaces, détection et réponse, la qualification des données de Données, vie privée et souveraineté.

🐝 Ce qui arrive si on s’en passe

Sans filtrage en amont, l’historique de conversation du compte devient une archive consultable de tout ce qui a été collé depuis des mois. Un attaquant qui vole la session ou le mot de passe d’un seul utilisateur de l’assistant n’a plus besoin de fouiller le réseau : la recherche intégrée à l’historique lui sert d’index, et une requête sur « password » ou « BEGIN PRIVATE KEY » ramène les secrets avec leur contexte (nom du serveur, environnement, usage). Cette consultation passe par le compte légitime, depuis l’interface normale de l’assistant, et ne laisse aucune trace dans les journaux des systèmes dont les secrets sont extraits.

🦫 Explication de la marmotte 🍫

Quand quelqu’un colle un texte dans un assistant en ligne, ce texte part sur les ordinateurs de l’entreprise qui fournit l’assistant. Le trajet est protégé, mais à l’arrivée le texte est enregistré : dans l’historique du compte, dans les journaux du fournisseur, parfois ailleurs selon le contrat. Si ce texte contenait un mot de passe ou une clé d’accès, il faut considérer que d’autres peuvent l’avoir lu, puisque personne ne peut prouver le contraire. Souvent, le secret n’est même pas collé exprès : il se cache dans un message d’erreur ou dans un fichier de réglages envoyé pour demander de l’aide. Pour limiter les dégâts, l’entreprise peut installer des outils qui lisent le texte juste avant son départ et reconnaissent les formes typiques des secrets, par exemple une clé qui commence toujours par les mêmes lettres. Ces outils bloquent les cas évidents et avertissent pour les autres, mais ils ne voient pas une photo prise avec un téléphone. Si un secret est quand même parti, la première chose à faire est de le changer, car effacer la conversation n’efface pas les copies. Ensuite, on vérifie si quelqu’un s’en est servi, on supprime la conversation et, si des informations sur des personnes sont parties, on prévient la personne chargée de la protection des données.

Pages voisines

La citent

Fuite de secrets dans les prompts d'un assistant IA public

Elle cite

: les deux pages se citent l’une l’autre.