OWASP Top 10 pour les LLM : Guide Remédiation 2026

# Exemple de défense multi-couche contre la prompt injection
import re, hashlib, json

class PromptInjectionGuard:
    INJECTION_PATTERNS = [
        r"(?i)ignore\s+(all\s+)?previous\s+instructions",
        r"(?i)you\s+are\s+now\s+(?:a|an)\s+(?:un)?restricted",
        r"(?i)system\s*:\s*you\s+(?:are|must|should)",
        r"(?i)(?:print|repeat|reveal)\s+(?:your\s+)?(?:system|initial)\s+(?:prompt|instructions)",
    ]

    def sanitize_input(self, user_input: str) -> tuple[str, bool]:
        """Retourne (input nettoyé, is_suspicious)"""
        suspicious = False
        for pattern in self.INJECTION_PATTERNS:
            if re.search(pattern, user_input):
                suspicious = True
                user_input = re.sub(pattern, "[FILTERED]", user_input)
        return user_input, suspicious

    def build_safe_prompt(self, system_prompt, user_msg, canary):
        """Instruction hierarchy avec canary token"""
        return f"""[SYSTEM INSTRUCTIONS - PRIORITY ABSOLUTE]
{{system_prompt}}
CANARY: {{canary}}
[END SYSTEM] --- [USER DATA BELOW - UNTRUSTED] ---
{{user_msg}}
[END USER DATA]"""

# Détection de data poisoning avec analyse statistique
from sklearn.ensemble import IsolationForest
from sentence_transformers import SentenceTransformer
import numpy as np

def detect_poisoned_samples(dataset: list[str], contamination=0.05):
    """Détecte les échantillons potentiellement empoisonnés"""
    model = SentenceTransformer("all-MiniLM-L6-v2")
    embeddings = model.encode(dataset)

    # Isolation Forest pour détecter les outliers
    clf = IsolationForest(contamination=contamination, random_state=42)
    predictions = clf.fit_predict(embeddings)

    suspicious = [i for i, p in enumerate(predictions) if p == -1]
    return suspicious, embeddings

# Vérification de la dérive post-fine-tuning
def audit_finetuning(model_before, model_after, safety_benchmark):
    """Compare les scores de sécurité avant/après fine-tuning"""
    score_before = evaluate(model_before, safety_benchmark)
    score_after = evaluate(model_after, safety_benchmark)
    drift = score_before - score_after
    if drift > 0.05:  # 5% de dégradation = alerte
        alert(f"Safety score drift: {drift:.2%}")
    return drift

• ▹Gouvernance et Architecture : les deux piliers qui couvrent le plus de vulnérabilités — une architecture défensive solide et une gouvernance rigoureuse protègent contre 9 des 10 vulnérabilités
• ▹Output Controls insuffisants seuls : les contrôles de sortie ne couvrent que partiellement les menaces Supply Chain, Data Poisoning et Model Theft — ils doivent être complétés par des contrôles en amont
• ▹Monitoring universel : la surveillance est pertinente pour les 10 vulnérabilités — c'est la couche transversale de détection et de réponse aux incidents LLM

5 LLM07-08 : Insecure Plugin Design et Excessive Agency

Avec l'essor des architectures agentiques en 2026, les vulnérabilités LLM07 (Insecure Plugin Design) et LLM08 (Excessive Agency) sont passées du statut de risques théoriques à celui de menaces opérationnelles critiques. Les LLM ne se contentent plus de générer du texte : ils exécutent des outils, appellent des API, manipulent des fichiers et prennent des décisions autonomes via des frameworks comme CrewAI, AutoGen et le Model Context Protocol (MCP). Chaque plugin, chaque outil connecté, chaque fonction appelable est un vecteur d'attaque potentiel qui étend la surface d'attaque bien au-delà du modèle lui-même.

LLM07 — Insecure Plugin Design

