🤖 machine learning

Verifying LLM Inference to Detect Model Weight Exfiltration

Cet article propose un cadre de vérification formel et pratique pour détecter et prévenir l'exfiltration de poids de modèles d'IA via des techniques de stéganographie lors de l'inférence, en exploitant des sources de non-déterminisme pour contraindre les attaquants avec un coût minimal.

Auteurs originaux : Roy Rinberg, Adam Karvonen, Alexander Hoover, Daniel Reuter, Keri Warr

Publié 2026-03-16

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Roy Rinberg, Adam Karvonen, Alexander Hoover, Daniel Reuter, Keri Warr

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous possédez une recette de cuisine secrète, très précieuse (c'est votre modèle d'IA). Vous louez votre cuisine à des clients pour qu'ils fassent cuire des plats (c'est le serveur d'inférence). Le problème, c'est que certains clients malveillants pourraient essayer de voler votre recette en cachant des pages de celle-ci à l'intérieur des plats qu'ils vous demandent de préparer.

C'est exactement ce que traite ce papier de recherche : comment empêcher quelqu'un de voler le "cerveau" d'une intelligence artificielle en le cachant dans ses réponses normales.

Voici une explication simple, avec des analogies, de la solution proposée par les auteurs.

1. Le Problème : Le Voleur qui Chuchote dans le Vent

Imaginez un voleur qui a réussi à se faufiler dans votre cuisine. Il ne peut pas sortir avec un sac rempli de vos livres de recettes (les poids du modèle), car la police (les pare-feu de sécurité) les verrait immédiatement.

Alors, il utilise une technique appelée stéganographie. C'est comme écrire un message secret sur les étiquettes des épices que vous utilisez, ou changer subtilement l'ordre dans lequel il met les œufs dans l'omelette.

Le piège : Les réponses de l'IA sont naturellement un peu imprévisibles (comme un cuisinier qui hésite entre un peu plus ou un peu moins de sel). Le voleur exploite cette petite incertitude pour cacher des bits d'information (des 0 et des 1) dans les mots que l'IA génère.
Le résultat : Il envoie des milliers de réponses inoffensives qui, une fois assemblées, reconstituent votre recette secrète.

2. La Solution : Le "Double-Check" Magique

Les auteurs proposent de construire une cuisine de contrôle (un serveur de vérification) séparée de la cuisine principale. Voici comment ça marche, étape par étape :

A. La "Graine" de la Réalité (Le Seed)

Quand vous demandez à l'IA de cuisiner, vous lui donnez une instruction précise et une "graine" (un nombre aléatoire secret). Normalement, avec la même graine, la même recette et le même cuisinier, le plat devrait être identique à chaque fois.

B. Le Détecteur de "Faux"

Le serveur de vérification (le garde du corps) reçoit une copie de la commande et de la "graine". Il recuisine le plat lui-même, dans son propre environnement sécurisé.

Si le cuisinier est honnête : Le plat qu'il a servi et celui que le garde a cuisiné seront presque identiques. Il y aura de minuscules différences dues à la chaleur du four ou à la précision du couteau (ce qu'on appelle le non-déterminisme valide). C'est normal.
Si le cuisinier est un voleur : Pour cacher son message secret, il a dû modifier légèrement le plat (changer un mot, un ordre). Le garde va comparer les deux plats et dire : "Attends, ce mot-là n'est pas celui que j'aurais choisi avec cette graine ! C'est suspect."

C. Le Score de Suspicion

Le système attribue un score à chaque mot :

Sûr : Le mot correspond parfaitement à ce qu'on attendait.
Suspect : Le mot est possible, mais un peu étrange.
Dangereux : Le mot est très improbable, comme si le cuisinier avait délibérément mis du poivre à la place du sel.

3. Pourquoi c'est si efficace ? (L'Analogie du Labyrinthe)

Imaginez que le voleur essaie de sortir de votre cuisine en passant par un labyrinthe.

Sans surveillance, il peut courir vite et sortir en 1 jour.
Avec ce système, le garde lui dit : "Si tu veux sortir sans être attrapé, tu dois prendre des chemins très spécifiques et très lents."

