Une faille d’API récemment divulguée met en lumière un risque de confidentialité dans des interfaces de modèles d’IA. Des chercheurs ont montré qu’un mécanisme conçu pour conserver le raisonnement d’un appel à l’autre pouvait, dans certaines conditions, être réutilisé pour récupérer du contenu interne à partir de journaux de sessions publiés.
Le point central n’est pas de “casser” le chiffrement, mais d’exploiter la manière dont des objets de raisonnement chiffrés peuvent être acceptés et rejoués. Résultat : des informations sensibles, potentiellement incluses dans des blocs opaques, peuvent être reconstruites.
De quoi parle exactement la faille d’API
Le problème concerne la transmission de “raisonnement” entre appels d’API. Selon la recherche, OpenAI, Anthropic et Google utilisent des objets chiffrés pour préserver l’état du raisonnement lorsque l’application gère manuellement l’historique ou lorsqu’elle passe par des mécanismes de compatibilité de session.
Dans ces conditions, un bloc produit dans une session peut être repris dans une autre. Les chercheurs expliquent que le mécanisme repose sur l’acceptation de blocs “opaques” intacts par les interfaces de raisonnement, sans qu’il soit nécessaire d’obtenir une clé de chiffrement.
Pourquoi les logs d’agents deviennent un vecteur
La recherche s’appuie sur l’observation de trajectoires d’agents. Quand des développeurs publient des journaux bruts, y compris des éléments de raisonnement chiffrés, ces traces peuvent devenir réutilisables par des tiers.
Les auteurs indiquent que la récupération ne correspondait pas à un accès arbitraire aux conversations privées. Elle nécessitait notamment :
- la disponibilité d’un bloc de raisonnement chiffré (par exemple présent dans un log d’agent publié),
- et un accès à un modèle compatible au sein du même fournisseur.
Autrement dit, le risque est “borné”, mais il est réel pour quiconque publie des traces contenant ces champs de raisonnement.
Ce que les chercheurs ont réellement récupéré
Les résultats rapportent une analyse de 6 708 trajectoires d’agents publiques. À partir de ces sources, l’équipe estime avoir déchiffré 315 320 blocs de “pensée” au total, puis a procédé à un tri afin d’exclure certaines sources de référence.
Après filtrage, les chercheurs recensent 704 artefacts de confidentialité issus de sessions utilisateurs “réelles”. Parmi eux figurent :
- 62 clés API
- 33 mots de passe
- 24 jetons d’accès
- 7 clés privées
Un point marquant concerne la façon dont ces secrets peuvent rester invisibles dans le texte lisible : certains artefacts ne se retrouvaient que dans le raisonnement caché, pas dans la trace “visible”. Cela signifie qu’un nettoyage du texte affiché ne suffit pas forcément.
Une attaque “portable” entre modèles et sessions
Les chercheurs décrivent aussi une propriété de portabilité. Lors de tests, des objets chiffrés liés au raisonnement se sont révélés réutilisables entre sessions, utilisateurs et même modèles “compatibles” au sein d’une même famille.
Pour reconstruire le contenu, l’équipe s’appuie sur ce qu’elle décrit comme un “décodeur flou”. Concrètement, un modèle plus faible, déclenché avec une consigne de transcription, pouvait produire une version exploitable du raisonnement généré auparavant par un modèle plus puissant.
Exemples de “décodeurs” testés
La recherche cite des combinaisons où un modèle compatible est utilisé pour transcrire des traces associées à un modèle plus fort. L’objectif est de faire “réapparaître” le contenu caché contenu dans les blocs opaques.
Abus possibles : au-delà de l’extraction de secrets
La publication ne se limite pas à l’extraction de données. Les chercheurs décrivent plusieurs voies d’abus, notamment :
- vol de raisonnement pour de la distillation,
- récupération d’informations privées à partir de traces publiées par d’autres utilisateurs,
- exfiltration de contenu potentiellement dangereux camouflé derrière une réponse visible “sûre”,
- insertion de prompt injections via des blocs opaques, sans faire apparaître l’instruction dans le texte lisible.
Les auteurs montrent aussi une preuve de concept d’injection “invisible” : un bloc opaque portant une instruction malveillante peut ensuite être rejoué vers une tâche différente, amenant le modèle à exécuter une action dictée par l’attaquant, sans que l’instruction apparaisse dans les champs visibles.
Le chiffrement n’a pas été “cassé”
Contrairement à l’idée d’une compromission par cassage cryptographique, la recherche précise que le chiffrement des objets de raisonnement n’a pas été brisé. L’attaque repose plutôt sur le fait que des blocs opaques intacts sont traités et acceptés par l’API.
Autrement dit : il ne s’agit pas d’obtenir la clé. Il s’agit de tirer parti du comportement de compatibilité côté fournisseur et de la réutilisation de blocs dans des contextes où ils ne devraient pas être rejoués.
Ce qui a changé après la divulgation
La recherche indique avoir communiqué les résultats aux fournisseurs concernés, notamment Microsoft et Hugging Face, et affirme que les attaques démontrées ont cessé de fonctionner après des mesures d’atténuation.
Les auteurs précisent aussi que la reproductibilité de l’attaque principale n’est plus assurée “en août 2026” selon leur déclaration.
Cela dit, le dossier public ne mentionne pas de preuve formelle d’un correctif confirmé par chaque fournisseur dans ses documents accessibles. Les chercheurs s’appuient donc sur leur capacité à reproduire le scénario plutôt que sur un engagement explicite visible dans la documentation publiée.
Recommandations pour les développeurs
La publication insiste sur des actions concrètes, surtout pour celles et ceux qui partagent des journaux d’agents. Les recommandations comprennent notamment :
- Retirer les blocs de raisonnement et les champs de raisonnement opaques des traces partagées.
- Éviter de publier des transcriptions brutes des échanges d’API, même si le texte visible a été “sanitisé”.
- Revoir les processus de journalisation afin que les logs ne contiennent pas d’artefacts chiffrés réutilisables.
Cette approche est cohérente avec un constat clé : une trace lisible peut sembler propre, alors que des secrets subsistent ailleurs, dans des structures opaques.
Pourquoi cette faille d’API soulève des questions plus larges
Au-delà du cas de démonstration, la recherche ouvre des points qui restent partiellement sans réponse dans le dossier public. Par exemple :
- Les blocs déjà publiés dans des dépôts antérieurs demeurent-ils décodables avec les règles actuelles ?
- Le niveau d’exposition exacte dépend-il des architectures d’application et de la gestion de l’historique ?
- Quels changements documentés côté fournisseurs ont réellement modifié la compatibilité des “thought” signatures et objets de raisonnement ?
Le document mentionne cependant que les pratiques ont évolué : les fournisseurs décrivent des mécanismes de compatibilité et d’enchaînement des sessions, mais précisent désormais mieux quand et comment les blocs doivent être traités, notamment lors de changements de modèle.
Conclusion
Cette divulgation montre comment une faille d’API peut émerger non pas d’une rupture de chiffrement, mais d’une logique de réutilisation de blocs de raisonnement chiffrés entre appels. En combinant des logs d’agents publiés et un accès à des modèles compatibles, les chercheurs ont pu reconstruire des contenus internes et extraire des artefacts sensibles, parfois absents du texte visible.
Pour les équipes qui développent ou publient des traces, le message est clair : la sécurité ne se limite pas à nettoyer l’affichage. Il faut aussi retirer les champs opaques et les blocs de raisonnement de tout journal partagé, afin de réduire drastiquement le risque de rejouabilité.
Source: https://thehackernews.com/2026/08/openai-anthropic-google-api-flaw-let.html
