Anatomie d'une fuite vers l'IA : trois histoires tirées de notre télémétrie

Trois incidents, trois leçons, aucun nom de client

Ce que nous pouvons publier de plus utile, ce n'est ni un benchmark ni un livre blanc. C'est ce qui se passe vraiment, dans de vraies organisations, la semaine qui suit l'activation de Zeuslock. Les trois récits ci-dessous sont des cas composites construits à partir de schémas que nous voyons se répéter dans la télémétrie de nos clients. Secteurs, effectifs, géographies et détails ont été suffisamment modifiés pour qu'aucune organisation ne soit identifiable. En revanche, la logique de détection et la réponse humaine sont rapportées telles qu'elles se sont produites.

Chaque histoire suit la même trame : le contexte (qui faisait quoi), ce que nous avons vu (la détection, avec un aperçu masqué), ce qui s'est déclenché (quel détecteur, quelle sévérité, quelle action) et ce que le client a fait ensuite (le changement de politique ou de procédure qui ferme la boucle). L'objectif n'est pas de pointer du doigt les collaborateurs. Dans chaque cas, la personne essayait simplement d'aller plus vite dans son travail. L'objectif est de montrer l'écart entre l'intention et l'exposition, et à quoi ressemble un contrôle utile au bon moment.

Histoire 1 : une clé AKIA, une stack trace et une vraie session de debug

Un développeur backend dans une fintech en série B était en train de gérer un incident de production depuis trois heures. Le pipeline de déploiement s'était bloqué sur une erreur de permissions et l'équipe brûlait sa matinée pour livrer un correctif avant l'ouverture des marchés. Le développeur a copié la stack trace CloudWatch qui échouait, ouvert Microsoft Copilot dans VS Code et posé la question évidente : pourquoi cela échoue, et quelle permission dois-je ajouter à ce rôle IAM ?

Le bloc collé faisait une soixantaine de lignes. Enfouie en ligne 14 : l'access key ID AWS littéralement utilisée par le runner de déploiement, sous la forme AKIAIO******************, accompagnée de la région, de l'ARN du rôle et d'assez de contexte pour rendre la credential triviale à utiliser si elle quittait jamais l'entreprise. Le développeur n'avait pas copié un secret volontairement. Il avait copié une stack trace qui contenait un secret.

L'extension navigateur et l'agent desktop Zeuslock se sont déclenchés en quelques millisecondes. Le détecteur déclenché : api_key:aws sur la couche regex stricte (préfixe AKIA plus 20 caractères en base32), confirmé en moins de 80 ms par le modèle ML hébergé dans l'UE avec un score de confiance élevé. Sévérité : critique. Action en vigueur à ce moment dans la politique développeurs : Anonymisation. Le texte est arrivé chez Copilot avec la clé remplacée par un leurre structurellement valide, le reste de la trace intact. Copilot a quand même produit une réponse parfaitement utile sur la permission s3:PutObject manquante, parce que le modèle n'a jamais eu besoin de la vraie clé pour raisonner sur IAM.

La Console Opérateur a enregistré l'incident avec attribution complète : utilisateur, machine, URL source (github.com/copilot) et un hash salé du secret brut, pour que l'équipe sécurité puisse corréler avec AWS CloudTrail sans jamais stocker le secret. La réponse du responsable sécurité a été double. D'abord, la clé AKIA a été tournée dans l'heure par hygiène, même si elle n'avait jamais quitté le poste. Ensuite, la politique développeurs est passée de Anonymisation à Blocage pour la famille api_key:* sur tous les groupes d'ingénierie, et un hook pre-commit gitleaks a été ajouté à chaque dépôt backend, pour que la même classe de fuite soit attrapée une couche plus tôt, au git commit plutôt qu'au collage dans un outil IA.

Histoire 2 : 200 lignes d'historique client, collées dans ChatGPT pour du « sentiment »