L'insecure plugin design survient lorsque les outils et plugins connectés au LLM ne valident pas correctement les entrées qu'ils reçoivent du modèle. Le problème fondamental est que les développeurs traitent souvent les requêtes du LLM comme des sources fiables, alors qu'un LLM compromis par prompt injection peut envoyer des paramètres malveillants à n'importe quel outil connecté. Les vecteurs d'attaque incluent l'injection de commandes via les paramètres de plugins shell, l'escalade de privilèges lorsqu'un plugin fonctionne avec des droits élevés sans restriction, la traversée de répertoire via les plugins de lecture de fichiers, et l'exfiltration de données via des plugins réseau (requêtes HTTP, envoi d'emails). Un cas typique en 2026 : un plugin MCP de gestion de fichiers, appelé par un LLM compromis par injection indirecte, qui exfiltre le contenu de fichiers sensibles vers un serveur externe via une requête HTTP construite par le modèle.

Remédiation LLM07 : sécuriser chaque plugin comme un endpoint

Chaque plugin doit être traité comme un endpoint API exposé à un utilisateur non fiable. Le principe du moindre privilège exige que chaque plugin fonctionne avec les permissions minimales nécessaires — un plugin de lecture de fichiers ne doit pas avoir d'accès en écriture, un plugin de requête SQL doit être limité à des requêtes SELECT sur des tables spécifiques. L'input validation stricte sur chaque paramètre de plugin (type checking, whitelist de valeurs, sanitization des chemins de fichiers, parameterized queries) empêche les injections. Le sandboxing exécute les plugins dans des environnements isolés (conteneurs, gVisor, Firecracker) avec des limites de ressources et un réseau restreint. Chaque appel de plugin doit être loggé et auditable avec les paramètres reçus, le résultat retourné et l'identité de l'utilisateur ayant initié la chaîne d'appels.

Mise en pratique et recommandations

LLM08 — Excessive Agency

L'excessive agency survient lorsqu'un LLM dispose de capacités d'action disproportionnées par rapport à ce que son cas d'usage requiert, et surtout lorsque ces actions sont exécutées sans confirmation humaine. En 2026, les agents autonomes basés sur LLM peuvent exécuter du code, modifier des bases de données, envoyer des communications, et interagir avec des API externes. Un agent avec un excessive agency peut, en réponse à une prompt injection ou une hallucination, supprimer des données en production, envoyer des emails à des clients avec des informations erronées, effectuer des transactions financières non autorisées, ou modifier des configurations critiques. Le problème est amplifié par les architectures multi-agents où un agent compromis peut influencer le comportement de tous les agents en aval dans la chaîne de traitement.

Remédiation LLM08 : contrôle de l'autonomie

La remédiation de l'excessive agency repose sur le contrôle granulaire de ce que le LLM est autorisé à faire. Le human-in-the-loop (HITL) obligatoire pour toute action à impact élevé (modifications de données, transactions, communications externes) interrompt l'exécution automatique et demande une validation humaine explicite. L'action whitelisting définit une liste explicite des actions autorisées pour chaque contexte — tout ce qui n'est pas explicitement permis est interdit par défaut. La confirmation pour actions sensibles implémente un mécanisme de double validation : le modèle propose l'action, un système de vérification indépendant (règles métier, second modèle, validation humaine) l'approuve ou la rejette. L'audit trail complet de toutes les actions exécutées permet la détection a posteriori des abus et la reconstruction forensique en cas d'incident.

Outils et ressources complementaires

# Architecture sécurisée pour plugins et agents LLM
from enum import Enum
from dataclasses import dataclass

class ActionRisk(Enum):
    LOW = "low"       # Lecture seule, aucun effet de bord
    MEDIUM = "medium"  # Modifications réversibles
    HIGH = "high"     # Actions irréversibles, données sensibles
    CRITICAL = "critical" # Transactions, communications externes

@dataclass
class PluginPolicy:
    name: str
    allowed_actions: list[str]
    risk_level: ActionRisk
    requires_approval: bool
    max_calls_per_minute: int
    sandbox: bool = True

class AgencyController:
    def execute_action(self, action, params, policy):
        # 1. Vérifier que l'action est dans la whitelist
        if action not in policy.allowed_actions:
            raise PermissionError(f"Action '{action}' non autorisée")
        # 2. HITL pour les actions à haut risque
        if policy.requires_approval:
            approval = self.request_human_approval(action, params)
            if not approval: return {"status": "rejected_by_human"}
        # 3. Exécution sandboxée avec audit
        self.audit_log(action, params, policy)
        return self.sandbox_execute(action, params)

