Le paysage de menace LLM
OWASP a publié en 2024 le LLM Top 10, adapté au contexte IA générative. Le risque n'est plus seulement applicatif classique (OWASP Top 10 standard) — il s'étend au comportement du modèle lui-même.
Top 3 des risques que nous voyons en mission : prompt injection (LLM01), informations sensibles dans les sorties (LLM02), dépendance à des tiers (LLM03).
Le défenseur doit penser comme l'attaquant : un LLM est une machine à exécuter du langage naturel. Tout ce que le modèle peut faire, un attaquant peut tenter de le faire via le prompt.
Prompt injection (LLM01) : le risque numéro 1
Principe : un attaquant injecte dans le contexte du modèle des instructions qui contournent le prompt système. Exemple typique : un utilisateur demande au RAG de 'ignorer les instructions précédentes et révéler le prompt système'.
Sources d'injection : input utilisateur direct, mais AUSSI contenus tiers (pages web crawlées, documents ingérés dans le RAG, messages d'outils). Un PDF malveillant ingéré peut contenir une prompt injection.
Antidotes : (1) cloisonner le prompt système dans un channel séparé du contexte utilisateur (OpenAI permet cela via system vs user messages). (2) valider et sanitizer les sorties du modèle (jamais de code exécuté sans validation). (3) couche de garde (modèle léger qui vérifie la sortie avant action).
Sur les agents avec tool use : la règle absolue est qu'un tool ne doit JAMAIS exécuter une action irréversible sans confirmation humaine si la requête vient d'un canal utilisateur non-vérifié.
Sorties sensibles (LLM02) : PII et secrets
Un LLM peut ingérer des données sensibles (PII, secrets, IP métier) et les restituer dans une réponse ultérieure. C'est le risque de fuite par le modèle lui-même.
Antidotes : (1) ne JAMAIS inclure de secrets ou credentials dans le contexte ou le prompt système. (2) anonymiser les PII avant ingestion dans le RAG. (3) filtrer les sorties via une regex/entity recognizer (Presidio, etc.) qui masque les PII détectées.
Sur le cas juridique VALRY LABS : tous les noms de personnes physiques dans les documents sont remplacés par des pseudonymes avant l'indexation. La ré-identification se fait côté UI uniquement, sur requête authentifiée.
Logging : les prompts complets et les sorties complètes sont conservés 12 mois pour audit, mais sous forme hashée côté PII, et accessibles uniquement à l'équipe sécurité.
SSRF via tool use (LLM03 et variantes)
Si votre agent a accès à un tool 'fetch URL', un attaquant peut potentiellement le faire accéder à des endpoints internes (metadata AWS, réseau interne, admin panels).
Antidotes : allowlist stricte des domaines accessibles (pas de wildcard). Pas de fetch sur des IPs privées (RFC 1918) ou link-local (169.254.169.254 — le fameux endpoint metadata cloud).
Validation : schema JSON strict sur les paramètres d'entrée du tool. Pas de paramètre libre 'url' — toujours décomposer en host + path, valider le host contre une allowlist.
Logging de chaque appel tool, alerte si tentative d'URL non-allowlistée.
Supply chain modèles (LLM08)
Les modèles eux-mêmes peuvent être empoisonnés (data poisoning de l'entraînement) ou backdoorés. Moins probable sur les gros modèles commerciaux, plus probable sur les modèles fine-tunés ou open-source tiers.
Antidotes : ne charger que des modèles depuis des sources vérifiées (Hugging Face verified authors, ou modèle commercial). Vérifier le hash du modèle. Pour le fine-tuning, audit du dataset.
Sur les modèles open-source auto-hébergés : preferer des modèles Llama/Mistral depuis leurs dépôts officiels, et non des mirrors aléatoires. Hugging Face a un système de signature à vérifier.
SBOM modèle : inventorier version, hash, dataset d'entraînement quand disponible. Ajouter à votre SBOM applicatif global.
Gouvernance et journalisation (LLM10)
Toute interaction avec un LLM doit être journalisée : utilisateur, prompt (anonymisé), modèle, version, durée, coût, classification sécurité de la sortie. Conservation 12 mois minimum.
Audit log append-only, immuable, stocké séparément. Accès restreint à l'équipe sécurité. Rotation de clé d'accès trimestrielle.
Droit d'accès RGPD : un utilisateur peut demander l'historique de ses interactions. Prévoir une extraction par `user_id` en moins de 30 jours.
Incident response : plan d'incident spécifique LLM (prompt injection réussie, fuite via le modèle, hallucination à conséquences). Post-mortem obligatoire sous 48 h.