Claude. Les défenses contre la distillation changent aussi certaines intégrations

Anthropic publie le 12 octobre 2026 un bilan de ses défenses contre l’extraction des capacités de Claude. L’entreprise estime avoir réduit de 90 à 99 % les données récoltées par les acteurs qu’elle identifie comme distillateurs. Ce résultat relève de sa propre mesure. Le billet expose aussi des effets pour certains utilisateurs légitimes de l’API. Le sujet concerne donc les protections du modèle autant que le fonctionnement des intégrations.

Protéger le raisonnement utilisé pour entraîner un autre modèle

La distillation permet de transférer des comportements d’un modèle vers un autre à partir de ses sorties. Le billet porte sur des campagnes d’extraction sans autorisation décrites par Anthropic. L’entreprise souligne la valeur particulière des traces de raisonnement. Elle explique avoir associé plusieurs mécanismes pour rendre leur collecte plus difficile.

Son dispositif comprend un contrôle des blocs de raisonnement et un classifieur en deux étapes. Il comprend aussi des restrictions contre les tentatives répétées. La baisse annoncée ne constitue pas un taux universel de sécurité de Claude. Elle mesure un objectif particulier sur la plateforme de l’éditeur. Anthropic indique que les attaquants peuvent encore faire évoluer leurs méthodes. Le résultat n’est donc pas présenté comme une protection définitive.

Certaines intégrations doivent conserver le contexte antérieur

La documentation de preserved thinking explique le contrôle des blocs de raisonnement renvoyés à l’API. Leur signature permet notamment de vérifier le modèle qui peut les lire. Elle permet aussi de vérifier que les éléments précédant le bloc sont restés identiques. Ce préfixe comprend le message système et les outils ainsi que les messages concernés.

Pour les comptes créés depuis le 31 août 2026, le contrôle du préfixe s’applique par défaut. Il peut notamment concerner une intégration qui réécrit son contexte entre deux appels tout en conservant les blocs de raisonnement précédents. Selon le paramétrage, un bloc invalide peut être supprimé ou la requête peut être rejetée. Il faut donc séparer cette vérification d’un simple problème de connexion.

Une limite précise qui ne concerne pas tous les usages

La documentation indique qu’il n’y a pas de changement à effectuer lorsque Claude Code ou l’application Claude construit les requêtes. Elle cite également les outils gérés par Anthropic et les intégrations qui conservent le préfixe puis ajoutent les nouveaux messages. Si aucun bloc de raisonnement n’est renvoyé, ce contrôle n’a pas de bloc à rejeter. Ces conditions évitent de laisser croire que tout utilisateur doit modifier son historique manuellement.

Une requête refusée peut aussi être facturée

Le bilan du 12 octobre rappelle une modification introduite le 24 septembre. Certaines requêtes bloquées avant une réponse sont de nouveau facturées. La documentation sur les refus et leur traitement précise les catégories actuelles. Le refus avant toute sortie est facturé pour les catégories bio et frontier_llm ainsi que reasoning_extraction. Les autres catégories ne le sont pas dans cette situation. Un refus pendant la génération possède une autre règle de facturation.

Le motif du refus peut donc aider à comprendre la facture. Il peut aussi guider la réponse de l’application. Une erreur réseau et un refus de classifieur ne correspondent pas au même état. La documentation décrit un refus pouvant arriver avec un statut HTTP 200 et une raison de fin nommée refusal. Une application qui vérifie seulement le statut HTTP risque de traiter une absence de réponse comme une réussite normale.

Demander une explication reste différent d’extraire les traces internes

La documentation permet de demander une explication courte et les éléments qui soutiennent une réponse. Elle distingue cette demande de la reproduction intégrale du raisonnement interne. Pour une équipe qui analyse un résultat, les sources et les actions observées peuvent être plus utiles qu’une demande de copie complète de ces traces.

Ce point ne garantit pas que chaque refus sera justifié. Anthropic reconnaît l’existence de faux positifs et des adaptations nécessaires pour certains développeurs. Les taux publiés restent ceux de l’entreprise. L’analyse d’un incident concret doit donc revenir à la requête et à sa catégorie plutôt qu’au seul chiffre global annoncé.

Ce bilan apporte une information sur l’accès aux modèles et ses limites. Il ne concerne pas le même dispositif que les restrictions des environnements de recherche. Pour distinguer ces deux sujets, consultez notre article sur les actions inattendues examinées par Anthropic pendant ses évaluations.