• ▹Règle critique LLM07 : chaque plugin est un endpoint API non fiable — implémenter validation d'entrée, moindre privilège et sandboxing sur chaque outil connecté au LLM
• ▹Règle critique LLM08 : un LLM ne devrait jamais exécuter une action irréversible sans validation humaine — implémenter HITL obligatoire pour les actions HIGH et CRITICAL
• ▹Pattern sécurisé : adopter l'architecture "propose-verify-execute" — le LLM propose, un contrôleur vérifie contre les politiques, et l'exécution se fait dans un sandbox audité
• ▹Multi-agents : dans les architectures multi-agents, chaque agent doit avoir sa propre politique de sécurité et les communications inter-agents doivent être validées comme des inputs non fiables

6 LLM09-10 : Overreliance et Model Theft

Les deux dernières vulnérabilités du classement OWASP ciblent des risques de nature très différente : l'overreliance (LLM09) est une vulnérabilité humaine amplifiée par la technologie, tandis que le model theft (LLM10) est une menace de propriété intellectuelle avec des implications financières considérables. Malgré leurs scores de risque modérés (7.0 et 7.8), ces deux vulnérabilités peuvent causer des dommages systémiques qui dépassent largement ceux d'une simple exploitation technique. Pour approfondir, consultez RAG en Production : Architecture, Scaling et Bonnes.

LLM09 — Overreliance : le danger des hallucinations non détectées

L'overreliance se manifeste lorsque les utilisateurs ou les systèmes automatisés font confiance aux sorties d'un LLM sans vérification adéquate. Les LLM génèrent des hallucinations — des affirmations factuellement incorrectes mais formulées avec une confiance apparente élevée — à un taux qui varie entre 3% et 15% selon le modèle et le domaine. Dans un contexte professionnel, cette overreliance peut avoir des conséquences graves : des décisions juridiques fondées sur des jurisprudences inventées (cas Mata v. Avianca, 2023), des diagnostics médicaux erronés basés sur des informations hallucinées, des rapports financiers contenant des chiffres fabriqués, ou des décisions automatisées prises sans intervention humaine sur la base de recommandations incorrectes du modèle. Le risque est amplifié par le phénomène d'automation bias : les humains ont tendance à faire davantage confiance aux systèmes automatisés qu'à leur propre jugement, surtout lorsque les sorties sont formulées de manière convaincante.

Remédiation LLM09 : ancrage et vérification

La remédiation de l'overreliance combine des mesures techniques et organisationnelles. Le RAG (Retrieval-Augmented Generation) ancre les réponses du modèle dans des sources de données vérifiables, réduisant significativement le taux d'hallucinations factuelles. Les mécanismes de fact-checking automatisé croisent les affirmations du LLM avec des bases de connaissances structurées (Knowledge Graphs, bases documentaires certifiées) pour détecter les incohérences. Le confidence scoring évalue la certitude du modèle sur chaque affirmation et signale visuellement les passages à faible confiance — les architectures modernes utilisent des techniques comme la calibration de température, le self-consistency checking (générer plusieurs réponses et vérifier leur cohérence), et les modèles d'évaluation dédiés. Les disclaimers systématiques rappellent aux utilisateurs que les sorties doivent être vérifiées, tandis que les workflows intègrent des étapes de validation humaine obligatoire avant toute action basée sur une recommandation LLM.

Perspectives et evolution

LLM10 — Model Theft : extraction et vol de modèles

Le model theft englobe les techniques permettant de voler ou reproduire un modèle propriétaire sans autorisation. L'extraction via API (model extraction attack) consiste à interroger massivement un modèle pour entraîner un modèle clone qui reproduit son comportement — des recherches ont démontré qu'avec suffisamment de requêtes (quelques millions), il est possible de distiller un modèle qui atteint 90-95% des performances de l'original. Les side-channel attacks exploitent les métadonnées des réponses (timing, logprobs, nombre de tokens) pour extraire des informations sur l'architecture interne du modèle. Les insider threats restent le vecteur le plus direct : un employé avec accès aux poids du modèle peut les copier et les exfiltrer. En 2026, avec des coûts d'entraînement dépassant les 100 millions de dollars pour les modèles frontier, le vol de modèle représente une menace de propriété intellectuelle considérable.

