La bataille de la distillation d'OpenAI est entrée le 1er octobre dans un deuxième round embarrassant. Selon un article de The Decoder publié ce jour-là, au lendemain de l'annonce par l'entreprise de la neutralisation d'une campagne de distillation de modèles à grande échelle, des chercheurs indépendants ont publié une mise à jour de leur étude affirmant que la même technique de vol fonctionne toujours sur Microsoft Azure — le raisonnement caché du tout nouveau GPT-6 Astra lui-même peut être « volé » mot pour mot.
Tout a commencé avec le billet officiel d'OpenAI du 30 septembre, « Disrupting a coordinated model-distillation campaign ». L'entreprise y révélait que depuis le 1er juillet, un groupe avait utilisé des dizaines de milliers de requêtes soigneusement conçues pour tenter d'extraire le raisonnement interne caché de ses modèles ; l'activité avait culminé les 24 et 25 juillet — 16 000 requêtes présentant des motifs d'extraction en deux jours, provenant de plus de 4 000 utilisateurs, des motifs connexes couvrant plus de 15 000 comptes — avant d'être totalement stoppée le 28 juillet. OpenAI a attribué le groupe central à des personnes liées à Moonshot AI (le créateur de Kimi), en précisant en note de bas de page que ces chiffres comptaient des tentatives, pas nécessairement des succès. En riposte, OpenAI a banni les comptes frauduleux, resserré les inscriptions, fermé le canal permettant de rejouer du raisonnement chiffré et ajouté une détection de fuites aux sorties en streaming. Ce site avait déjà couvert cette annonce : OpenAI révèle une attaque de distillation de modèles : 16 000 requêtes d'extraction pointent vers Moonshot.
Nouveau test : les API maison ont tenu — pas Azure
Le drame s'est joué le jour même de l'annonce. L'équipe du chercheur Joachim Schaeffer a mis à jour sur stolen-thoughts.com son étude « Stealing Reasoning Traces from Proprietary LLM APIs », avec un titre qui disait tout : « We stole reasoning. Again. » (Nous avons encore volé le raisonnement.)
Le 13 septembre, ils ont retesté la même méthode : sur les propres API d'OpenAI et d'Anthropic, l'attaque était désormais bloquée ; mais sur Microsoft Azure, tous les modèles OpenAI testés — y compris le nouveau GPT-6 Astra — et les modèles Anthropic jusqu'à Sonnet 5 sont tombés : une seule tentative suffisait à extraire le raisonnement mot pour mot. Pour reprendre les mots de Schaeffer : « Les mêmes modèles, mais des protections totalement différentes selon la plateforme qui les sert. »
Une deuxième voie encore plus simple : donner au modèle un « bloc-notes »
Les chercheurs ont aussi révélé une deuxième méthode, encore plus simple, démontrée par le développeur Can Bölük : donner au modèle un outil « bloc-notes » virtuel et lui dire d'y écrire son raisonnement — l'utilisateur peut ensuite lire ce qui a été écrit. La méthode a fonctionné sur tous les modèles OpenAI ainsi que sur Opus 4.8 et Sonnet 5 ; seuls Opus 5, Fable 5 et Fable 5.1 ont résisté. Selon les chercheurs, la sortie de la méthode du bloc-notes ressemble fortement à celle de l'attaque par déchiffrement et serait « tout aussi utile » pour la distillation.
Pourquoi les correctifs arrivent toujours en retard
La chronologie explique l'embarras. GPT-6 Astra a été lancé sur des plateformes tierces sans aucune protection ; OpenAI n'a ajouté de protections au point de terminaison Azure que le 27 septembre — plusieurs jours après la sortie du modèle. Côté Anthropic, l'extraction sur Azure n'a cessé d'être reproductible qu'à partir du 28 septembre.
Les chercheurs qualifient les correctifs déployés jusqu'ici de bricolage superficiel : beaucoup de défenses ne sont que des correspondances fragiles contre des motifs de requêtes précis, et elles n'atteignent les plateformes cloud que plusieurs jours après les fournisseurs de modèles. Les attaquants n'ont pas besoin de forcer la porte la plus solide ; il leur suffit de trouver la fenêtre la plus faible.
La thèse des chercheurs : les clouds qui ne suivent pas ne devraient pas héberger de modèles de raisonnement
L'article va plus loin : les correctifs doivent couvrir chaque technique d'attaque et chaque cloud hébergeant les modèles, faute de quoi les attaquants choisiront toujours la route la plus faible. Et au-delà, les chercheurs soutiennent que les fournisseurs cloud n'appliquant pas des protections équivalentes ne devraient tout simplement pas être autorisés à héberger des modèles de raisonnement — sinon, des portes dérobées ouvertes permettraient de contourner aisément les contrôles à l'exportation au niveau des API.
La réponse d'OpenAI a été de reconnaître que les modèles hébergés par des partenaires nécessitent la même protection que ses propres services, et que « le travail n'est pas terminé ».
Pour les entreprises qui utilisent réellement les API de raisonnement dans le cloud, la leçon est concrète : le niveau de sécurité du modèle appelé ne dépend pas du nombre de correctifs expédiés par le fournisseur du modèle, mais de la mesure dans laquelle votre cloud a suivi. Plus le modèle est puissant, plus son raisonnement a de la valeur — et plus il y aura de gens pour vouloir le « voler ». Cette bataille ne fait qu'entrer dans sa seconde mi-temps.
