L'OWASP Top 10 for LLM Applications est devenu en 2025-2026 le référentiel de base pour structurer la sécurité d'une app LLM. Mais beaucoup d'équipes le lisent comme une liste de menaces sans la convertir en contrôles défendables. Voici, pour chacun des 10 risques, le contrôle que je pose et le moyen de vérifier qu'il marche.
LLM01 — Prompt Injection
Risque : un attaquant manipule l'agent via input direct ou contenu externe (RAG, web).
Contrôles :
- Détection runtime (Rebuff, Lakera, classifier custom — voir comparatif outils).
- Privileges scope-down côté tools (un agent qui lit un document n'a pas accès aux tools d'envoi d'email).
- Defense in depth : isolation entre instructions système et contenu utilisateur (delimiters, structured prompting).
Vérification : suite Promptfoo/PyRIT avec 50-200 prompts injection en CI, bloquant.
LLM02 — Insecure Output Handling
Risque : l'output du LLM est utilisé sans validation (XSS, SQL injection via texte généré, code malveillant exécuté).
Contrôles :
- Output filtering systématique (HTML escape avant rendu UI, prepared statements toujours, jamais d'exec sur du contenu LLM).
- Sandboxing si exécution code généré.
- Allowlist sur les actions déclenchables par output.
Vérification : test injection HTML/SQL via prompt qui demande la génération de payload, vérifier que l'output ne casse pas le rendu UI.
LLM03 — Training Data Poisoning
Risque : données d'entraînement ou fine-tuning compromises.
Contrôles : provenance dataset, hash, scan PII, échantillonnage manuel, tests post-entraînement. Détail dans data poisoning et model leakage.
Vérification : audit annuel des datasets utilisés, traçabilité documentée. Tests adversariaux après chaque fine-tune.
LLM04 — Model Denial of Service
Risque : prompts qui font boucler ou consommer ressources excessives.
Contrôles :
- Limites tokens / tool calls / wall-clock / budget par session (voir migration chatbot vers agent).
- Rate limiting par utilisateur et par tenant.
- Détection des patterns de cost runaway.
Vérification : test load avec prompts piégés (boucles infinies, prompts XXL), vérifier que les limites coupent proprement.
LLM05 — Supply Chain Vulnerabilities
Risque : dépendances modèle, datasets, libs compromis.
Contrôles :
- SBOM incluant les modèles utilisés (avec hash et version).
- Évaluation fournisseurs LLM (voir audit fournisseur LLM DDQ).
- Scan des modèles téléchargés (Picklescan, ModelScan).
- Signature des artefacts (Sigstore).
Vérification : politique fournisseurs documentée, SBOM généré à chaque build, signatures vérifiées au déploiement.
LLM06 — Sensitive Information Disclosure
Risque : fuite de PII, secrets, données métier via outputs LLM.
Contrôles :
- Output filtering avec liste de patterns sensibles (PII, secrets, IDs internes).
- Cloisonnement RAG par tenant.
- Tests memorization (cf. data poisoning et model leakage).
- Pas de secrets en clair dans le system prompt.
Vérification : suite de tests qui essaie de faire ressortir des PII connues du training/RAG, monitoring runtime sur les outputs.
LLM07 — Insecure Plugin Design
Risque : tools/plugins MCP avec scope trop large, validation insuffisante des inputs.
Contrôles :
- Catalogue tools minimal et versionné (voir sécurité MCP).
- Validation stricte des paramètres tool, schema-typed.
- Authentication et autorisation au niveau tool, pas seulement au niveau agent.
- Audit log par tool call.
Vérification : revue chaque nouveau tool en mode "que peut faire un attaquant qui le contrôle ?", tests de fuzzing sur les paramètres.
LLM08 — Excessive Agency
Risque : l'agent prend des actions à fort impact sans validation humaine.
Contrôles :
- Catégorisation des actions (lecture / écriture interne / action externe / irréversible).
- Validation humaine obligatoire à partir de "action externe".
- Double validation sur "irréversible".
- Kill-switch accessible en < 30 secondes.
Vérification : scénarios de test où l'agent reçoit une instruction adverse, vérifier que les paliers de validation s'enclenchent.
LLM09 — Overreliance
Risque : équipes/utilisateurs qui font confiance aveugle aux outputs LLM.
Contrôles :
- Disclaimers UI clairs sur les limites du modèle.
- Sources affichées quand RAG (l'utilisateur peut vérifier).
- Mesure du taux de validation aveugle (humain qui clique "approuver" sans lire) — si ça monte, signal d'alerte.
- Formation utilisateurs internes.
Vérification : enquête utilisateur trimestrielle + analyse logs validation.
LLM10 — Model Theft
Risque : extraction du modèle par requêtes ou exfiltration directe.
Contrôles :
- Rate limiting fort sur l'API.
- Détection de patterns d'extraction (requêtes systématiques, volumes inhabituels).
- Watermarking outputs.
- Accès restreint aux modèles internes (registry avec ACL).
Vérification : monitoring usage avec alerting sur patterns suspects, exercice de simulation extraction annuel.
Comment je l'utilise en mission
Quand je cadre un programme sécu IA, je pars du Top 10 comme structure de gap analysis :
- Pour chaque LLMxx, je note l'état actuel (rien / partiel / en place).
- Je priorise par criticité du cas d'usage.
- Je propose une roadmap qui couvre les 10 sur 6-12 mois selon maturité.
- Je relie chaque contrôle à un référentiel cadre (NIST AI RMF, ISO 42001, MITRE ATLAS) pour la défendabilité auditeur.
Cette structure rend le programme lisible par la direction et compatible avec les audits ISO 42001 / NIST AI RMF. Voir articulation ISO 27001 / 42001 / RGPD / AI Act.
Mon avis en 1 ligne
L'OWASP LLM Top 10 n'a de valeur que quand chaque ligne est convertie en contrôle vérifié, pas en bonne intention listée dans un PowerPoint. Démarrer par LLM01, LLM07, LLM08 (les trois plus exploitables en pratique), puis dérouler. Compter 2-3 jours-conseil pour la gap analysis initiale, puis 6-12 mois de roadmap.