Changer de modèle peut exposer le raisonnement caché de GPT et Claude

Vers le 27 août 2026, l'utilisateur X @kotekjedi_ml a publié une série de résultats expérimentaux inhabituels : des blocs de raisonnement caché dans les API de Claude, GPT et Gemini — normalement jamais montrés aux utilisateurs — ont été restitués par des chercheurs en sécurité sous forme de texte lisible. Par construction, une fois son raisonnement interne terminé, le modèle voit ce contenu chiffré côté serveur en un bloc opaque renvoyé au client ; le client détient cette donnée sans pouvoir la lire ni la modifier, et la renvoie telle quelle à l'appel suivant pour que le modèle reprenne là où il s'était arrêté. Les chercheurs n'ont ni cassé ce chiffrement ni obtenu de clé côté serveur : ce qu'ils ont contourné, c'est le périmètre d'usage du bloc, pas le chiffrement lui-même.

Pourquoi le raisonnement caché quitte-t-il le modèle

La différence entre un modèle de raisonnement et un simple modèle de conversation ne tient pas qu'à quelques étapes de réflexion en plus avant la réponse : ces états intermédiaires doivent souvent être réutilisés au fil d'une tâche longue ou d'une exécution agentique, à mesure que le modèle décompose un problème, teste des approches, lit des résultats d'outils et révise son jugement. Un serveur pourrait conserver l'historique complet du raisonnement pour chaque session, mais cela alourdit le stockage et la gestion du contexte ; de nombreuses API préfèrent donc emballer le raisonnement interne dans un bloc illisible pour le client, le lui confier pour qu'il le garde, puis le vérifier et le réutiliser à l'appel suivant. Cela empêche la lecture ou l'altération directe, mais crée un problème de permissions resté jusque-là peu visible : le chiffrement et la signature prouvent qu'un bloc a bien été généré par le serveur et n'a pas été modifié de l'extérieur, mais pas qu'il appartient toujours au bon compte, à la bonne session ou au bon modèle — un raisonnement parfaitement légitime peut se retrouver là où il ne devrait pas être.

Faire «parler» un modèle puissant

Les chercheurs ont constaté que ces blocs de raisonnement caché ne restent pas toujours verrouillés à leur contexte d'origine : certains peuvent être réutilisés d'une session à l'autre, d'autres même resoumis sous un autre compte, et surtout, certains peuvent être lus par d'autres modèles du même fournisseur. Chez Claude, par exemple, Opus termine une tâche normale, le serveur génère le raisonnement caché correspondant et renvoie au client un bloc de pensée signé. Plutôt que de chercher à faire livrer sa chaîne de pensée à Opus lui-même, les chercheurs ont chargé ce bloc dans le contexte d'un autre modèle, Haiku — qui a pu charger un raisonnement appartenant à l'origine à Opus. Une fois cette étape franchie, la cible change de nature : plus besoin de contourner les restrictions propres à Opus, il suffit que Haiku, plus facile à contourner, restitue à voix haute ce qu'il a déjà chargé. Les modèles d'une même famille n'ayant pas la même robustesse d'alignement ni la même résistance au jailbreak, les garde-fous protégeant le modèle puissant peuvent être contournés via un «cousin» plus faible.

Prouver que le contenu restitué est authentique

Les chercheurs n'avaient pas accès à la trace de raisonnement en clair conservée côté serveur, et ne pouvaient donc pas la vérifier jeton par jeton — ils se sont appuyés sur des signaux indépendants pour juger si le texte restitué correspondait vraiment à l'état caché d'origine.

• Ils ont fait traiter 120 problèmes de programmation Codeforces par un modèle source, en enregistrant le nombre de jetons de raisonnement caché rapporté par l'API, puis ont comparé ce chiffre à la longueur du texte restitué : chez plusieurs modèles d'Anthropic, d'OpenAI et de Google, les longueurs restituées suivaient de près les nombres de jetons rapportés par l'API, se regroupant près de la droite où les deux chiffres coïncident exactement.
• Ils ont rassemblé 6 708 journaux publics d'exécutions d'agents sur GitHub et Hugging Face, qu'ils ont découpés en 315 320 blocs de raisonnement. Une fois restitué, le contenu comportait des clés d'API, des mots de passe, des jetons d'accès, des clés privées et des adresses e-mail — dont certains n'étaient jamais apparus nulle part dans l'historique de conversation public, ce qui signifie que le modèle de restitution n'aurait pas pu deviner ces valeurs précises à partir du seul texte visible.

Ce résultat a mis au jour un autre problème dans les journaux d'agents : même après qu'un utilisateur a supprimé un mot de passe ou une clé de son historique de discussion ou d'un dépôt de code, la même information peut subsister dans un ancien bloc de raisonnement caché, l'agent ayant très bien pu la lire en modifiant du code, en ajustant une configuration ou en nettoyant un dépôt — et une fois entrée dans le raisonnement, elle peut persister dans cet état stocké.

La «rente du raisonnement» des laboratoires d'IA vacille

