Checklist sécurité et gouvernance LLM en production : 60+ points de contrôle

Pourquoi une checklist spécifique aux LLM ?

Les Large Language Models introduisent des vecteurs d'attaque que les checklists de sécurité applicative classiques ne couvrent pas. Une application web traditionnelle reçoit des requêtes structurées, validées par des schémas. Un LLM reçoit du langage naturel non structuré — une surface d'entrée impossible à valider exhaustivement.

Les principales différences avec la sécurité applicative classique :

• Prompt injection : L'entrée utilisateur peut modifier les instructions du système (équivalent d'une injection SQL, mais pour le raisonnement du modèle).
• Mémorisation involontaire : Les LLM peuvent avoir mémorisé des données sensibles lors de l'entraînement et les restituer à la demande.
• Non-déterminisme : Le même input peut produire des outputs différents — difficile à tester exhaustivement.
• Surface d'attaque des plugins/outils : Un LLM avec accès à des APIs, bases de données ou systèmes de fichiers peut être détourné pour exécuter des actions non autorisées.
• Hallucination comme vecteur de risque : Dans des contextes critiques (médical, juridique, financier), une réponse fausse mais confiante peut causer des dommages réels.

Référentiels utilisés dans cette checklist

Référentiel	Éditeur	Portée	Usage
OWASP LLM Top 10 (2025)	OWASP Foundation	Vulnérabilités LLM applicatives	Identification des vecteurs d'attaque
NIST AI RMF 1.0	NIST (USA)	Gestion des risques IA (govern, map, measure, manage)	Cadre de gouvernance global
Guide IA de l'ANSSI	ANSSI (France)	Sécurité des systèmes IA en contexte national	Exigences réglementaires françaises
ISO/IEC 42001	ISO	Système de management de l'IA	Certification et audit externe

1. Sécurité infrastructure

La sécurité de l'infrastructure hébergeant le LLM est le premier rempart. Un modèle bien configuré sur une infrastructure compromise reste vulnérable.

Isolation et cloisonnement

• ☐ [HAUTE] Le LLM est déployé dans un environnement isolé (namespace Kubernetes dédié, VPC séparé ou réseau privé sans accès Internet direct)
• ☐ [HAUTE] Les communications entre le LLM et les services internes transitent par un réseau privé (jamais par Internet public)
• ☐ [HAUTE] L'accès au nœud hébergeant le modèle est restreint aux administrateurs via bastion SSH avec MFA
• ☐ [MOYENNE] Le modèle tourne dans un conteneur ou VM avec surface d'attaque minimale (image minimale, pas de shell root)
• ☐ [MOYENNE] Les GPU/CPU hébergeant le modèle sont dédiés — pas de colocation avec d'autres workloads non IA

Chiffrement et stockage

• ☐ [HAUTE] Les poids du modèle sont chiffrés au repos (AES-256 minimum)
• ☐ [HAUTE] Toutes les communications client-LLM sont chiffrées en transit (TLS 1.3 minimum)
• ☐ [HAUTE] Les logs et traces sont stockés dans un système séparé, avec chiffrement et accès restreint
• ☐ [MOYENNE] Les sauvegardes du modèle et des configurations sont chiffrées et stockées dans un emplacement distinct
• ☐ [BASSE] Un inventaire des assets (modèle, adapters, bases vectorielles, configurations) est maintenu à jour

Mise à jour et patch management

• ☐ [HAUTE] Les dépendances du framework d'inférence (vLLM, llama.cpp, Ollama…) sont mises à jour mensuellement minimum
• ☐ [HAUTE] Les images de conteneur sont scannées pour vulnérabilités CVE avant tout déploiement
• ☐ [MOYENNE] Un processus de mise à jour du modèle lui-même (nouvelle version, patch) est défini et testé

2. Sécurité des données d'entrée

Le vecteur d'attaque le plus courant sur les LLM en production passe par les données d'entrée. L'OWASP LLM Top 10 classe la prompt injection en première position.