Le papier montre que pour voler tout le modèle (par exemple 1 To de données), le voleur serait obligé de prendre des chemins si lents et si prudents qu'il lui faudrait plus de 200 jours au lieu d'un seul jour.

Le gain : Le voleur doit choisir entre être attrapé très vite ou voler si lentement que le modèle sera déjà obsolète avant qu'il n'ait fini.

4. Les Avantages Pratiques

Pas de ralentissement pour les clients : La vérification ne se fait pas sur chaque mot en temps réel (ce qui serait trop lent). On vérifie un échantillon aléatoire de messages, comme un douanier qui fouille 1 valise sur 100. Si le voleur sait qu'il peut être fouillé à tout moment, il n'osera pas essayer.
Double usage : Ce système sert aussi à repérer les bugs. Si l'IA commence à dire des bêtises à cause d'un bug informatique, le garde le remarquera aussi !

En Résumé

Ce papier propose un système de sécurité qui ne bloque pas les voleurs physiquement, mais qui les force à parler trop lentement pour réussir leur coup.

C'est comme si vous aviez un détective qui écoute chaque conversation de votre cuisinier. Si le cuisinier essaie de chuchoter un secret, le détective entend un mot qui ne correspond pas à la conversation normale et sonne l'alarme. Résultat : le voleur préfère abandonner son vol, car il sait qu'il mettra des mois à réussir là où il espérait réussir en quelques heures.

C'est une protection puissante, peu coûteuse à mettre en place, et qui rend le vol de modèles d'IA beaucoup plus difficile et moins rentable.

1. Le Problème : L'Exfiltration par Stéganographie

À mesure que les modèles d'intelligence artificielle (LLM) deviennent des actifs commerciaux critiques, le risque de vol de leurs poids (paramètres) augmente. Les attaquants peuvent compromettre un serveur d'inférence pour extraire ces poids.

Le vecteur d'attaque : Au lieu de télécharger directement les fichiers (ce qui est souvent bloqué), un attaquant peut utiliser la stéganographie. Il consiste à cacher des fragments des poids du modèle à l'intérieur des réponses textuelles normales générées par le modèle.
Le défi technique : Les LLM sont intrinsèquement non déterministes. Même avec une graine aléatoire (seed) fixe, des variations mineures dues à la précision flottante, à l'ordonnancement des noyaux GPU ou à la charge du serveur peuvent entraîner des sorties différentes. Un attaquant peut exploiter cette "non-déterminisme valide" pour encoder des informations sans que cela ne semble anormal, rendant la détection difficile.
L'objectif : Développer un système capable de vérifier si une réponse générée provient bien du modèle légitime avec son comportement attendu, et de détecter toute déviation utilisée pour exfiltrer des données.

2. Méthodologie et Cadre Théorique

Les auteurs proposent un cadre de vérification basé sur la comparaison entre le comportement attendu du modèle et les réponses observées, en tenant compte de la variabilité naturelle.

A. Formalisation du Jeu de Sécurité

Le problème est modélisé comme un jeu de sécurité où un adversaire tente d'extraire $n$ bits d'information (les poids) via des réponses de longueur $\ell$ .

Hypothèses de confiance : Le serveur de vérification est supposé honnête et isolé. L'attaquant contrôle le serveur d'inférence mais ne peut pas utiliser de canaux latéraux (timing, cache) ni modifier les logs.
Distribution Postérieure à Graine Fixe : Les auteurs définissent une distribution de probabilité $P_{seed}(t | \sigma)$ qui représente la probabilité qu'un token $t$ soit généré avec une graine $\sigma$ , en intégrant la variabilité due aux erreurs numériques (non-déterminisme valide).

B. Mécanisme de Vérification

Le système fonctionne en trois étapes :

Journalisation (Logging) : Le serveur d'inférence enregistre toutes les entrées, sorties et les graines aléatoires utilisées.
Vérification Isolé : Un serveur de vérification (isolé et sécurisé) rejoue un échantillon aléatoire de ces inférences avec le modèle de référence.
Analyse de Déviation : Le vérificateur calcule la probabilité que le token observé ait été généré honnêtement.

C. Les Estimateurs de Probabilité (FSSL)

Pour quantifier la probabilité d'un token sous une graine fixe, deux méthodes sont proposées :

