Détecter l'extraction de modèle en observant la fenêtre de trafic, pas les requêtes isolées

De quoi s’agit-il ?

L’extraction de modèle (model stealing) est l’attaque où l’on interroge de façon répétée une API LLM hébergée, où l’on conserve les paires entrée-sortie, puis où l’on entraîne un modèle substitut, moins coûteux, qui approche le comportement, les connaissances métier, voire une partie des paramètres de la cible. Elle figure parmi les menaces majeures pour les services LLM dans la synthèse 2025 sur les attaques et défenses d’extraction de modèle, et les résultats classiques remontent à Tramèr et al. (2016) sur le vol de modèles via API de prédiction.

Le 4 juin 2026, Shuze Liu, Qianwen Guo et Yushun Dong (Santa Clara University, Florida State, FAMU-FSU) ont publié An Embarrassingly Simple Detector for Model Extraction Attacks in LLM API Traffic (arXiv:2606.05725, cs.CR). La contribution n’est pas une nouvelle attaque mais un recadrage défensif : cesser de chercher à signaler les requêtes « suspectes » une à une, et tester plutôt si une fenêtre de trafic récent s’est écartée de votre distribution légitime historique.

Comment ça marche

L’observation centrale : les requêtes d’extraction sont quasi impossibles à repérer individuellement. Les attaquants puisent dans du texte naturel — passages de type Wikipédia, prompts SQuAD, banques de questions métier — si bien que chaque requête ressemble à un utilisateur normal. Ce qui les trahit, c’est la structure dans l’agrégat : un lot de requêtes d’extraction induit un décalage mesurable dans l’espace des embeddings sémantiques, même quand le trafic attaquant ne représente qu’une fraction d’une fenêtre multi-utilisateurs plus large.

Le détecteur est volontairement minimal :

1. Encoder chaque requête entrante avec un encodeur de phrases standard.
2. Constituer une fenêtre glissante des embeddings de trafic récent.
3. Calculer la Maximum Mean Discrepancy (MMD) — une statistique
   à noyau à deux échantillons — entre la fenêtre et un ensemble
   de référence légitime.
4. Alerter si la MMD dépasse un seuil.

Le choix de conception décisif est la calibration. Le seuil est fixé à partir de comparaisons légitime-contre-légitime uniquement — aucune donnée d’attaque étiquetée, aucun générateur de requêtes attaquant. C’est crucial car le défenseur ne dispose presque jamais de l’outillage de l’attaquant ; il n’a que ses propres journaux historiques. Le papier formalise ceci comme un test de distribution sur fenêtre de trafic calibré sur le légitime et l’évalue sur quatorze paires requêtes-attaquant / requêtes-normales couvrant quatre scénarios d’extraction, dont le cas réaliste du trafic mixte où les requêtes attaquantes sont diluées parmi de nombreux utilisateurs légitimes.

Face à PRADA, SEAT, CAP, DATE et une distance de Mahalanobis marginale (toutes adaptées au même protocole embedding + calibration légitime pour une comparaison équitable), le détecteur MMD rapporte, sur trois graines : 0,3 % de taux de faux positifs légitimes, 100,0 % de taux de vrais positifs sur le trafic purement attaquant, 90,5 % de TPR moyen selon les fractions d’attaquant, et 95,1 % d’exactitude équilibrée. Le code est publié sur LabRAI/mmd-llm-mea-detection.

Pourquoi c’est important

La plupart des défenses publiées contre l’extraction sont évaluées au niveau du compte : un utilisateur légitime n’émet que des requêtes propres, un attaquant déroule un workflow d’extraction complet, et le détecteur sépare les deux. La supervision réelle d’une API ne ressemble pas à cela. Le trafic est un flux mêlé de nombreux locataires, et une campagne d’extraction n’en est qu’une mince tranche. Un détecteur qui ne distingue que les comptes purement légitimes des comptes purement attaquants échoue discrètement dès que l’attaquant est l’un des mille appelants simultanés.

Le cadrage par distribution sur fenêtre répond directement à ce problème, et le chiffre de faux positifs mérite qu’on s’y arrête. La supervision de sécurité vit et meurt de la fatigue des analystes : un détecteur qui se déclenche en permanence est désactivé en une semaine. Un taux de faux positifs de 0,3 % avec une calibration sans étiquettes d’attaque rend un contrôle déployable, pas seulement publiable. Le revers, par honnêteté : c’est de la détection de la phase de requêtage, pas de la prévention. Cela vous dit qu’une campagne est probablement en cours ; cela n’empêche pas l’entraînement du substitut sur des données déjà exfiltrées, et un attaquant patient qui étale assez finement ses requêtes dans le temps et entre les comptes peut faire baisser le signal par fenêtre.

Défenses

Ce papier est la technique défensive ; les enseignements pratiques portent donc sur l’adoption :

1. Traitez la supervision de l’extraction comme un problème de distribution, pas d’anomalie par requête. Agrégez sur une fenêtre de trafic et comparez à votre propre référence légitime. Les classifieurs par requête rateront l’extraction car chaque requête est légitime par construction.

2. Calibrez sur le trafic légitime que vous avez déjà. Pas besoin d’échantillons d’attaque ni du générateur de l’attaquant. Fixez le seuil d’alerte à partir de la variation légitime-contre-légitime de vos journaux, ce qui maintient les faux positifs bas et évite le surajustement à un style d’extraction.

3. Encoder, puis tester. Un encodeur de phrases générique plus la MMD constituent une base solide et peu coûteuse. Commencez par là avant les encodeurs spécifiques à la tâche ou les modèles d’anomalie auto-supervisés — ici, le simple test à deux échantillons a battu les bases adaptées.

4. Ajustez la taille de fenêtre et la provenance, pas seulement le seuil. Le trafic mixte dilue le signal ; des fenêtres plus petites par locataire ou par segment restaurent la sensibilité. Combinez avec limitation de débit, quotas par clé et défenses côté sortie (watermarking, perturbation des réponses) pour faire de la détection une couche, pas toute la stratégie.

5. Préparez la réponse, pas seulement l’alerte. Détecter la phase de requêtage gagne du temps pour brider, défier ou révoquer une clé avant qu’un substitut exploitable soit entraîné. Décidez à l’avance ce que déclenche une alerte MMD.

État des lieux

Élément	Référence	Date	Notes
Détecteur MMD d’extraction	arXiv:2606.05725	2026-06-04	Test MMD sur fenêtre calibré sur le légitime
Résultats rapportés	arXiv:2606.05725	2026-06-04	0,3 % FPR, 100 % TPR pur attaquant, 95,1 % exactitude éq.
Code	LabRAI/mmd-llm-mea-detection	2026-06	Publication publique
Contexte de menace	Synthèse extraction de modèle (Zhao et al.)	2025	L’extraction comme menace majeure des services LLM

Le cadrage à retenir est simple : l’extraction de modèle est difficile à détecter requête par requête et facile à détecter fenêtre par fenêtre. Si votre supervision d’API évalue encore les requêtes isolément, un test de distribution calibré sur votre propre trafic légitime est une amélioration peu coûteuse — et à faible taux de faux positifs.