Des chercheurs ont démontré que les traces de raisonnement chiffrées — de petits paquets qu'un fournisseur envoie à l'appareil d'un utilisateur pour qu'une conversation puisse passer d'un modèle à un autre — peuvent être déchiffrées par un modèle plus faible du même service, exposant des centaines d'identifiants et de détails privés. Cette découverte, détaillée dans l'article Stealing Reasoning Traces from Proprietary LLM APIs, menace une fonctionnalité de commodité sur laquelle Anthropic, OpenAI et Google comptent pour assurer la fluidité des conversations d'IA.

Pourquoi les blocs chiffrés existent

Lorsque vous communiquez avec un grand modèle de langage (LLM), le service construit une « trace de raisonnement » : la chaîne de prompts internes, d'appels d'outils et d'étapes de réflexion (chain-of-thought) qui ont mené à la réponse. Pour vous permettre de passer d'un modèle plus large à un modèle moins coûteux sans perdre cette chaîne, les fournisseurs chiffrent la trace, l'envoient à votre appareil et s'attendent à ce que vous la renvoyiez avec la requête suivante. Le chiffrement est destiné à préserver la confidentialité de la trace tout en permettant une continuité inter-session et inter-modèle.

Comment l'attaque fonctionne

Les chercheurs ont démontré un exploit en trois étapes qui ne nécessite aucune brèche dans le modèle puissant lui-même :

  1. Capturer un bloc de raisonnement chiffré généré par un modèle puissant lors d'une conversation normale.
  2. Alimenter ce bloc dans un modèle plus faible du même fournisseur, en lui demandant de « lire » le bloc.
  3. Comme le modèle plus faible partage les mêmes clés de déchiffrement, il produit le contenu déchiffré en texte clair.

Le modèle plus faible agit comme un oracle de déchiffrement. Les attaquants n'ont jamais touché aux composants internes du modèle puissant ; ils ont simplement utilisé l'API du fournisseur contre lui-même.

Ce que les chercheurs ont récupéré

  • 182 identifiants – clés API, jetons (tokens) et autres secrets intégrés dans la trace.
  • 367 informations privées – noms, e-mails, adresses que les utilisateurs avaient fournis pendant la discussion.
  • Charges utiles d'injection de prompt – instructions malveillantes cachées dans le bloc chiffré qui pourraient être exécutées ultérieurement lors de la relecture de la trace.
  • Contournements des filtres de sécurité – la trace déchiffrée a révélé des étapes qui auraient été bloquées si elles avaient été examinées en texte clair, permettant à du contenu dangereux de passer.

L'article souligne que la faiblesse ne provient pas d'une faille de l'algorithme cryptographique ; le chiffrement en lui-même est robuste. La brèche provient du choix de conception consistant à permettre à n'importe quel modèle de la flotte du fournisseur de déchiffrer le bloc au nom de l'expérience utilisateur.

Le compromis au cœur du problème

Les fournisseurs ont intégré cette capacité de « changement de modèle » dans leurs API car les développeurs et les utilisateurs finaux accordent une grande importance à la continuité. Si le chiffrement était lié à une seule instance ou session de modèle, la transition fluide serait rompue, obligeant les développeurs à reconstruire eux-mêmes la gestion de l'état. L'article soutient que la sécurité a été délibérément sacrifiée au profit de la flexibilité.

Ce que les développeurs doivent faire maintenant

  • Traitez les traces chiffrées comme du texte en clair. Partez du principe que tout journal (log), cache ou système de surveillance qui les stocke pourrait être lu par un attaquant.
  • Évitez de soumettre des traces dans des dépôts publics. Même un seul bloc égaré peut exposer des dizaines de secrets.
  • Prévoyez des contrôles plus stricts. Les fournisseurs pourraient renforcer la sécurité, ce qui pourrait modifier la manière dont les agents multi-modèles sont construits.
  • Passez à des transferts d'état explicites. Au lieu de vous appuyer sur un raisonnement caché, concevez des agents capables de produire des données structur