Token-DiFR (FSSL-GM) : Pour les modèles utilisant l'astuce Gumbel-Max. Le vérificateur régénère le bruit Gumbel à partir de la graine et calcule la probabilité que le token observé ait été sélectionné malgré le bruit et les variations de logits.
Token-IPT-DiFR (FSSL-IPT) : Pour les modèles utilisant la Transformée Inverse de Probabilité (IPT). Le vérificateur intègre une densité gaussienne sur l'intervalle de probabilité du token observé pour estimer la vraisemblance.

D. Classification à Trois Niveaux

Pour améliorer la précision, le système classe les tokens en trois catégories :

Sûr (Safe) : Le token a une probabilité FSSL élevée.
Suspect (Suspicious) : Le token a une probabilité FSSL faible, mais son rang dans les logits bruts (avant filtrage) est élevé (ex: top 8). Cela limite l'information exfiltrable à $\log_2(R)$ bits.
Dangereux (Dangerous) : Le token a une probabilité faible et un rang faible. Cela déclenche une alerte.

3. Contributions Clés

Formalisation Théorique : Définition rigoureuse de l'exfiltration de poids comme un jeu de sécurité, avec des bornes informationnelles prouvées sur la capacité d'exfiltration d'un adversaire.
Cadre de Vérification Pratique : Introduction de méthodes (Token-DiFR et Token-IPT-DiFR) pour estimer la vraisemblance d'échantillonnage à graine fixe, permettant de distinguer le bruit valide des manipulations malveillantes.
Architecture Découplée : Proposition d'une architecture où le serveur de vérification est séparé du serveur d'inférence. Cela permet de sécuriser le processus sans ralentir le débit de production (l'inférence utilise le "prefill" pour une vérification rapide).
Analyse Économique et Stratégique : Le papier démontre que la détection force l'attaquant à choisir entre être détecté rapidement ou exfiltrer très lentement (sur des mois ou des années), rendant l'attaque économiquement non viable.

4. Résultats Empiriques

Les auteurs ont évalué leur système sur plusieurs modèles open-weight (de 3B à 30B paramètres), notamment Llama-3, Llama-3.2 et Qwen (MoE).

Réduction de l'information exfiltrable : Sur le modèle Qwen3-30B-A3B, le détecteur réduit l'information exfiltrable à < 0,5 % avec un taux de faux positifs (FPR) inférieur à $10^{-2}$ .
Ralentissement de l'attaque : Pour un modèle de 1 To avec un trafic de 1 To/jour, le temps nécessaire pour exfiltrer le modèle passe d'environ 1 jour à plus de 200 jours (un ralentissement de facteur > 200x).
Efficacité du filtrage par rang : L'ajout d'une vérification du rang des logits (Logit Rank) améliore considérablement la courbe de Pareto (sécurité vs utilisabilité), permettant de réduire l'information exfiltrable tout en maintenant un faible taux de faux positifs.
Robustesse : Le système fonctionne bien même avec des contextes longs (jusqu'à 12k tokens) et différents types d'architectures (Dense vs MoE).

5. Signification et Impact

Ce travail établit une fondation solide pour la défense contre le vol de modèles d'IA :

Niveau de Sécurité : Il permet de passer d'un niveau de sécurité "SL3" (résistant aux cybercriminels) à "SL4" (résistant aux opérations standard des institutions cyber-capables), en augmentant le temps et le coût de l'exfiltration.
Double Usage : Le même système de vérification peut détecter non seulement les attaques malveillantes, mais aussi les bugs d'inférence ou les anomalies de distribution, servant ainsi d'outil de débogage et de fiabilité.
Faisabilité : Contrairement aux preuves à divulgation nulle de connaissance (ZKPs) qui sont trop lentes pour la production, cette approche est légère, ne nécessite qu'un échantillonnage aléatoire des requêtes (mécanisme de type "Panopticon") et peut être déployée avec un coût marginal pour les fournisseurs d'inférence.

En conclusion, cette recherche démontre qu'il est possible de protéger les poids des modèles contre l'exfiltration par stéganographie en exploitant mathématiquement les limites de la variabilité naturelle des LLM, offrant ainsi une barrière défensive pratique et théoriquement prouvée.