Distillation et alerte NSA/CISA/FBI : protéger modèles et prompts sans ruiner l’usage

Un signal cyber mondial, et pourtant très “PME de Lyon”

Tu n’as pas un “frontier model” maison. Tu n’as pas 200 chercheurs. Et pourtant, l’alerte te concerne.

Le 8 septembre 2026, la NSA, la CISA et le FBI ont publié un Cybersecurity Advisory AA26-251A sur des campagnes de distillation “à l’échelle industrielle” visant des modèles via des usages abusifs, notamment via API. Source : CISA, AA26-251A (08/09/2026) via dejavu.org https://www.dejavu.org/cgi-bin/get.cgi?url=https%3A%2F%2Fwww.cisa.gov%2F%2Fnews-events%2Fcybersecurity-advisories%2Faa26-251a&ver=93&utm_source=openai.

Quelques mois plus tôt, la directive américaine NSTM-4 (23/04/2026) citait explicitement des tentatives de distillation non autorisée et à grande échelle, et appelait à structurer des bonnes pratiques de défense. Source : Maison Blanche https://www.whitehouse.gov/wp-content/uploads/2026/04/NSTM-4.pdf?utm_source=openai.

Traduction pour les boîtes lyonnaises et AURA : dès que tu exposes un LLM en production, tu crées une surface d’attaque. Même si tu n’as “que” :

• un assistant interne (RH, support, juridique),
• des agents qui appellent des outils (CRM, ERP, ITSM, drive, bases doc),
• ou une API qui sort des réponses à forte valeur (résumés experts, scoring, extraction structurée, recommandations).

Et ce risque se superpose à des classiques déjà en tête côté OWASP GenAI, comme la divulgation d’informations sensibles et l’injection de prompt. Source : OWASP GenAI Top 10 https://genai.owasp.org/llm-top-10/?utm_source=openai.

Distillation modèles IA : la menace, version opérationnelle

La distillation est une technique normale en machine learning : un “student” apprend d’un “teacher”. Le problème, c’est la version hostile : l’attaquant requête ton modèle en masse, récupère les sorties, et entraîne un modèle clone qui reproduit ton comportement.

Ce n’est pas forcément du vol de poids. C’est du model theft / model extraction : on n’exfiltre pas les paramètres, on approxime le modèle par observation. Source : Microsoft, catalogue des techniques d’attaque “model theft” https://learn.microsoft.com/en-us/security/zero-trust/catalog-ai-attack-techniques/model-theft?utm_source=openai.

Pourquoi tes prompts sont une cible

Quand on parle de protection prompts, il ne s’agit pas seulement d’éviter que quelqu’un copie “la formule magique”. L’attaquant veut tout ce qui augmente la valeur d’apprentissage :

• instructions système (règles internes, politiques, garde-fous),
• exemples (few-shot), gabarits, structures de réponse,
• sorties structurées qui servent de labels,
• indices sur tes règles métier (tarification, éligibilité, processus),
• et parfois, au passage, de la donnée sensible si ton assistant n’est pas verrouillé.

Donc oui, “distillation modèles IA” et “cybersécurité IA” se rejoignent : ce qui est volé, c’est à la fois une capacité et un avantage concurrentiel.

Trois vecteurs concrets en entreprise : API, assistant interne, agents

1) API LLM et endpoints internes

Le scénario typique est bête et méchant : scripts 24/7, haut débit, itérations systématiques sur des familles d’inputs. Le but : cartographier ton comportement, stabiliser un dataset, entraîner un clone.

Le point important dans l’alerte : ne pas regarder uniquement le volume. Regarde des patterns comportementaux. Source : AA26-251A via dejavu.org https://www.dejavu.org/cgi-bin/get.cgi?url=https%3A%2F%2Fwww.cisa.gov%2F%2Fnews-events%2Fcybersecurity-advisories%2Faa26-251a&ver=93&utm_source=openai.

2) Assistants internes (chat RH, support, juridique)

Deux risques se combinent :

• System prompt leakage : l’utilisateur tente de faire recracher les instructions internes.
• Sensitive information disclosure : l’utilisateur obtient (ou fait reformuler) des infos qu’il ne devrait pas voir.

Source : OWASP GenAI Top 10 https://genai.owasp.org/llm-top-10/?utm_source=openai.

Et même si tu penses “c’est interne, donc sûr” : un compte compromis, un prestataire, ou juste un usage détourné, et ton “interne” devient une porte d’entrée.

3) Agents connectés à des outils (le multiplicateur de risques)

Quand ton agent peut appeler des outils, l’attaquant peut faire du mix :

• distillation (vol de comportement),
• exfiltration (vol de données),
• et contournement (forcer des formats, déclencher des actions).

On retombe sur les risques OWASP liés à l’“agency” et à la divulgation d’infos. Source : OWASP GenAI Top 10 https://genai.owasp.org/llm-top-10/?utm_source=openai.