Validation et sanitisation des prompts

• ☐ [HAUTE] Une couche de filtrage des prompts entrants est implémentée (détection de tentatives d'injection directe et indirecte)
• ☐ [HAUTE] La longueur maximale des prompts est limitée et enforced (prévention des attaques par contexte saturé)
• ☐ [HAUTE] Les contenus issus de sources externes (documents uploadés, URLs crawlées, emails) sont traités comme non fiables — jamais injectés directement dans le system prompt
• ☐ [HAUTE] Le system prompt est protégé en écriture — l'utilisateur ne peut pas le modifier ou le visualiser directement
• ☐ [MOYENNE] Un classifier de détection de prompt injection est appliqué avant passage au LLM (modèle de détection dédié ou règles heuristiques)
• ☐ [MOYENNE] Les caractères de contrôle, balises HTML/XML et séquences d'échappement sont filtrés ou encodés dans les inputs

Données dans le contexte RAG

• ☐ [HAUTE] Les documents indexés dans la base vectorielle sont validés et de source connue avant indexation
• ☐ [HAUTE] Les chunks retournés par le RAG sont filtrés selon les permissions de l'utilisateur avant injection dans le contexte
• ☐ [HAUTE] Les métadonnées de source sont systématiquement incluses dans le contexte pour traçabilité
• ☐ [MOYENNE] Un système de détection de documents malveillants (tentatives d'injection via contenu de document) est en place
• ☐ [MOYENNE] La base vectorielle est segmentée par niveau de classification des données (public, interne, confidentiel)

Exemple de configuration de filtrage (Python)

# Exemple : couche de validation des prompts avant LLM
import re
from typing import Optional

INJECTION_PATTERNS = [
    r"ignore (all |previous |above )?(instructions|rules|system prompt)",
    r"you are now (a |an )?(different|new|unrestricted)",
    r"act as (if |though )?you (have no|don't have) (restrictions|guidelines)",
    r"jailbreak",
    r"DAN mode",
    r"\[INST\]|\[SYS\]|<\|im_start\|>",  # tokens spéciaux de prompt
]

def validate_prompt(user_input: str, max_length: int = 4096) -> tuple[bool, Optional[str]]:
    """Valide un prompt utilisateur avant envoi au LLM.
    Retourne (is_valid, reason_if_invalid)"""
    
    # Vérification longueur
    if len(user_input) > max_length:
        return False, f"Prompt trop long ({len(user_input)} > {max_length} chars)"
    
    # Détection patterns d'injection
    lower_input = user_input.lower()
    for pattern in INJECTION_PATTERNS:
        if re.search(pattern, lower_input):
            return False, f"Pattern d'injection détecté : {pattern}"
    
    # Détection de blocs de code suspects avec instructions système
    if "<system>" in lower_input or "\nsystem:" in lower_input:
        return False, "Tentative d'injection de system prompt"
    
    return True, None

# Usage
is_valid, reason = validate_prompt(user_message)
if not is_valid:
    logger.warning(f"Prompt rejeté : {reason} | user_id={user_id}")
    return {"error": "Requête invalide"}, 400

3. Sécurité du modèle

Sélection et approvisionnement

• ☐ [HAUTE] La provenance du modèle est vérifiée : téléchargement depuis le dépôt officiel du créateur uniquement, vérification des hashs SHA256
• ☐ [HAUTE] La licence du modèle est analysée par le service juridique avant déploiement en production
• ☐ [HAUTE] Un scan du modèle (poids et fichiers de configuration) est effectué pour détecter des backdoors ou payloads malveillants (outil : ModelScan d'HiddenLayer)
• ☐ [MOYENNE] Le modèle de base et ses adapters (LoRA, PEFT) sont versionnés et leur intégrité vérifiable

Configuration du modèle

• ☐ [HAUTE] Le system prompt de production est rédigé, validé par la sécurité et la conformité, et versionné dans Git
• ☐ [HAUTE] Les paramètres de génération (temperature, top_p, max_tokens) sont fixés pour la production — pas modifiables par l'utilisateur
• ☐ [HAUTE] Un mécanisme de filtrage des outputs est implémenté (détection de contenu sensible en sortie : PII, données confidentielles, contenu toxique)
• ☐ [MOYENNE] Des garde-fous thématiques (topic guardrails) restreignent le LLM au périmètre métier défini
• ☐ [MOYENNE] La détection d'hallucinations sur des faits critiques est implémentée (vérification des sorties contre une source de vérité)

Fine-tuning et données d'entraînement

• ☐ [HAUTE] Les données utilisées pour le fine-tuning sont vérifiées pour l'absence de données personnelles non consenties
• ☐ [HAUTE] La provenance de chaque dataset d'entraînement est documentée
• ☐ [MOYENNE] Un test de mémorisation est effectué après fine-tuning (vérification que le modèle ne restitue pas de données sensibles mémorisées)
• ☐ [MOYENNE] Les données d'entraînement sont stockées avec les mêmes contrôles d'accès que les données de production

4. Sécurité API et intégrations

Sécurité de l'API LLM

• ☐ [HAUTE] L'API LLM n'est pas exposée directement sur Internet — elle passe par une API Gateway avec authentification
• ☐ [HAUTE] Toutes les requêtes API sont authentifiées (API key, JWT, OAuth2) — pas d'accès anonyme
• ☐ [HAUTE] Un rate limiting par utilisateur/clé est implémenté (prévention des abus et attaques DoS)
• ☐ [HAUTE] Les timeouts sont configurés côté serveur (prévention des blocages par prompts longs)
• ☐ [MOYENNE] Les erreurs API retournées ne révèlent pas d'informations sur l'architecture interne (no stack traces en production)
• ☐ [MOYENNE] Un Web Application Firewall (WAF) est configuré devant l'API avec règles spécifiques LLM

Sécurité des outils et plugins (agents)

• ☐ [HAUTE] Chaque outil accessible par l'agent est listé explicitement — pas d'accès dynamique à des outils non approuvés
• ☐ [HAUTE] Les permissions de chaque outil suivent le principe de moindre privilège (un outil de lecture ne peut pas écrire)
• ☐ [HAUTE] Les appels d'outils sensibles (envoi d'email, modification de données, appels API externes) nécessitent une confirmation humaine
• ☐ [HAUTE] Chaque appel d'outil est loggé avec : timestamp, utilisateur, outil appelé, paramètres, résultat
• ☐ [MOYENNE] Le périmètre d'action de l'agent est restreint à l'environnement de l'utilisateur (un agent ne peut pas accéder aux données d'un autre utilisateur)

Exemple de configuration d'un agent avec permissions restreintes (LangChain)

# Configuration d'un agent LangChain avec outils restreints
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain.tools import tool
from langchain_core.prompts import ChatPromptTemplate
import logging

logger = logging.getLogger(__name__)

@tool
def search_internal_docs(query: str, user_id: str) -> str:
    """Recherche dans la base documentaire interne.
    Restreint aux documents accessibles par l'utilisateur."""
    # Filtrage par permissions utilisateur AVANT la recherche vectorielle
    allowed_collections = get_user_allowed_collections(user_id)
    results = vectordb.similarity_search(
        query,
        filter={"collection": {"$in": allowed_collections}}
    )
    logger.info(f"Tool:search_internal_docs | user={user_id} | query={query[:50]}")
    return format_results(results)

# Outils disponibles : liste explicite et restrictive
ALLOWED_TOOLS = [search_internal_docs]  # Jamais d'accès shell, DB en écriture, email

agent = create_openai_tools_agent(
    llm=llm,
    tools=ALLOWED_TOOLS,
    prompt=system_prompt
)

# Limites d'itération et timeout
executor = AgentExecutor(
    agent=agent,
    tools=ALLOWED_TOOLS,
    max_iterations=5,          # Prévention des boucles infinies
    max_execution_time=30,     # Timeout 30 secondes
    handle_parsing_errors=True,
    verbose=False              # Pas de logs verbeux en production
)

5. Contrôle des accès

Authentification et autorisation

• ☐ [HAUTE] L'authentification au LLM est intégrée à l'annuaire de l'entreprise (LDAP/AD via OIDC/SAML) — pas de comptes locaux
• ☐ [HAUTE] Le MFA est obligatoire pour tous les accès à l'interface LLM
• ☐ [HAUTE] Les droits d'accès aux données RAG sont synchronisés avec les droits existants dans les systèmes sources (GED, SharePoint…)
• ☐ [HAUTE] Les comptes de service utilisés par le LLM pour accéder aux systèmes internes ont des permissions minimales
• ☐ [MOYENNE] Les tokens d'API ont une durée de vie limitée et sont révocables
• ☐ [MOYENNE] Une revue trimestrielle des accès est effectuée et documentée
• ☐ [BASSE] Les accès sont catégorisés par profil (lecture seule, utilisateur standard, administrateur)

Ségrégation des environnements

• ☐ [HAUTE] Les environnements dev, staging et production sont strictement séparés — le modèle de production ne tourne pas en dev
• ☐ [HAUTE] Les données de production ne sont jamais utilisées en dev ou staging (données anonymisées ou synthétiques uniquement)
• ☐ [MOYENNE] Les clés API et secrets de production sont dans un vault (HashiCorp Vault, AWS Secrets Manager) — jamais en dur dans le code

6. Monitoring et détection

Logging opérationnel

• ☐ [HAUTE] Chaque requête LLM est loggée : timestamp, user_id, prompt_hash (pas le texte brut si sensible), output_length, latence, tokens
• ☐ [HAUTE] Les logs sont centralisés dans un SIEM (Splunk, Elastic, Wazuh) avec alertes temps réel
• ☐ [HAUTE] Les tentatives de prompt injection détectées déclenchent une alerte immédiate vers l'équipe sécurité
• ☐ [HAUTE] Les outputs du LLM contenant des données potentiellement sensibles (PII, clés, credentials) déclenchent une alerte
• ☐ [MOYENNE] Un tableau de bord de monitoring LLM est maintenu (latence, taux d'erreur, taux de refus, anomalies de volume)

Détection d'anomalies comportementales

• ☐ [HAUTE] Des seuils d'utilisation par utilisateur sont définis et monitorés (volume de tokens, fréquence des requêtes)
• ☐ [MOYENNE] Les patterns d'utilisation anormaux sont détectés (horaires inhabituels, volumes exceptionnels, requêtes répétitives similaires)
• ☐ [MOYENNE] Un score de confiance des réponses est calculé et loggé pour identifier les zones à risque d'hallucination
• ☐ [MOYENNE] Les conversations longues dépassant un seuil de contexte sont analysées pour détecter des tentatives d'exfiltration progressive

Configuration YAML — Monitoring avec Prometheus

# prometheus-llm-alerts.yml
groups:
  - name: llm_security
    rules:
      # Alerte si trop de requêtes refusées (tentatives d'injection)
      - alert: LLMHighRejectionRate
        expr: rate(llm_requests_rejected_total[5m]) > 10
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Taux de rejet LLM anormalement élevé"
          description: "{{ $value }} requêtes/s rejetées — possible attaque"

      # Alerte si latence P99 > 30s (possible saturation du contexte)
      - alert: LLMHighLatency
        expr: histogram_quantile(0.99, llm_request_duration_seconds) > 30
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Latence LLM critique"

      # Alerte si un utilisateur dépasse 1000 tokens/min
      - alert: LLMUserRateLimit
        expr: rate(llm_tokens_consumed_total[1m]) by (user_id) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Utilisation excessive LLM par utilisateur {{ $labels.user_id }}"

7. Conformité réglementaire

RGPD et données personnelles

• ☐ [HAUTE] Une AIPD (Analyse d'Impact sur la Protection des Données) a été conduite si le LLM traite des données personnelles à grande échelle
• ☐ [HAUTE] Le LLM est ajouté au registre de traitement RGPD de l'entreprise
• ☐ [HAUTE] La base légale du traitement des conversations utilisateur est définie et documentée
• ☐ [HAUTE] La durée de conservation des conversations est définie et techniquement enforced (suppression automatique)
• ☐ [HAUTE] Les droits RGPD (accès, rectification, suppression) sont techniquement possibles sur les données de conversation
• ☐ [MOYENNE] Si le LLM utilise un fournisseur cloud hors UE, les transferts de données sont encadrés (SCCs, BCRs)

EU AI Act

• ☐ [HAUTE] Le système LLM est classifié selon les niveaux de risque EU AI Act
• ☐ [HAUTE] Si risque élevé (RH, crédit, santé…) : documentation technique EU AI Act rédigée
• ☐ [MOYENNE] Les utilisateurs sont informés qu'ils interagissent avec un système IA (obligation de transparence)
• ☐ [MOYENNE] Un registre des systèmes IA est maintenu, incluant le LLM

8. Gouvernance et documentation

Politiques et procédures

• ☐ [HAUTE] Une politique d'utilisation du LLM est rédigée, approuvée et communiquée à tous les utilisateurs
• ☐ [HAUTE] Les cas d'usage autorisés et interdits sont documentés de façon explicite
• ☐ [HAUTE] Un processus d'approbation pour les nouveaux cas d'usage est défini (qui approuve, quels critères)
• ☐ [MOYENNE] Une formation sécurité LLM est dispensée à tous les utilisateurs avant premier accès
• ☐ [MOYENNE] Les responsabilités (propriétaire du système, responsable sécurité, responsable conformité) sont définies et documentées
• ☐ [MOYENNE] Un processus de revue sécurité semestrielle est planifié et tenu

Documentation technique

• ☐ [HAUTE] L'architecture du système LLM est documentée (schéma de flux, composants, points d'intégration)
• ☐ [HAUTE] Les procédures de déploiement, mise à jour et rollback sont documentées et testées
• ☐ [MOYENNE] Le system prompt de production est versionné dans Git avec historique des modifications
• ☐ [MOYENNE] Les résultats des tests de sécurité (red teaming, pentests) sont archivés
• ☐ [BASSE] Un runbook opérationnel couvre les scénarios d'incident courants

9. Plan de réponse aux incidents

Préparation

• ☐ [HAUTE] Un plan de réponse aux incidents spécifique aux systèmes IA est rédigé et validé
• ☐ [HAUTE] L'équipe de réponse est identifiée avec des contacts 24/7 pour les incidents critiques
• ☐ [HAUTE] La procédure d'arrêt d'urgence du LLM est documentée et testée (kill switch)
• ☐ [MOYENNE] Des exercices de simulation d'incident LLM sont conduits au moins annuellement

Types d'incidents et procédures

Type d'incident	Sévérité	Action immédiate	Notification
Prompt injection réussie avec exfiltration de données	Critique	Suspendre l'accès, isoler les logs	RSSI + DPO + CNIL (72h si données perso)
Fuite de données mémorisées du modèle	Haute	Documenter les outputs, évaluer le périmètre	RSSI + DPO, évaluer notification CNIL
Contournement des garde-fous (jailbreak)	Haute	Analyser le vecteur, patcher le filtrage	RSSI, équipe sécurité
Disponibilité dégradée (DoS, saturation)	Moyenne	Activer le rate limiting renforcé	Équipe ops, utilisateurs impactés
Hallucination critique dans un contexte sensible	Variable	Corriger l'output, informer l'utilisateur	Responsable métier, conformité si impact réglementaire

• ☐ [HAUTE] Les seuils de notification CNIL sont définis (violation de données personnelles via LLM)
• ☐ [HAUTE] La chaîne d'escalade est testée lors des exercices de simulation
• ☐ [MOYENNE] Un processus de retour d'expérience post-incident (PIR) est conduit systématiquement