Sécurité des LLM

La sécurité des LLM est la discipline spécialisée de protection des applications construites sur des modèles de langage contre une classe unique de menaces qui n’existait pas dans la sécurité logicielle traditionnelle. Alors que les organisations déploient des chatbots IA, des agents autonomes et des flux de travail alimentés par LLM à grande échelle, comprendre et traiter les vulnérabilités spécifiques aux LLM devient une exigence opérationnelle critique.

Pourquoi les LLM nécessitent une nouvelle approche de sécurité

La sécurité applicative traditionnelle suppose une frontière claire entre le code (instructions) et les données (entrée utilisateur). La validation d’entrée, les requêtes paramétrées et l’encodage de sortie fonctionnent en appliquant cette frontière de manière structurelle.

Les modèles de langage effondrent cette frontière. Ils traitent tout — instructions du développeur, messages utilisateur, documents récupérés, sorties d’outils — comme un flux unifié de tokens en langage naturel. Le modèle ne peut pas distinguer de manière fiable un prompt système d’une entrée utilisateur malveillante conçue pour ressembler à un tel prompt. Cette propriété fondamentale crée des surfaces d’attaque sans équivalent dans les logiciels traditionnels.

De plus, les LLM sont des agents capables et utilisant des outils. Un chatbot vulnérable n’est pas seulement un risque de contenu — il peut être un vecteur d’attaque pour exfiltrer des données, exécuter des appels API non autorisés et manipuler des systèmes connectés.

L’OWASP LLM Top 10

L’Open Worldwide Application Security Project (OWASP) publie le LLM Top 10 — la référence standard de l’industrie pour les risques critiques de sécurité LLM :

LLM01 — Injection de prompt : Des entrées malveillantes ou du contenu récupéré remplacent les instructions du LLM. Voir Injection de prompt .

LLM02 — Gestion non sécurisée des sorties : Le contenu généré par le LLM est utilisé dans des systèmes en aval (rendu web, exécution de code, requêtes SQL) sans validation, permettant des attaques XSS, injection SQL et autres attaques secondaires.

LLM03 — Empoisonnement des données d’entraînement : Des données malveillantes injectées dans les ensembles de données d’entraînement provoquent une dégradation du comportement du modèle ou introduisent des portes dérobées.

LLM04 — Déni de service du modèle : Des entrées coûteuses en calcul provoquent une consommation excessive de ressources, dégradant la disponibilité du service.

LLM05 — Vulnérabilités de la chaîne d’approvisionnement : Des modèles pré-entraînés, plugins ou données d’entraînement compromis introduisent des vulnérabilités avant le déploiement.

LLM06 — Divulgation d’informations sensibles : Les LLM révèlent des données confidentielles provenant des données d’entraînement, des prompts système ou des documents récupérés. Voir Exfiltration de données (contexte IA) .

LLM07 — Conception non sécurisée de plugins : Les plugins ou outils connectés aux LLM manquent d’autorisation appropriée, permettant des attaques par escalade.

LLM08 — Agence excessive : Les LLM dotés de permissions ou de capacités excessives peuvent causer des dommages importants lorsqu’ils sont manipulés.

LLM09 — Dépendance excessive : Les organisations ne parviennent pas à évaluer de manière critique les sorties du LLM, permettant aux erreurs ou informations fabriquées d’affecter les décisions.

LLM10 — Vol de modèle : Accès non autorisé ou réplication de poids ou capacités LLM propriétaires.

Prêt à développer votre entreprise?

Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.

Demander une démo Se connecter

Contrôles de sécurité LLM essentiels

Séparation des privilèges et autorité minimale

Le contrôle unique le plus impactant : limitez ce que votre LLM peut accéder et faire. Un chatbot de service client n’a pas besoin d’accéder à la base de données RH, aux systèmes de traitement des paiements ou aux API d’administration. L’application des principes de moindre privilège limite considérablement le rayon d’impact d’une attaque réussie.

Sécurité du prompt système

Les prompts système définissent le comportement du chatbot et contiennent souvent des instructions sensibles pour l’entreprise. Les considérations de sécurité incluent :

• Ne pas inclure de secrets, clés API ou identifiants dans les prompts système
• Concevoir des prompts résistants aux tentatives de remplacement
• Instruire explicitement le modèle de ne pas révéler le contenu du prompt
• Tester la confidentialité du prompt dans le cadre des évaluations de sécurité régulières (voir Extraction de prompt système )

Validation des entrées et sorties

Bien qu’aucun filtre ne soit infaillible, la validation des entrées réduit la surface d’attaque :

• Signaler et bloquer les modèles d’injection courants et les formulations ressemblant à des instructions dans les entrées utilisateur
• Valider les sorties du modèle avant de les transmettre aux systèmes en aval
• Utiliser des formats de sortie structurés (schémas JSON) pour contraindre les réponses du modèle

Sécurité du pipeline RAG

La génération augmentée par récupération introduit de nouvelles surfaces d’attaque. Les déploiements RAG sécurisés nécessitent :

• Des contrôles stricts sur qui peut ajouter du contenu aux bases de connaissances indexées
• La validation du contenu avant l’indexation
• Traiter tout contenu récupéré comme potentiellement non fiable
• Surveiller les tentatives d’empoisonnement RAG

Garde-fous d’exécution

Des garde-fous d’exécution en couches fournissent une défense en profondeur au-delà de l’alignement au niveau du modèle :

• Filtres de modération de contenu sur les entrées et les sorties
• Détection d’anomalies comportementales
• Limitation de débit et prévention des abus
• Journalisation d’audit pour l’analyse forensique

Tests de sécurité réguliers

Les techniques d’attaque LLM évoluent rapidement. Les tests de pénétration IA et le red teaming IA doivent être effectués régulièrement — au minimum avant les changements majeurs et annuellement comme évaluations de référence.

Termes connexes

• Injection de prompt — la vulnérabilité LLM la plus critique
• OWASP LLM Top 10 — le cadre complet des risques de sécurité LLM
• Red teaming IA — tests de sécurité adverses systématiques
• Empoisonnement RAG — attaques de contamination de base de connaissances
• Tests de pénétration IA — évaluations de sécurité structurées pour les systèmes IA