Sécurité LLM entreprise : l’objectif est simple

Tu ne vas pas “empêcher” toute distillation. L’objectif réaliste :

• augmenter le coût de l’attaque (temps, comptes, infrastructure),
• réduire le gain (sorties moins utiles pour entraîner un clone),
• détecter tôt et couper proprement,
• éviter la fuite de secrets (prompts, règles, données).

Et tu veux faire ça sans casser l’expérience utilisateur, sinon tes équipes repasseront en Shadow AI. Sur ce point, tu peux recroiser avec le sujet “IA fantôme” : https://lyon-ia.com/blog/shadow-ai-en-entreprise.

Mesures techniques prioritaires (pragmatiques, déployables)

1) Rate limiting et throttling, mais intelligents

Le rate limiting basique par IP ne suffit plus. Les attaques se répartissent. Fais-le à plusieurs niveaux :

• par clé API,
• par utilisateur (IAM),
• par tenant (si multi-client),
• par type d’opération (chat libre vs extraction structurée vs scoring),
• par coût tokens (plafonds de budget et alertes).

Idée simple : une extraction structurée “parfaite” est souvent plus distillable qu’un chat. Donc tu limites plus fort ce qui produit des labels propres.

OWASP relie aussi la consommation non bornée à des risques de vol et de dégradation. Source (synthèse Trend Micro sur OWASP) : https://documents.trendmicro.com/assets/research-reports/owasp-10-llm-and-vision-one.pdf?utm_source=openai.

2) Détection d’anomalies : cherche les comportements “machine”

Ce que tu veux détecter, ce n’est pas “beaucoup de requêtes”. C’est “requêtes comme un robot qui entraîne un modèle”. Exemples de signaux :

• activité 24/7,
• utilisation à 100 % dès la création d’un compte ou d’une clé,
• répétitivité (mêmes structures, mêmes tailles, même langue),
• faible diversité linguistique et sémantique,
• inputs générés automatiquement, séries paramétriques, balayage.

Source : analyse CSA sur les risques “nation-state” et la distillation https://labs.cloudsecurityalliance.org/research/csa-ai-model-distillation-nation-state-risk-v1-0-csa-styled/?utm_source=openai.

3) Corrélation multi-sources : arrête de logger “dans ton coin”

Si tu as :

• des logs API,
• un WAF,
• des logs IAM (SSO, MFA, device),
• et un SIEM ou au moins une centralisation,

alors tu peux repérer les attaques distribuées (plusieurs comptes, plusieurs IP, même pattern). Sans ça, tu vois juste “des gens qui utilisent l’outil”.

4) Protéger les prompts : séparation, minimisation, rotation

La protection prompts passe rarement par un “prompt secret” unique. C’est plutôt une hygiène :

• sépare instructions système (politiques) et logique métier (règles) et données (contenu),
• minimise les détails internes dans les instructions,
• évite les exemples trop “golden” si tu exposes l’API à l’extérieur,
• rotate et versionne tes prompts comme du code (avec revue et historique).

Si tu veux un rappel sur l’injection, c’est ici : https://lyon-ia.com/blog/injection-de-prompt-securite.

5) Réponses dégradées : la “riposte” recommandée, mais avec un cerveau

Une recommandation mise en avant dans les discussions autour de l’alerte : des “targeted response changes”. En clair : si tu as un score d’abus élevé, tu peux modifier subtilement les réponses pour réduire la valeur de distillation, sans prévenir l’attaquant.

Source (relai grand public des recommandations) : TechRadar https://www.techradar.com/pro/security/fbi-nsa-warn-chinese-ai-companies-like-deepseek-and-alibaba-are-reportedly-carrying-out-industrial-scale-distillation-campaigns-to-boost-their-models?utm_source=openai.

Le piège : si tu dégrades trop tôt, tu casses des usages légitimes (QA, data, intégrations, partenaires). Donc tu poses des règles :

• dégradation uniquement au-delà d’un seuil de confiance (score d’abus),
• dégradation graduée (latence, précision, structure),
• canal de recours interne (support, whitelist temporaire),
• tests pour vérifier que tu ne crées pas de vulnérabilités ou de biais.

Exemples de dégradation “soft” (à manier avec prudence) :

• réduire la granularité des réponses structurées (moins de champs, moins de certitudes),
• introduire une variabilité contrôlée dans la formulation,
• limiter l’accès à certaines capacités “premium” (extraction massive, batch) quand le pattern ressemble à un entraînement.

6) Watermarking, fingerprinting, provenance : utile pour l’audit, pas une barrière totale

Le watermarking est souvent compris de travers. Pour la distillation, il ne “bloque” pas l’attaque. Par contre, ça peut aider à :

