Faille majeure : les « pensées » des IA d’OpenAI, Anthropic et Google peuvent être volées

Une vulnérabilité architecturale critique touche les trois géants de l’IA générative. Des chercheurs viennent de démontrer qu’il est possible d’extraire en clair les traces de raisonnement – normalement chiffrées – de modèles comme GPT-4, Claude Opus ou Gemini, sans attaquer directement ces systèmes. La technique exploite un mécanisme de « rejeu » entre modèles d’une même famille, révélant un conflit structurel entre performance et sécurité dans l’architecture des LLM commerciaux.

Une attaque en trois temps qui contourne le chiffrement

Le 11 août 2026, une équipe de recherche regroupant des experts du MATS Research, de l’ELLIS Institute Tübingen, du Max Planck Institute for Intelligent Systems et de Snyk a publié un paper explosif sur AlphaXiv (référence 2608.09867). Leur découverte, baptisée « Stealing Reasoning Traces from Proprietary LLM APIs » et illustrée par le domaine de démonstration stolen-thoughts.com, révèle une faille de conception touchant simultanément OpenAI, Anthropic et Google.

Selon Simon Willison, expert reconnu en IA qui a relayé la découverte sur son blog, le mécanisme d’attaque repose sur une chaîne en trois étapes. D’abord, l’attaquant récupère un bloc de raisonnement chiffré (encrypted chain-of-thought) généré par un modèle avancé – ce que l’industrie appelle un « modèle frontier » comme GPT-4 ou Claude Opus 4.8. Ces blocs sont normalement retournés aux clients par les API pour optimiser les performances et permettre la continuité des conversations.

Ensuite, et c’est là que réside la vulnérabilité, ces blocs chiffrés s’avèrent compatibles et rejouables entre différentes sessions, utilisateurs, et même entre modèles d’une même famille. L’attaquant peut donc injecter la trace capturée dans un modèle « sibling » – une version moins puissante de la même famille, comme GPT-3.5 face à GPT-4. Enfin, en appliquant des techniques de jailbreaking sur ce modèle plus faible et moins sécurisé, il force la révélation en clair du raisonnement complet du modèle fort.

« Anthropic, OpenAI, and Google return encrypted chain-of-thought blocks to clients that can be replayed across sessions, users, and models. We take a trace produced by a frontier model, replay it into a weaker sibling, jailbreak the weaker model, and recover the stronger model’s hidden reasoning in plaintext », résume le paper.

62 clés API et centaines de secrets exposés dans la nature

Au-delà de la démonstration de principe, les chercheurs ont mené une analyse à grande échelle sur 6 708 trajectoires d’agents publiques récupérées sur GitHub et Hugging Face. Le bilan est édifiant : 62 clés API actives, 33 mots de passe, 24 tokens d’accès et plusieurs centaines d’autres secrets ont été extraits de blocs chiffrés que leurs propriétaires pensaient protégés.

Selon le rapport de l’AI Governance Institute, cette découverte soulève deux vulnérabilités distinctes mais liées. La première, l’extraction de raisonnement via rejeu, permet de récupérer la propriété intellectuelle des modèles – leur manière de « penser » – sans déclencher les protections anti-distillation. La seconde, la fuite d’informations personnellement identifiables (PII) et de credentials dans les logs publics d’agents, transforme chaque session partagée en risque potentiel de sécurité.

L’analyse révèle que l’attaque fonctionne sur claude-opus-4-8, les modèles GPT-4 et GPT-5.6 Sol d’OpenAI, ainsi que sur les modèles Gemini de Google. Un exemple particulièrement parlant concerne GPT-5.6 Sol : les chercheurs ont réussi à décoder des traces de raisonnement qui ressemblent à des notes compressées, révélant le processus de réflexion interne du modèle sur un problème de géométrie impliquant un pentagone.

Un défaut structurel, pas un simple bug

Cette vulnérabilité n’est pas un accident de parcours corrigeable par un patch. Elle révèle un conflit fondamental dans l’architecture des LLM commerciaux entre optimisation des coûts et exigences de sécurité. Pour réduire la latence et les dépenses de calcul, les fournisseurs ont mis en place des systèmes de cache et de réutilisation des traces de raisonnement – ce que l’industrie appelle le « chain-of-thought ».

Le chain-of-thought, technique de prompting qui décompose un problème en étapes logiques intermédiaires, est devenu central dans les modèles de raisonnement avancés. Plutôt que de recalculer à chaque fois, les systèmes stockent et rejouent ces traces. Mais en retournant ces blocs au client – même chiffrés – les fournisseurs créent nécessairement une surface d’attaque.

Comme le souligne un analyste de Cybersecurity News, « cette faille architecturale montre que les blocs de raisonnement chiffrés retournés par les API peuvent être compatibles à travers sessions, utilisateurs et modèles au sein d’un même écosystème fournisseur ». Le problème se situe donc au niveau de la conception même du service, pas dans son implémentation.

