L'erreur stratégique la plus fréquente sur la sécurité LLM en 2026 : choisir une couche (un guardrail, un system prompt durci, un classifier) et croire que le problème est résolu. La prompt injection est, par construction, une menace probabiliste qui ne disparaît pas — elle se réduit. La seule réponse défendable est la défense en profondeur : plusieurs couches indépendantes dont les modes d'échec ne se recouvrent pas.
Cet article aborde la défense en profondeur sous l'angle stratégique (threat model, architecture, gouvernance, conformité) plutôt que tactique. Pour les implémentations concrètes par couche, voir les articles dédiés : protéger une application LLM, system prompt durci, guardrails, détection runtime.
Pourquoi la défense en profondeur LLM diffère
Trois propriétés rendent l'approche LLM différente d'un WAF ou d'une défense réseau classique :
- Mélange donnée/instruction : un LLM reçoit un prompt qui contient à la fois le contexte système (instruction) et l'input utilisateur (donnée), et il les concatène en un seul flux qu'il interprète sémantiquement. Aucun parser n'extrait l'instruction de la donnée comme dans le langage SQL ou HTML.
- Surface d'attaque incluant le contenu retrieved : RAG, browsing, emails, fichiers — toute donnée externe ingérée est un vecteur. La surface dépasse largement l'input direct.
- Défense probabiliste : aucune couche ne couvre 100% des attaques. Les benchmarks publics (HarmBench, JailbreakBench) mesurent les bypass, et ils sont non-nuls même pour les meilleurs produits.
Conséquence : le bon analogue mental n'est pas le WAF, c'est la lutte anti-fraude — accumulation de signaux faibles, scoring multi-dimensionnel, calibration continue, acceptation d'un taux de FP/FN, monitoring runtime obligatoire.
Threat model : STRIDE-LLM et MITRE ATLAS
Avant d'empiler des couches, formaliser le modèle de menace. Deux référentiels utilisables :
STRIDE adapté au LLM
| Catégorie STRIDE | Manifestation LLM | Exemple concret |
|---|---|---|
| Spoofing | Persona injection / impersonation | DAN, Developer Mode, claim d'identité système |
| Tampering | Modification du comportement via injection | Override d'instructions, RAG poisoning |
| Repudiation | Action sans trace attribuable | Tool call déclenché par injection indirecte sans log |
| Information disclosure | Leak de system prompt, exfiltration RAG | EchoLeak, Bing Sydney, system prompt leak |
| Denial of service | Prompts qui font boucler ou consommer le quota | Many-shot, prompts adversariaux longs |
| Elevation of privilege | LLM exécute action qu'il ne devrait pas | Tool call non autorisé déclenché par injection |
MITRE ATLAS
MITRE ATLAS (Adversarial Threat Landscape for AI Systems) catalogue les techniques adverses contre les systèmes IA. Pour un LLM, les techniques pertinentes incluent : Prompt Injection (AML.T0051), LLM Plugin Compromise (AML.T0053), LLM Jailbreak (AML.T0054), Indirect Prompt Injection (AML.T0070).
Couvrir explicitement ces techniques dans le threat model permet de mapper chaque couche défensive à une ou plusieurs techniques — exigence de plus en plus demandée par auditeurs externes (EU AI Act, ISO 42001, NIST AI RMF).
Tip — Documenter le threat model dans un format vivant (markdown versionné), pas un PDF qui dort. Le mettre à jour à chaque évolution majeure de l'application ou des techniques d'attaque publiques. Cible : revue trimestrielle.
Architecture cible : 7 couches indépendantes
Pour un système exposé en production, l'architecture défensive cible :
┌─────────────────────────────────────┐
│ Couche 7 — Audit & red teaming │
│ (externe, périodique) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 6 — Gouvernance & monitoring │
│ (SOC, SIEM, runbooks, KPIs) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 5 — Tool allowlist + HITL │
│ (approval pour actions sortantes) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 4 — Output filter (DLP) │
│ (Presidio, canary detection, URLs) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 3 — Sanitization ingestion │
│ (RAG chunks, docs, emails, web) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 2 — System prompt durci │
│ (rôle strict, délimiteurs, canary) │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Couche 1 — Input filter │
│ (regex + classifier + guardrail) │
└─────────────────────────────────────┘Propriétés clés :
- Indépendance des modes d'échec : un bypass de couche 1 (regex + classifier) ne signifie pas un bypass de couche 4 (output filter). Si elles partageaient le même classifier, l'indépendance serait illusoire.
- Granularité d'intervention : chaque couche peut être activée, désactivée, calibrée séparément.
- Observabilité par couche : chaque couche émet ses propres métriques et logs vers le SIEM.
- Coût décroissant : les premières couches (input filter, system prompt) sont peu coûteuses ; les dernières (audit externe, HITL) sont plus chères mais critiques.
| Couche | Coût relatif | Couverture incrémentale | Article dédié |
|---|---|---|---|
| 1 — Input filter | Faible | Élevée (attaques connues) | détecter |
| 2 — System prompt | Très faible | Modérée | system prompt |
| 3 — Sanitization | Faible | Élevée (indirecte) | protéger LLM |
| 4 — Output filter | Moyen | Modérée à élevée | protéger LLM |
| 5 — Tool + HITL | Moyen | Très élevée (agents) | agents APIs |
| 6 — Gouvernance | Moyen | Transverse | Cet article |
| 7 — Audit externe | Élevé | Transverse | red teaming LLM |
Décisions de trade-off
Toute stratégie défensive arbitre entre quatre dimensions :
| Dimension | Levier | Trade-off |
|---|---|---|
| Latence | Plus de couches synchrones = plus de p95 | UX vs sécurité |
| Coût | Couches managées + infra interne | $ vs autonomie |
| Faux positifs (FPR) | Seuils stricts | Friction utilisateur vs couverture |
| Faux négatifs (FNR) | Seuils permissifs | Couverture vs friction |
Cadre de décision par profil de risque
| Profil | Exemples | Cible FPR | Cible FNR | Latence acceptable |
|---|---|---|---|---|
| Critique | Santé, finance, défense, M365-class | < 0.5% | < 5% | < 200ms p95 |
| Élevé | Support client B2B, RH, juridique | < 1-2% | < 10% | < 300ms p95 |
| Modéré | Chatbot grand public sans données | < 3% | < 20% | < 500ms p95 |
| Faible | Outil interne dev, sandbox | < 5% | < 30% | < 1s |
Calibrer les seuils selon ce profil, pas selon les défauts du fournisseur. Le profil détermine aussi le nombre de couches obligatoires (cf. modèle de maturité ci-dessous).
Modèle de maturité par niveau
Cinq niveaux progressifs. Chaque niveau ajoute des couches et de la rigueur opérationnelle.
Niveau 1 — Initial (POC)
- System prompt minimal, sans canary token.
- Aucun filtre input/output.
- Pas de monitoring.
- Tools débridés.
- Risque : fuite quasi-certaine sous attaque ciblée. Acceptable seulement pour POC interne sans données sensibles.
Niveau 2 — MVP
- System prompt durci (rôle strict + délimiteurs + canary).
- Input filter regex + classifier managé (Lakera, Prompt Shields).
- Désactivation rendu markdown image côté UI.
- Logs structurés vers SIEM.
- Risque : couvre 60-80% des attaques connues. Acceptable pour public non-sensible.
Niveau 3 — Production standard
- Niveaux 1-2 + sanitization à l'ingestion (RAG, docs, emails).
- Output filter DLP (Presidio + canary detection + allowlist URLs).
- Tool allowlist statique pour agents.
- Monitoring runtime + alerting SOC.
- Red teaming interne semestriel.
- Risque : couvre 80-95% des attaques connues. Acceptable pour la plupart des cas d'usage entreprise.
Niveau 4 — Production critique
- Niveaux 1-3 + approval HITL pour actions sortantes (envoi email, partage, API externes).
- Isolation par contexte de confiance (les chunks d'un user ne passent pas en système).
- Canary tokens dans documents test continus.
- Red teaming externe trimestriel.
- Conformité documentée (NIST AI RMF, ISO 42001).
- Risque : couvre > 95% des attaques connues. Requis pour santé, finance, défense, M365-class.
Niveau 5 — Optimisé
- Niveaux 1-4 + recherche interne sur nouvelles techniques d'attaque (veille arXiv mensuelle, contributions open source).
- Bug bounty IA actif.
- Threat intelligence partagée avec partenaires/communauté.
- Re-calibration mensuelle des seuils.
- Métriques de maturité publiées (cf. NIST AI RMF Tier 4).
Cible réaliste pour la plupart des organisations : niveau 3 dans l'année qui suit le déploiement, niveau 4 pour les systèmes critiques sous 18-24 mois.
Mapping aux référentiels
La défense en profondeur LLM doit s'aligner avec les référentiels en vigueur. Trois cadres principaux à connaître en 2026.
NIST AI RMF (AI Risk Management Framework, 2023+)
Quatre fonctions principales : Govern, Map, Measure, Manage. Pour la prompt injection, le mapping typique :
- Govern : politique de sécurité IA, ownership, RACI, formation des équipes.
- Map : threat model STRIDE-LLM + MITRE ATLAS, classification de risque par usage.
- Measure : métriques par couche (TPR/FPR, latence, MTTD/MTTR), benchmarks périodiques.
- Manage : runbooks SOC, calibration continue, gestion d'incident.
EU AI Act (entrée en vigueur progressive 2024-2027)
Pour les systèmes IA à haut risque (Annexe III : santé, éducation, RH, justice, infrastructures critiques) :
- Article 9 — Système de gestion des risques (obligatoire) : threat model documenté.
- Article 10 — Données : qualité et gouvernance des données d'entraînement et d'inférence.
- Article 13 — Transparence : information utilisateur sur les limites du système.
- Article 14 — Surveillance humaine : approval HITL pour actions critiques.
- Article 15 — Cybersécurité : robustesse contre les attaques (incluant prompt injection).
Sanctions jusqu'à 35M€ ou 7% du CA mondial pour non-conformité sur systèmes à haut risque.
ISO 42001 (publiée décembre 2023)
Premier standard international de management de l'IA. Aligné sur la structure ISO (Plan-Do-Check-Act). Couvre :
- Contexte organisationnel et parties intéressées
- Leadership et politique
- Planification (objectifs, gestion des risques IA)
- Support (compétences, communication, documentation)
- Opération (contrôles techniques, gestion de fournisseurs IA)
- Évaluation des performances (audit, revue de direction)
- Amélioration
ISO 42001 fournit le cadre formel ; NIST AI RMF fournit le pratico-technique. Les deux sont complémentaires.
OWASP LLM Top 10 v2 (2025)
Référence technique opérationnelle. La défense en profondeur couvre directement :
- LLM01 Prompt Injection
- LLM02 Sensitive Information Disclosure
- LLM03 Supply Chain
- LLM06 Excessive Agency
- LLM07 System Prompt Leakage
Pour le détail OWASP : audit IA générative OWASP LLM Top 10 et audit conformité NIST/ISO/EU AI Act.
Gouvernance, ownership et cadence opérationnelle
Une stratégie sans gouvernance est un PowerPoint. La défense en profondeur LLM exige une structure RACI explicite et des cadences opérationnelles.
RACI type
| Responsabilité | Owner principal | Contributeurs |
|---|---|---|
| Threat model | RSSI / Security Architect | Tech lead LLM, Data Privacy Officer |
| System prompt + sanitization | Tech lead LLM | AppSec |
| Input/output filters | AppSec | Tech lead LLM, SRE |
| Monitoring + SOC | SOC | AppSec, SRE |
| Red teaming | Red team / externe | RSSI |
| Conformité (NIST/AI Act/ISO) | DPO + RSSI | Direction juridique |
| Gestion incident | SOC + RSSI | Tech lead LLM, Comms |
Cadences opérationnelles
| Cadence | Activité |
|---|---|
| Continue | Monitoring runtime, alertes SOC |
| Hebdo | Revue des détections, ajustement seuils mineurs |
| Mensuelle | Revue des métriques, re-calibration classifiers, mise à jour corpus de test |
| Trimestrielle | Revue threat model, audit interne, métriques direction |
| Semestrielle | Red teaming interne, revue conformité |
| Annuelle | Red teaming externe, revue politique de sécurité IA, audit ISO 42001 si applicable |
KPIs minimum
- Couverture techniques d'attaque : % des techniques du Top 20 jailbreak bloquées sur corpus de test.
- MTTD (Mean Time to Detect) : temps moyen entre attaque réussie et détection.
- MTTR (Mean Time to Respond) : temps moyen entre détection et action.
- FPR sur trafic légitime : taux de blocage erroné.
- Disponibilité du service : pas dégradée par les couches défensives.
- Coût défensif total / coût LLM : ratio à monitorer (cible 5-20%).
Pour l'opérationnalisation runtime côté SOC, voir détecter une prompt injection en temps réel.
Points clés à retenir
- La prompt injection est une menace probabiliste qui ne se résout pas par une seule mesure. Toute stratégie sérieuse repose sur la défense en profondeur avec couches indépendantes.
- Threat model d'abord (STRIDE-LLM + MITRE ATLAS), avant d'empiler des outils. Documenté, vivant, mis à jour trimestriellement.
- 7 couches cibles : input filter, system prompt durci, sanitization à l'ingestion, output filter DLP, tool allowlist + HITL, gouvernance/monitoring, audit externe.
- Modèle de maturité 5 niveaux : POC → MVP → Production standard → Production critique → Optimisé. Cibler niveau 3 dans l'année, niveau 4 pour les systèmes critiques.
- Trade-offs explicites : latence, coût, FPR, FNR. Calibrer selon le profil de risque (critique, élevé, modéré, faible), pas selon les défauts vendeur.
- Conformité incontournable en 2026 : NIST AI RMF (technique), EU AI Act (légal/sanctions), ISO 42001 (management), OWASP LLM Top 10 (opérationnel).
- Gouvernance = RACI explicite + cadences (continue → hebdo → mensuelle → trimestrielle → annuelle) + KPIs (MTTD, MTTR, FPR, couverture).
- Ne pas créer de cellule IA isolée : intégrer la défense LLM aux pratiques existantes (SOC, AppSec, audit, threat modeling, red team).
La défense en profondeur LLM est un programme, pas un produit. Sa qualité se mesure dans la durée — capacité à détecter de nouvelles techniques, à calibrer en continu, à intégrer les retours du SOC et des red teams. C'est un alignement entre architecture technique, gouvernance et opérationnel, indissociables.