• tracer des sorties,
• attribuer des contenus,
• auditer des usages,
• et parfois alimenter une détection d’abus (si tu retrouves tes marqueurs ailleurs).

Le NIST a publié une vue d’ensemble sur la réduction des risques liés au contenu synthétique. Source : NIST https://www.nist.gov/publications/reducing-risks-posed-synthetic-content-overview-technic.

Gouvernance : sans ça, tes contrôles techniques se contournent

Journalisation utile (pas juste “on garde des logs”)

Tu dois pouvoir répondre à trois questions : qui a demandé quoi, quand, et avec quel niveau d’accès. Donc :

• journalisation des appels (métadonnées, coûts, latence, succès/échec),
• journalisation des outils appelés par les agents (actions, paramètres sensibles masqués),
• rétention alignée avec tes obligations (et pas “à vie”).

Pour cadrer la conservation : https://lyon-ia.com/blog/politique-conservation-donnees-ia.

Classification des secrets : prompts et sorties inclus

Le problème, c’est que beaucoup d’entreprises classent “documents” et “données”, mais pas :

• les prompts système,
• les templates d’extraction,
• les jeux d’exemples,
• les sorties (qui peuvent révéler des règles internes).

Décide noir sur blanc ce qui est :

• public,
• interne,
• confidentiel,
• secret (et donc jamais envoyé à un fournisseur, jamais exposé via assistant).

Si tu veux une approche “PME” sur données et IA, tu peux croiser avec : https://lyon-ia.com/blog/piratage-du-fisc-et-controle-cnil-10-controles-donnees-ia-pour-une-pme-lyonnaise.

Red teaming : teste comme un adversaire, pas comme un utilisateur poli

Tu veux faire du red teaming sur :

• fuite d’instructions système,
• exfiltration via formats et extractions,
• contournements d’autorisations (agents + outils),
• capacités distillables (réponses trop “propres” et stables).

Et tu testes aussi tes “ripostes” : si tu dégrades, est-ce que tu crées de faux positifs ? Est-ce que tu fais perdre confiance à tes équipes ?

Encadré spécial PME : contrôles simples à poser en 2 semaines

Objectif : améliorer vite ta sécurité LLM entreprise sans projet à 6 mois.

• 1. Inventaire express : liste tous les points d’entrée (API, bots internes, agents, connecteurs). Un tableau suffit.
• 2. Quotas par défaut : plafonds par utilisateur et par clé. Et alertes budget tokens.
• 3. Auth solide : SSO si possible, MFA obligatoire, clés API jamais partagées.
• 4. Logs centralisés : au minimum, regrouper logs API + IAM + WAF dans un même endroit consultable.
• 5. Règle simple sur les prompts : pas de règles métier sensibles dans le prompt système, pas d’exemples “or” exposés si l’API sort en externe.
• 6. Liste rouge d’usages : ce que l’assistant ne doit jamais traiter (secrets commerciaux, mots de passe, données RH sensibles).
• 7. Test d’attaque interne : 10 scénarios (fuite de prompt, extraction structurée massive, agent qui appelle des outils). Tu mesures ce qui sort.

Pour les agents connectés à des outils, garde un guide très concret sous le coude : https://lyon-ia.com/blog/securiser-un-agent-ia.

Ce que tu dois accepter (et piloter) pour ne pas “casser l’expérience”

La défense parfaite n’existe pas. Ce que tu peux faire, c’est piloter le compromis :

• Friction minimale pour 95 % des usages (employés, clients),
• Contrôles renforcés pour les 5 % à risque (automatisation, batch, patterns suspects),
• Canal officiel pour demander des exceptions (sinon Shadow AI revient).

La bonne approche, c’est une sécurité “adaptative” : tu ne bloques pas tout, tu adaptes selon le contexte.

Plan d’action actionnable pour cette semaine

• Cartographie : où sont tes LLM en prod, qui y accède, via quoi.
• Contrôles d’accès : SSO/MFA, rôles, clés par application, rotation.
• Rate limiting : quotas multi-niveaux + limites plus strictes sur extraction structurée.
• Détection : 5 signaux d’abus, un score simple, une alerte.
• Riposte prudente : dégradation graduée uniquement si suspicion forte, avec procédure de recours.
• Hygiène prompts : minimiser, séparer, versionner, éviter les exemples “gold” exposés.
• Red team : 10 tests concrets, un compte rendu, des corrections.

Si tu veux un cadre plus large sur la sécurisation des LLM en production (menaces et parades), tu peux aussi t’appuyer sur : https://lyon-ia.com/blog/securiser-vos-llm-en-production-menaces-et-parades-pour-les-entreprises.

Message final : la distillation n’est pas un sujet “Silicon Valley”. C’est un problème d’exploitation. Et à Lyon comme ailleurs, dès que tu mets un assistant ou une API en prod, tu dois le gérer comme un produit exposé. Avec des garde-fous. Et avec des logs.