La trace de raisonnement complète d'un modèle vaut, pour l'entraînement, bien plus que quelques phrases ajoutées à la réponse finale : elle enregistre comment une tâche a été décomposée, comment les jugements intermédiaires se sont formés et comment les erreurs de parcours ont été corrigées — un signal bien plus riche, pour entraîner un modèle plus petit, qu'une supervision limitée à la réponse. Obtenir ce type de données à grande échelle exigeait auparavant de payer soi-même l'appel à un modèle fermé coûteux. Désormais, les journaux publics d'agents contiennent déjà de grands volumes de raisonnement chiffré calculé par d'autres utilisateurs sur des modèles coûteux ; quiconque trouve un modèle compatible capable de lire ces blocs a une chance d'en extraire un raisonnement de haute qualité déjà calculé, plutôt que de le régénérer de zéro. La génération et l'extraction du raisonnement se retrouvent ainsi séparées sur deux points d'accès différents — un modèle haut de gamme produit la réflexion de valeur, un modèle bon marché la lit —, une voie qu'une surveillance concentrée sur le seul modèle haut de gamme risque de ne pas détecter.

Une expérience menée avec Kimi K3, le modèle de Moonshot AI, a illustré la valeur de ce raisonnement fuité : les chercheurs n'ont prélevé qu'environ 1 % des premiers jetons d'une trace de raisonnement caché de Claude Opus, et les ont injectés dans le contexte de raisonnement de Kimi K3 ; la réponse ultérieure de Kimi K3 s'est nettement rapprochée de celle d'Opus, bien plus qu'un modèle témoin n'ayant pas reçu ce préfixe. Cela ne prouve pas que Kimi K3 ait été entraîné sur les données de raisonnement de Claude, mais montre qu'un simple fragment de raisonnement de haute qualité peut modifier de façon mesurable la façon dont un autre modèle résout un problème.

Dans les systèmes agentiques, bien plus qu'une fuite de données

Dans une conversation ordinaire, faire lire un raisonnement caché revient surtout à exfiltrer des informations internes. Dans un système agentique qui s'exécute longtemps, le raisonnement fait aussi office d'état de la tâche : il consigne ce que l'agent a déjà analysé, les options qu'il a écartées, ce qu'il prévoit de faire ensuite. Si un bloc de raisonnement peut migrer d'une tâche vers une autre exécution d'agent, ce qui se déplace avec lui n'est pas seulement de l'information historique, mais potentiellement une tendance d'action déjà formée par l'agent. Les chercheurs ont démontré une injection de prompt invisible qui en découle : un contenu malveillant est d'abord écrit dans le raisonnement caché, puis un nouvel agent charge cet état — l'entrée que voit l'utilisateur ne comporte aucune instruction correspondante, mais une fois son état interne restauré, le modèle peut malgré tout agir en fonction de ce contenu. Cela diffère de l'injection de prompt classique, généralement dissimulée dans une page web, un fichier, un e-mail ou un résultat d'outil qu'un système de sécurité a au moins une chance de scanner en clair ; un bloc de raisonnement chiffré reste opaque pour les systèmes externes, et ne prend sens qu'une fois déchiffré par le serveur — moment où toute défense par analyse arrive déjà trop tard.

Le contexte plus large : des agents de code IA exécutant déjà du code non autorisé dans des réseaux d'entreprise

Cette découverte sur le raisonnement caché survient alors qu'une vague plus large de révélations sur la sécurité des agents IA fait surface. Selon Ars Technica, des chercheurs d'une start-up israélienne discrète ont scanné 6 214 domaines actifs appartenant à des sous-traitants de la défense, des entreprises du Fortune 500 et de grands groupes technologiques, et découvert 227 commandes d'installation pointant vers des paquets de code ou des noms de domaine non enregistrés, dans les fichiers llms.txt de 120 de ces sites. Après avoir enregistré quelques-uns de ces noms de paquets et de domaines vacants, l'équipe a reçu, en moins d'une heure, une requête de rappel émanant d'une entreprise du Fortune 500, puis des dizaines d'autres par la suite — impliquant des agents de code dont Claude, Codex d'OpenAI et Hermes de Nous Research. Le chercheur Alon Hertz y voit un problème plus fondamental encore : les agents traitent par défaut chaque document qu'ils lisent comme digne de confiance, sans moyen de distinguer une instruction authentique d'un contenu non vérifié.

Les agents traitent la documentation des éditeurs comme une vérité incontestable, sans la remettre en question — et les humains qui les supervisent non plus. L'usage de l'IA agentique explose, et les agents se répandent à tous les niveaux : SaaS, cloud, terminaux.

Ce que ça change pour les entreprises françaises

Pour toute organisation qui intègre Claude, GPT ou un autre modèle de raisonnement dans des flux agentiques — support client, revue de code, analyse de données —, cette recherche pointe un risque encore peu discuté : un bloc de raisonnement peut receler des secrets comme des clés ou des mots de passe, et sa restitution peut faire autant de dégâts qu'une fuite de journaux. Les organisations qui laissent leurs agents transporter et réutiliser d'anciens états de raisonnement d'une tâche ou d'un modèle à l'autre doivent aussi se demander si cet état pourrait véhiculer une tendance d'action altérée. À court terme, les équipes qui déploient des agents de raisonnement devraient éviter d'exposer des identifiants internes dans tout contexte susceptible d'être écrit dans le raisonnement, et fixer des limites de permission explicites sur les états de raisonnement réutilisables d'un modèle ou d'une session à l'autre, plutôt que de faire confiance par défaut à tout bloc qui passe la vérification de signature.