Plus troublant encore, l’attaque exploite l’écart de sécurité entre modèles d’une même famille. Les versions « lite » ou « mini », proposées à prix réduit, sont par nature moins robustes aux tentatives de jailbreaking. Mais si elles peuvent décoder les traces des modèles premium, elles deviennent le maillon faible de toute la chaîne. Cela force les fournisseurs à sécuriser tous leurs modèles au niveau du plus fort, annulant l’intérêt économique des versions allégées.

Implications pour les entreprises et les utilisateurs

Pour les organisations qui ont confié des analyses stratégiques, des données clients ou de la propriété intellectuelle aux API d’OpenAI, Anthropic ou Google, cette découverte soulève des questions urgentes. Selon les experts en gouvernance IA, près de 60 % des entreprises utilisant des LLM en production ont déjà détecté des tentatives d’exfiltration de données, souvent involontaires.

Les raisonnements confidentiels traités par ces systèmes – contrats, stratégies commerciales, dossiers médicaux analysés, code propriétaire commenté – pourraient théoriquement être exposés rétroactivement si les traces ont été conservées. La question de la durée de rétention de ces blocs chiffrés reste ouverte : sont-ils conservés indéfiniment ? Qui y a accès côté fournisseur ?

Les implications juridiques sont également considérables. Avec l’entrée en vigueur progressive de l’AI Act européen et le durcissement des réglementations sur la protection des données, cette vulnérabilité pourrait devenir un cas d’école. Les premiers litiges basés sur cette faille définiront les standards de responsabilité pour toute l’industrie de l’IA-as-a-Service.

Du côté des investisseurs, la découverte pourrait redistribuer les cartes. Les solutions open-source comme Llama de Meta ou Mistral, qui n’ont pas ce problème architectural puisque tout le raisonnement reste local, pourraient bénéficier d’un regain d’intérêt. À l’inverse, OpenAI, Anthropic et Google font face à un risque réputationnel majeur et à des coûts de remédiation potentiellement élevés nécessitant une refonte complète de leurs systèmes de cache.

Réactions et perspectives

À l’heure de la publication de cette analyse, ni OpenAI, ni Anthropic, ni Google n’ont communiqué officiellement sur la vulnérabilité. On ignore si les chercheurs ont respecté un processus de divulgation responsable en informant les fournisseurs avant la publication, ou s’ils ont choisi une approche plus confrontationnelle.

La création d’un domaine « vanity » (stolen-thoughts.com) et le choix d’AlphaXiv plutôt qu’ArXiv pour la publication suggèrent une stratégie de communication agressive, possiblement liée à des chercheurs en « offensive AI security » ou à un agenda de sensibilisation publique. Cette approche marque peut-être un tournant dans les normes de divulgation en IA, vers plus de transparence et de pression publique.

À court terme (1-3 mois), on peut s’attendre à la publication du paper complet avec détails techniques, suivie de réponses officielles des fournisseurs – probablement en minimisant le risque – et de premiers correctifs partiels. Des chercheurs indépendants tenteront de reproduire l’attaque, et une couverture médiatique grand public pourrait émerger si un cas d’exploitation réelle est documenté.

À moyen terme (6-12 mois), plusieurs scénarios se dessinent. Le plus optimiste verrait les fournisseurs abandonner le système de traces rejouables et refondre leur architecture de cache, au prix de performances réduites et de coûts accrus. Une alternative consisterait en la mise en place de mécanismes cryptographiques plus robustes – chiffrement par session, attestation matérielle via Trusted Execution Environments – rendant l’attaque impraticable.

Un scénario plus disruptif verrait une accélération de l’adoption de modèles open-source par les entreprises sensibles à la sécurité, affaiblissant le modèle économique des API propriétaires. Enfin, une intervention des régulateurs (CNIL, FTC, autorités de l’AI Act) pourrait imposer des standards de sécurité contraignants pour les fournisseurs d’IA-as-a-Service.

Questions ouvertes et zones d’ombre

Plusieurs incertitudes majeures subsistent. Cette vulnérabilité a-t-elle déjà été exploitée avant sa divulgation publique ? Par qui, et à quelle échelle ? Quelle quantité de données historiques est potentiellement exposée, et les traces sont-elles conservées indéfiniment par les fournisseurs ?

D’autres acteurs de l’IA-as-a-Service comme Cohere, AI21 Labs ou Mistral AI sont-ils également vulnérables ? Le mécanisme de rejeu est-il une fonctionnalité documentée des API ou une découverte accidentelle des chercheurs ? Existe-t-il des moyens techniques de détecter si vos traces ont été rejouées ou volées ?

Enfin, comment cette faille interagit-elle avec les nouvelles fonctionnalités de « mémoire » et de personnalisation déployées par OpenAI et Anthropic ? Ces systèmes, qui conservent des informations entre sessions pour améliorer l’expérience utilisateur, pourraient-ils amplifier le risque d’exposition ?

Une chose est certaine : cette découverte force l’industrie à repenser l’équilibre entre performance, coût et sécurité dans l’architecture des LLM commerciaux. Le modèle actuel, basé sur l’optimisation via réutilisation de raisonnements, pourrait s’avérer intrinsèquement incompatible avec les exigences de sécurité enterprise. C’est un problème structurel, pas un simple bug – et sa résolution pourrait redéfinir l’économie même de l’IA-as-a-Service.