Une analyste support senior d'un retailer en ligne mid-market préparait son résumé hebdomadaire d'escalades pour le responsable de la relation client. L'outil interne habituel était lent ce jour-là ; l'analyste a donc exporté la semaine de fils de réclamation depuis le CRM en CSV, ouvert ChatGPT, collé les 200 lignes et demandé : résume les trois principales réclamations par thème et dis-moi lesquelles ont l'air les plus en colère.

Le bloc contenait 47 adresses e-mail clients, 31 adresses postales en France, en Espagne et en Allemagne, l'historique de commandes complet pour chaque réclamation et, dans 12 cas, un fragment de numéro de carte de la forme **** **** **** 4242. Du point de vue du RGPD, c'était un transfert ultérieur illicite vers un sous-traitant américain situé hors de la chaîne de traitement déclarée. L'analyste n'était pas malveillante. ChatGPT était plus rapide que l'outil interne, et personne ne lui avait jamais expliqué le contraire de manière concrète.

Zeuslock a déclenché trois détecteurs en une seule soumission : email (47 hits, haute confiance), address (31 hits, haute confiance, sensible à la locale FR / ES / DE) et credit_card_partial sur les fragments de PAN masqués. Sévérité : élevée. Action dans la politique de l'équipe support : Anonymisation. Le prompt qui a réellement atteint ChatGPT a été réécrit à la volée : chaque e-mail est devenu user1@example.com, user2@example.com et ainsi de suite, chaque adresse est devenue une adresse européenne structurellement valide mais fictive dans le même pays, chaque PAN partiel est devenu un faux PAN passant le test de Luhn. Le texte des commandes et les phrases de réclamation, eux, n'ont pas été touchés. ChatGPT a produit un résumé tout à fait utile — les trois thèmes principaux étaient les retards de livraison, l'incohérence des tailles sur une gamme spécifique et un bug d'affichage de facturation — parce qu'aucun de ces raisonnements ne nécessitait de vraies données personnelles.

Le client a fait un changement modeste mais à fort effet de levier. Il n'a pas bloqué ChatGPT pour l'équipe support. Il a ajouté une page au guide utilisateur interne intitulée « le bon réflexe », avec une capture d'écran de l'aperçu anonymisé de Zeuslock et la phrase : voici à quoi ressemblait réellement votre prompt pour le modèle, la réponse est restée utile, vous pouvez continuer à utiliser ce schéma. Le respect de la politique a progressé parce que l'équipe a vu, visuellement, que le bon réflexe ne lui coûtait rien.

Le comportement que l'on cherche n'est pas « arrêtez d'utiliser l'IA ». C'est « utilisez l'IA librement, sur une charge utile qui a été nettoyée de ce qui n'aurait jamais dû y figurer ». L'anonymisation est le pont.

Histoire 3 : 400 lignes de propriété intellectuelle, des conseils de refactoring et une application desktop

Un ingénieur senior dans une healthtech européenne refactorait un module au cœur du moteur de scoring propriétaire qui, soyons honnêtes, constitue à lui seul la raison pour laquelle l'entreprise a des investisseurs. L'ingénieur a ouvert l'application desktop Claude et collé un module Python de 400 lignes pour demander des suggestions de refactoring, en particulier comment aplatir un ensemble de conditions imbriquées pour le rendre plus testable. Le module contenait les poids de scoring eux-mêmes, les noms de fonctions qui correspondent directement à la méthodologie brevetée et le préfixe de package interne qui n'existe que dans cette entreprise.

C'est la classe de fuite la plus difficile à attraper. Il n'y a pas de regex pour « notre propriété intellectuelle ». La détection Zeuslock qui a fonctionné ici était stratifiée : une heuristique générique source_code a marqué la soumission comme un gros bloc Python à forte densité syntaxique et faible ratio de langage naturel, et un détecteur personnalisé que le client avait construit trois semaines plus tôt — matchant son préfixe de package interne et trois noms de fonction réservés — a fait passer la sévérité de moyenne à critique. Action dans la politique de l'équipe propriétaire de la PI : Blocage. L'agent desktop a intercepté la soumission avant qu'elle ne quitte le poste. Claude n'a rien reçu. L'ingénieur a vu une fenêtre modale expliquant ce qui avait été détecté, un lien vers la page de politique interne et un chemin en un clic pour demander une exception à l'équipe sécurité si le refactoring pouvait vraiment être fait à l'extérieur.