Mise en pratique et recommandations

Remédiation LLM10 : protection de la propriété intellectuelle

La protection contre le vol de modèle nécessite des contrôles à plusieurs niveaux. Le rate limiting agressif avec des budgets de requêtes par utilisateur et par période limite la quantité de données exploitables pour une attaque d'extraction — un plafond de quelques milliers de requêtes par jour rend l'extraction impraticable. Le watermarking insère des signatures invisibles dans les sorties du modèle qui permettent de tracer l'origine des données en cas de redistribution non autorisée — des techniques comme le watermarking de distributions de tokens sont résistantes à la post-édition. Les access controls stricts (authentification forte, réseau privé, chiffrement des poids) protègent les artefacts du modèle contre l'exfiltration. Le monitoring comportemental détecte les patterns d'utilisation anormaux indicatifs d'une tentative d'extraction : requêtes systématiques couvrant uniformément l'espace des entrées, fréquence anormalement élevée, ou patterns de requêtes caractéristiques d'un dataset de distillation.

• ▹Overreliance systémique : implémenter le RAG avec citation des sources, le confidence scoring visible, et des workflows de validation humaine obligatoire pour les décisions critiques
• ▹Model Theft prévention : combiner rate limiting strict, watermarking des sorties, contrôle d'accès aux poids et monitoring comportemental des patterns d'extraction
• ▹Hallucinations critiques : dans les domaines à haut risque (médical, juridique, financier), imposer une vérification humaine de 100% des sorties LLM avant toute décision ou action
• ▹Détection d'extraction : alerter sur les utilisateurs dépassant le P99 en volume de requêtes avec une distribution uniforme des sujets — signature typique d'un dataset de distillation

7 Implémentation Globale : Checklist de Sécurisation LLM

Après avoir analysé individuellement chacune des dix vulnérabilités, cette section synthétise l'ensemble en une stratégie de sécurisation holistique. La défense en profondeur pour les LLM ne consiste pas à empiler des contrôles isolés, mais à construire une architecture cohérente où chaque couche de défense compense les faiblesses des autres. Cette section fournit la checklist complète de sécurisation pré-déploiement, les outils recommandés et le cadre de conformité applicable en 2026.

Architecture de défense en profondeur

L'architecture de défense en profondeur pour les LLM s'organise en cinq couches concentriques. La couche Périmètre (rate limiting, WAF IA-aware, authentification) protège l'accès au service. La couche Input (sanitization, injection detection, input validation) filtre les entrées malveillantes. La couche Modèle (guardrails, instruction hierarchy, canary tokens) contrôle le comportement du LLM lui-même. La couche Output (DLP, output encoding, type validation, PII scanning) assainit les sorties. La couche Exécution (sandboxing, HITL, action whitelisting) contrôle les actions déclenchées par le modèle. Chaque couche doit fonctionner indépendamment et être testée individuellement. L'échec d'une couche ne doit pas compromettre la sécurité globale — c'est le principe fondamental de la défense en profondeur appliqué à l'IA.

Checklist de sécurisation pré-déploiement

Cette checklist de 20 items couvre l'ensemble des vulnérabilités OWASP LLM Top 10 et doit être validée intégralement avant tout déploiement en production. Chaque item est classé par criticité et associé aux vulnérabilités qu'il adresse.

Mise en oeuvre et bonnes pratiques

