Le 12 octobre, Anthropic a indiqué que ses nouvelles mesures contre la distillation avaient réduit de 10 à 100 fois le volume de raisonnement de Claude extrait par des acteurs malveillants via sa plateforme. L’entreprise décrit un système à plusieurs niveaux : il complique la divulgation du raisonnement caché, suit le transfert de requêtes entre comptes et modèles, et bloque les demandes suspectes. Pour les développeurs d’API, cela importe pour deux raisons : la protection modifie le comportement des intégrations, et certaines requêtes bloquées sont désormais facturées.

La distillation permet d’entraîner un modèle plus petit à partir des réponses d’un système plus puissant. Anthropic estime que les enregistrements complets du raisonnement que Claude produit avant sa réponse finale sont particulièrement précieux à cette fin. Lors des premiers essais de l’entreprise, un modèle entraîné sur les transcriptions complètes de Claude Opus 4.8 a obtenu 80,4 % à SWE-bench Verified ; avec des versions raccourcies, le résultat était de 71,8 %. Ces chiffres concernent un test et une expérience spécifiques d’Anthropic, et ne constituent pas une évaluation universelle de la qualité des modèles.
Une protection contre plusieurs voies d’extraction
La première couche consiste à réduire la quantité de raisonnement divulguée. Selon Anthropic, après l’introduction de cette mesure, les tentatives se sont intensifiées : les requêtes ont commencé à demander directement la divulgation du raisonnement caché, puis des réseaux d’intermédiaires et de nombreux faux comptes ont été utilisés. L’entreprise affirme que l’un de ces réseaux gérait simultanément plus de 20 000 comptes.
Les nouvelles mesures contrôlent où les fragments de raisonnement protégés peuvent être transférés. Anthropic cite les transferts entre conversations, modèles et comptes parmi les moyens de contourner les protections individuelles. Selon l’entreprise, un classificateur en deux étapes détecte désormais toutes les techniques de distillation décrites dans son rapport de septembre sur les modèles publics les plus puissants.
Anthropic mesure l’effet en comptant les jetons de raisonnement que les acteurs de la distillation ont pu extraire sur sa plateforme. Après le déploiement du classificateur, cet indicateur a été réduit de 10 à 100 fois par rapport à son niveau précédent ; certains jours, le volume était trop faible pour être mesuré. L’entreprise indique également avoir bloqué des dizaines de milliers de comptes liés à la distillation. Ces données décrivent la télémétrie propre à Anthropic, et non le volume total d’extraction via des clouds tiers et des fournisseurs d’inférence.
Ce qui change pour les développeurs
La protection a déjà eu des effets sur certaines intégrations légitimes. Anthropic indique que le format de raisonnement conservé a nécessité des mises à jour de la part de certains développeurs, et que les classificateurs identifient à tort ou bloquent des requêtes inoffensives dans moins de 0,1 % des cas. Depuis le 24 septembre, l’entreprise facture les requêtes interrompues avant la génération d’une réponse dans des catégories où ce taux de faux positifs est déclaré, notamment la distillation.
En pratique, les équipes qui utilisent l’API devraient vérifier, après ces changements de traitement du raisonnement, quels champs de réponse leur application lit et conserve, ainsi que la façon dont elle gère un refus ou un blocage avant génération. Elles devraient également tenir compte du fait qu’une requête bloquée mais facturée peut engendrer des coûts sans fournir de réponse utile. C’est particulièrement important pour les nouvelles tentatives automatiques : répéter la même demande ne corrige pas la classification et peut augmenter les coûts.
Dans sa description des nouvelles mesures, Anthropic reconnaît que le système reste pris dans une course contre les attaquants : l’entreprise ignore combien de temps la réduction obtenue se maintiendra et n’a pas encore observé de tentative extrêmement persistante visant à contourner la protection mise à jour. Le changement pratique le plus concret est déjà en place : les développeurs doivent tenir compte du traitement révisé du raisonnement, du risque de rares blocages et de la facturation de certaines requêtes rejetées.