Un article de recherche montre que les blocs de raisonnement chiffrés émis par plusieurs grands fournisseurs sont interchangeables entre sessions, entre utilisateurs et entre modèles d'un même écosystème. Conséquence : un attaquant peut injecter le raisonnement chiffré d'un modèle puissant dans un modèle plus faible de la même famille et lui faire produire le contenu en clair, sans avoir à contourner les protections du modèle puissant. Les auteurs le démontrent chez trois grands fournisseurs.
Nous avons couvert plusieurs failles de sécurité cette année. Celle-ci est d'une nature différente, et particulièrement élégante dans son mécanisme.
Le contexte : pourquoi le raisonnement est chiffré
Les modèles récents produisent un brouillon interne avant de répondre, comme nous l'avons expliqué dans notre article sur les modèles de raisonnement. Ce brouillon contient souvent des éléments que les fournisseurs préfèrent ne pas exposer : des détails sur la méthode du modèle, parfois des fragments d'information sensibles.
Plusieurs fournisseurs ont donc choisi de transmettre ces blocs sous forme chiffrée. L'utilisateur reçoit un bloc opaque, que le système peut réutiliser dans la suite de la conversation sans que le contenu soit lisible.
La faille
Le problème découvert est que ces blocs ne sont pas liés à la session, ni à l'utilisateur, ni au modèle précis qui les a produits. Ils sont valides dans tout l'écosystème du fournisseur.
L'attaque en découle directement : on récupère un bloc chiffré produit par un modèle puissant, on le fournit comme contexte à un modèle plus faible de la même famille, et on demande à ce dernier de le restituer. Le petit modèle, qui n'a pas les mêmes garde-fous, s'exécute.
L'astuce est qu'on n'attaque jamais le modèle protégé. On utilise un membre moins gardé de sa propre famille comme traducteur. C'est une variante du principe que nous décrivions à propos de jailbreaks, mais qui contourne entièrement la question du contournement.
Les auteurs indiquent avoir décodé plus de trois cent mille blocs de raisonnement collectés dans des dépôts publics, et en avoir extrait plusieurs centaines d'éléments de données personnelles ainsi que des identifiants d'accès. Ce dernier point est le plus préoccupant : des développeurs ont publié, sans le savoir, des blocs contenant des secrets, en pensant qu'ils étaient illisibles. Le chiffrement a créé une fausse impression de sûreté qui a conduit à publier ce qu'on n'aurait jamais publié en clair.
La seconde attaque, plus insidieuse
Les auteurs décrivent aussi une voie d'injection invisible. Puisque ces blocs sont acceptés comme contexte légitime, on peut y placer des instructions qui persistent dans une exécution agentique sans être visibles.
C'est une variante de l'agentjacking, avec une difficulté supplémentaire : le vecteur est un objet que le système considère comme sien, chiffré, donc a priori digne de confiance.
La leçon générale
Cette découverte illustre un principe classique en sécurité : le chiffrement ne protège que si la clé est correctement liée à un périmètre. Un contenu chiffré déchiffrable par n'importe quel membre de l'écosystème n'est pas protégé, il est simplement illisible pour celui qui n'a pas la bonne porte.
Elle rejoint aussi ce que nous écrivions sur l'opacité des modèles : rendre un raisonnement inaccessible à l'utilisateur pour des raisons de propriété industrielle crée un objet dont personne ne peut vérifier le contenu, y compris celui qui le transporte.
Ce qu'il faut faire
Pour un développeur, deux précautions immédiates. Ne publiez jamais de blocs de raisonnement chiffrés, dans un dépôt, un journal ou un rapport de bug : traitez-les comme des données sensibles, pas comme des jetons opaques. Et ne considérez pas un bloc chiffré reçu comme une source fiable dans une chaîne agentique.
Pour tout le monde, cette affaire rappelle une chose utile : les protections les plus solides tombent rarement par la force. Elles tombent parce que quelqu'un trouve une porte latérale que personne n'avait pensé à fermer.