• ▹[CRITIQUE] Input sanitization : validation et filtrage de toutes les entrées utilisateur contre les patterns d'injection connus (LLM01)
• ▹[CRITIQUE] Output encoding : assainissement de toutes les sorties LLM avant insertion dans un contexte d'exécution — HTML, SQL, shell (LLM02)
• ▹[CRITIQUE] Instruction hierarchy : séparation stricte entre instructions système et données utilisateur avec délimiteurs forts (LLM01)
• ▹[CRITIQUE] Plugin input validation : chaque plugin valide ses paramètres indépendamment du LLM, avec type checking et whitelist (LLM07)
• ▹[CRITIQUE] Human-in-the-loop : approbation humaine obligatoire pour toute action irréversible ou à impact élevé (LLM08)
• ▹[ÉLEVÉ] Rate limiting : limites par utilisateur, par IP et par API key avec paliers progressifs (LLM04, LLM10)
• ▹[ÉLEVÉ] DLP output scanning : détection et masquage automatique des PII, secrets et données classifiées dans les sorties (LLM06)
• ▹[ÉLEVÉ] Model provenance : AI SBOM documentant le modèle de base, les datasets, les adaptateurs et toutes les dépendances (LLM05)
• ▹[ÉLEVÉ] Canary tokens : marqueurs secrets dans le system prompt pour détecter les tentatives d'extraction (LLM01, LLM06)
• ▹[ÉLEVÉ] Action whitelisting : liste explicite des actions autorisées par contexte, rejet par défaut de tout le reste (LLM08)
• ▹[ÉLEVÉ] Model scanning : analyse des fichiers de modèles tiers pour détecter les payloads malveillants avant chargement (LLM05)
• ▹[ÉLEVÉ] Sandboxing plugins : exécution isolée de chaque plugin avec limites de ressources et réseau restreint (LLM07)
• ▹[MOYEN] Data provenance : traçabilité complète de chaque échantillon dans les datasets de fine-tuning (LLM03)
• ▹[MOYEN] Safety benchmarking : évaluation automatisée du modèle sur un benchmark de sécurité après chaque mise à jour (LLM03)
• ▹[MOYEN] RAG grounding : ancrage des réponses dans des sources vérifiables avec citation obligatoire (LLM09)
• ▹[MOYEN] Confidence scoring : indication visuelle du niveau de certitude du modèle sur chaque assertion (LLM09)
• ▹[MOYEN] Watermarking : insertion de signatures dans les sorties pour tracer la redistribution non autorisée (LLM10)
• ▹[MOYEN] Timeout et circuit breakers : coupure automatique des requêtes excessives et désactivation en cas de surcharge (LLM04)
• ▹[MOYEN] Audit logging : journalisation complète de toutes les interactions, paramètres de plugins et actions exécutées (LLM07, LLM08)
• ▹[MOYEN] CSP stricte : Content Security Policy bloquant l'exécution de scripts inline générés par le LLM (LLM02)

Outils de sécurité LLM en 2026

L'écosystème d'outils de sécurité LLM s'est considérablement enrichi depuis 2024. Garak (NVIDIA) est le framework de red teaming LLM le plus complet, offrant des centaines de probes pré-configurées couvrant les 10 vulnérabilités OWASP avec des générateurs d'attaques automatisés et des rapports de couverture détaillés. NeMo Guardrails (NVIDIA) fournit un DSL (Colang) pour définir des règles de comportement programmatiques qui contrôlent les entrées, les sorties et les interactions du LLM avec les outils externes — c'est la solution de guardrails la plus mature en production. LLM Guard (Protect AI) offre une suite de scanners d'entrée et de sortie couvrant la détection d'injection, le scanning PII, la validation de toxicité et le contrôle de format. Rebuff est spécialisé dans la détection de prompt injection avec un moteur multi-couche combinant analyse heuristique, détection par LLM et vérification de canary tokens. Ces outils s'intègrent comme middleware dans les pipelines LLM existants (LangChain, LlamaIndex) et fonctionnent en temps réel avec une latence acceptable en production. Pour approfondir, consultez 10 Erreurs Courantes dans.

Conformité et cadres réglementaires

En 2026, trois cadres réglementaires et normatifs structurent la gouvernance de la sécurité des LLM. L'AI Act européen (Règlement 2024/1689) impose pour les systèmes IA à haut risque des exigences de gestion des risques (Article 9), de gouvernance des données (Article 10), de documentation technique (Article 11), de transparence (Article 13) et de supervision humaine (Article 14). Le non-respect peut entraîner des amendes allant jusqu'à 35 millions d'euros ou 7% du chiffre d'affaires mondial. Le NIST AI Risk Management Framework (AI RMF 1.0) fournit un cadre volontaire structuré en quatre fonctions — GOVERN, MAP, MEASURE, MANAGE — qui guide l'identification et la mitigation des risques IA tout au long du cycle de vie. La norme ISO/IEC 42001:2023 (AI Management System) définit les exigences d'un système de management de l'IA, incluant la gestion des risques, la gouvernance des données et la supervision continue. Un programme de bug bounty pour applications IA complète ces cadres en offrant une évaluation continue par la communauté de sécurité, avec des catégories spécifiques pour les vulnérabilités LLM (prompt injection, data extraction, jailbreak).