La suite est la plus intéressante des trois sur le plan opérationnel. Plutôt que de durcir la politique pour tout le monde, le client a scindé la politique développeurs en deux profils. Les équipes qui touchent au moteur de scoring, aux chemins de code brevetés et au pipeline d'entraînement du modèle tournent sous un profil strict : source_code et le détecteur PI personnalisé sont tous les deux en Blocage. Les équipes qui livrent des services utilitaires, du tooling interne et le site marketing public tournent sous un profil plus souple : source_code reste en Anonymisation, pour qu'elles continuent à obtenir de l'aide au refactoring sur du code où le coût d'un collage externe est essentiellement nul. La séparation a été publiée comme une note d'une seule page et rendue applicable via les groupes SCIM existants, pour qu'aucun ingénieur n'ait à se rappeler dans quel mode il est — l'agent, lui, le sait.

Ce que ces trois cas ont en commun

Lus ensemble, les trois récits riment plus qu'ils ne diffèrent. Dans chaque cas, le collaborateur était productif, pas négligent. Dans chaque cas, le secret ou la donnée personnelle était incident à la question posée — personne n'a collé une clé pour fuiter une clé, on a collé une clé parce qu'elle était attachée au message d'erreur sur lequel on voulait vraiment de l'aide. Dans chaque cas, le modèle aurait produit la même réponse utile sur un payload anonymisé ou vide. Et dans chaque cas, le correctif durable n'était pas un mémo. C'était un changement de politique câblé dans l'agent, soutenu par un petit changement de processus câblé dans l'équipe.

Pour mettre des chiffres sur ce qu'il y a à faire ce trimestre :

1. Passez la famille api_key:* en Blocage pour les groupes d'ingénierie. Le taux de faux positifs sur les patterns AWS, Stripe, GitHub, Slack et OpenAI est suffisamment faible pour que Blocage soit pertinent dès la semaine 3. Couplez-le à un hook pre-commit dans les dépôts qui comptent.
2. Gardez les PII en Anonymisation pour les équipes non techniques, et documentez le bon réflexe. Montrez l'aperçu masqué. Montrez que le modèle reste utile. Le changement de comportement arrive quand le bon réflexe ne coûte visiblement rien.
3. Construisez au moins un détecteur personnalisé sur votre propre PI. Prenez le préfixe de package interne, les identifiants de brevet, les noms de fonction réservés. Backtestez-le sur les 30 derniers jours d'incidents dans la Console Opérateur avant de le basculer en Blocage. Le détecteur que vous construisez en un après-midi attrapera une fuite qu'aucune regex générique de vendeur n'aurait attrapée.
4. Séparez la politique développeurs par équipe, pas par outil. Les équipes qui possèdent la PI ont besoin d'un profil différent des équipes utilitaires. Câblez la séparation via vos groupes d'identité existants, pour qu'elle reste appliquée automatiquement quand les gens arrivent, bougent et partent.

Rien de tout cela n'exige un nouvel outil, un nouveau processus ou un mémo au COMEX. Cela exige de regarder les trois lignes de votre tableau d'incidents qui vous ont le plus inquiété ce mois-ci et d'être honnête sur le mode de politique qui les aurait arrêtées. Pour le détail côté opérateur, voyez le guide configuration des politiques de détection et la référence détecteurs personnalisés. Les trois histoires ci-dessus ont démarré au même endroit que les vôtres. Elles se sont terminées par un changement de politique assez petit pour être livré un vendredi.