LLM-Attacker compare les attaques sur les split-LLM : les gradients font grimper la fuite à 37,77%

Des chercheurs ont présenté LLM-Attacker, un framework de red teaming unifié pour évaluer la confidentialité des modèles de langage split et distribués. Le chiffre clé vient d'une expérience de contrôle sur GPT-2 : dès que l'attaquant reçoit les gradients que le serveur renvoie pendant l'entraînement, la part de tokens reconstruits passe de 94,20% à 97,38%. La reconstruction exacte de documents entiers bondit de 13,71% à 37,77%, soit près du triple.

Pourquoi les résultats des attaques sur les split-LLM ne sont pas comparables

Dans un schéma split, le texte reste sur le client et seules les représentations intermédiaires, c'est-à-dire les activations d'une des couches, partent vers le serveur. L'idée est séduisante : le serveur exécute la partie lourde du modèle, tandis que les données brutes de l'utilisateur ne quittent pas l'appareil. Mais ces représentations permettent de reconstruire le texte, et les attaques de ce type ne manquent déjà plus.

Le problème, c'est que ces travaux se comparent mal entre eux. Un attaquant voit certains messages, un autre connaît les poids du modèle, un troisième non. Les jeux de données diffèrent, tout comme les métriques de reconstruction. Quand un article affirme que « notre défense réduit la fuite », on ne sait pas contre quel attaquant, sur quelles données ni avec quelle métrique cela a été mesuré.

Ce que le framework enregistre et vérifie

LLM-Attacker transforme ces hypothèses implicites en enregistrements explicites. Le framework consigne le modèle de menace, les messages accessibles à l'attaquant, les poids connus, le corpus et la méthode de calcul. Les attaques compatibles réutilisent les messages déjà enregistrés, et leurs prédictions sont sauvegardées puis évaluées indépendamment de la personne qui a lancé l'attaque.

Une règle stricte s'applique aux défenses : on ne peut revendiquer un succès qu'en présence d'une référence appariée sans défense. Sans point de comparaison, « c'est mieux » ne veut rien dire. Par ailleurs, le rapport final liste séparément les attaques qui n'ont pas été lancées. L'absence de fuite dans les scénarios testés ne passe plus pour une absence de fuite tout court.

Les auteurs distinguent aussi deux types d'affirmations : la vérification de la justesse de l'implémentation et l'efficacité mesurée de l'attaque. La première indique que le code fait ce qui était prévu, la seconde montre à quel point l'attaque est dangereuse.

L'expérience sur GPT-2 : ce que change l'accès aux gradients

L'expérience de contrôle visait à vérifier comment l'évaluation réagit à une modification des accès de l'attaquant. Résultats :

• reconstruction des tokens : 94,20% → 97,38% avec l'ajout des gradients ;
• reconstruction exacte du document : 13,71% → 37,77% ;
• le seuil d'effet de deux points de pourcentage a été fixé avant le début des tests ;
• l'intervalle de confiance à 95% du gain sur les tokens se situe entièrement au-dessus de ce seuil.

Cette expérience est distincte du travail associé. Au sein de LLM-Attacker, elle sert de test de sensibilité : si l'on élargit les droits de l'attaquant, la mesure doit le détecter, et c'est le cas. Détail notable : le gain sur les tokens paraît modeste (environ trois points), alors qu'il est énorme pour les documents entiers. La métrique moyenne masque la queue de distribution, où se concentre le vrai risque d'exposition.

Des études complémentaires menées dans le cadre du framework évaluent l'influence du choix du corpus et des défenses fondées sur la compression sur la reconstruction. Une attaque publiée, une fois adaptée, est comparée à son implémentation de référence, et le code de mesure lui-même est testé séparément.

Comment mettre en place cette vérification chez soi

Pour les équipes qui construisent ou achètent de l'inférence split et de l'entraînement distribué, la conclusion est pratique. Toute déclaration sur la confidentialité doit nommer l'attaquant, le jeu de données et la règle de calcul, présenter les exécutions de contrôle et lister ce qui reste non vérifié.

Lors de l'évaluation, il convient de lancer les attaques dans au moins deux modes d'accès : avec les seuls messages directs, puis avec les gradients, s'ils sont renvoyés au serveur. Il faut regarder non seulement la part de tokens reconstruits, mais aussi la reconstruction exacte des documents, car c'est cette métrique qui a le plus progressé. Toute défense, qu'il s'agisse de compression ou de bruit, doit être comparée à la version sans défense sur les mêmes données. Enfin, au moment de choisir un fournisseur, il est utile de lui demander un rapport sous cette forme : sans liste des attaques non testées, il ne montre qu'une partie du tableau.