Analyse approfondie et recommandations

À Propos de l'Auteur

Ayi NEDJIMI • Expert Cybersécurité & IA

Ayi NEDJIMI est un expert senior en cybersécurité offensive et intelligence artificielle avec plus de 20 ans d'expérience en développement avancé, tests d'intrusion et architecture de systèmes critiques. Spécialisé en rétro-ingénierie logicielle, forensics numériques et développement de modèles IA, il accompagne les organisations stratégiques dans la sécurisation d'infrastructures hautement sensibles.

Expert reconnu en expertises judiciaires et investigations forensiques, Ayi intervient régulièrement en tant que consultant expert auprès des plus grandes organisations françaises et européennes. Son expertise technique couvre l'audit Active Directory, le pentest cloud (AWS, Azure, GCP), la rétro-ingénierie de malwares, ainsi que l'implémentation de solutions RAG et bases vectorielles (Milvus, Qdrant, Weaviate) pour des applications IA d'entreprise.

20+Ans d'expérience

100+Missions réalisées

150+Articles & conférences

Conférencier et formateur reconnu en cybersécurité, Ayi anime régulièrement des conférences techniques et participe activement au développement de modèles d'intelligence artificielle pour la détection de menaces avancées. Auteur de plus de 150 publications techniques, il partage son expertise de haut niveau pour aider les RSSI et architectes sécurité à anticiper les cybermenaces émergentes et déployer des solutions IA de nouvelle génération.

📚 Tous ses articles 🛡️ Demander un audit 💼 LinkedIn

Pour approfondir ce sujet, consultez notre outil open-source llm-security-scanner qui facilite l'audit de sécurité des modèles de langage.

Questions frequentes

Pourquoi la securite des modeles LLM est-elle importante ?

La securite des modeles LLM est cruciale car ces systemes peuvent etre vulnerables aux injections de prompts, aux attaques par empoisonnement de donnees et aux fuites d'informations sensibles. Une securisation inadequate peut exposer l'organisation a des risques de confidentialite, d'integrite et de disponibilite.

Nous avons entraîné un modèle spécialisé CyberSec-Assistant-3B pour assister les professionnels en cybersécurité et IA.

Conclusion

Cet article a couvert les aspects essentiels de Table des Matières, 1 Introduction à l'OWASP Top 10 pour les LLM, 2 LLM01-02 : Prompt Injection et Insecure Output Handling. La mise en pratique de ces recommandations permet de renforcer significativement la posture de securite de votre organisation.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI, consultant en cybersecurite et intelligence artificielle, peut vous accompagner sur ce sujet : audit, formation ou conseil personnalise.

Demander un devis gratuit

Partager cet article

Twitter LinkedIn Copier le lien

Ayi NEDJIMI

Expert Cybersécurité & Intelligence Artificielle

Consultant et formateur spécialisé en tests d'intrusion, Active Directory, et développement de solutions IA. 15+ années d'expérience en sécurité offensive.

Articles connexes

Benchmark LLM Mars 2026 : Etat des Lieux Complet en 2026

Etat des lieux complet des benchmarks LLM en mars 2026 : classements, methodologies et limites des evaluations.

02/03/2026

Claude Opus 4.6 : Applications en Cybersecurite en 2026

Exploration des capacites de Claude Opus 4.6 pour les cas d'usage cybersecurite : analyse de code, threat hunting, audit.

01/03/2026

IA et Zero Trust : Micro-Segmentation Dynamique Pilotée par

Micro-segmentation réseau adaptative en temps réel pilotée par ML, scoring de confiance dynamique, UEBA et continuous authentication dans une architecture.

28/02/2026

Article précédent

Orchestration d'Agents IA : Patterns et Anti-Patterns

Article suivant

Phishing Généré par IA : Nouvelles Menaces : Guide

Commentaires

Aucun commentaire pour le moment. Soyez le premier à commenter !

Laisser un commentaire

Nom *

Email * (non publié)

Commentaire *

Publier