Auditer la sécurité des LLM

Les LLM (Large Language Models) ou modèles de langage de grande taille sont en train de devenir une brique standard des systèmes d’information, mais très peu d’organisations ont déjà intégré ces technologies dans leurs pratiques d’audit technique et de test d’intrusion. Cet article propose une approche orientée audit cyber, pentest et sécurité offensive pour évaluer concrètement les risques liés aux LLM, sans se limiter à une simple relecture théorique du Top 10 OWASP.

1. Pourquoi les LLM bouleversent l’audit technique ?

Les LLM ne ressemblent pas à un « simple » service web : ils combinent un modèle statistique, des données d’entraînement opaques, des prompts complexes, des connecteurs métier et parfois des agents capables d’exécuter des actions. Dans un contexte d’audit cyber, cela signifie que la surface d’attaque couvre à la fois le front, les API, le moteur d’orchestration, le modèle et les pipelines MLOps qui le nourrissent.

Pour une équipe de sécurité ou de pentest, les impacts sont concrets :

• Le test d’intrusion ne peut plus s’arrêter à l’interface : il faut aussi tester la logique de prompt, les sources de connaissances, les outils et les workflows automatisés.
• Les risques classiques (XSS, injections, exfiltration de données) se combinent avec de nouveaux scénarios propres à l’IA générative : poisoning, model theft (ou model extraction) et adversarial attacks.

2. Nouveaux risques et cadres de référence

L’arrivée des LLM impose une réinterprétation des standards de sécurité existants. Les cadres tels que l’OWASP Top 10 for LLM Applications, le NIST AI RMF ou les recommandations de l’ANSSI constituent une base de travail utile, mais insuffisante pour couvrir l’ensemble des risques opérationnels liés à l’orchestration, aux prompts et aux pipelines MLOps.
Un audit LLM efficace doit donc combiner analyse de conformité, tests en boîte grise et simulations d’attaques adversariales pour évaluer la résilience globale du système.

3. Cartographier les surfaces d’attaque avant le test d’intrusion

Avant de lancer un pentest LLM, la première étape est une cartographie précise de l’application et de son écosystème. Sans cette étape, l’audit se limiterait à des tests en surface (ex : simple chatbot) et pourrait passer à côté des vrais enjeux (données, automatisation, intégrations).

Axes clés de la cartographie :

• Flux de données et prompts : quels types de données transitent dans les prompts (clients, RH, SI interne, logs) ? Y a‑t‑il un mécanisme de RAG, et comment sont gérées les sources (droits d’accès, mises à jour, versionning) ?
• Connecteurs et outils : quels systèmes l’agent ou le chatbot peut‑il interroger ou modifier (ERP, CRM, ticketing, référentiels techniques) ? Quelles passerelles d’automatisation (orchestrateurs, webhooks, scripts) sont déclenchées par la sortie du LLM ?
• Pipeline MLOps : comment le modèle est‑il entraîné, ajusté, déployé et versionné ? Qui peut modifier les jeux de données, les prompts système ou les policies ?

Cette cartographie sert de base au périmètre d’audit technique et d’audit cyber : elle permet de définir les composants à cibler, les environnements à tester et les jeux de données à anonymiser.

4. Méthodologie de pentest LLM : trois blocs complémentaires

4.1. Tests orientés modèle et prompts

L’objectif est de vérifier la résistance du système face à des interactions malveillantes ou imprévues côté LLM.

• Attaques sur le contenu du prompt : tentatives de contournement des consignes de sécurité (prompt injection, jailbreak).
• Tests d’exfiltration : pousser le modèle à révéler des informations internes (données d’entraînement, secrets, prompts système, règles internes).
• Tests d’intégrité de la réponse : analyser la capacité du modèle à refuser les sollicitations malveillantes (demande de code d’attaque, contenu illicite).
• Évaluation de l’hallucination dans les cas d’usage critiques (juridique, conformité, finance).

Les résultats documentent la robustesse du système face aux attaques textuelles et aident à définir quand une validation humaine reste indispensable.

4.2. Tests orientés intégration et chaîne d’outils

Cette couche du pentest vise à comprendre comment l’application consomme les sorties du modèle et sécurise les outils exposés.

• Consommation de la sortie du LLM : vérification de la résistance aux injections HTML/JS côté client ou serveur ; analyse des workflows qui exécutent des commandes ou appellent des API en se basant sur les réponses du modèle.
• Plugins, outils et connecteurs : tests de forçage d’appels non autorisés, vérification des contrôles d’accès (authentification, autorisation, validation de paramètres).

Cette phase rapproche le test d’intrusion LLM d’un pentest applicatif avancé, enrichi par la logique probabiliste propre au modèle.

4.3. Tests orientés MLOps et gouvernance

L’audit technique doit enfin couvrir le cycle de vie complet du modèle et des données.

• Empoisonnement et intégrité des données : analyse des sources d’entraînement, du contrôle qualité et de la gestion des accès. Vérification des protections contre les injections de données malveillantes dans les pipelines ou les bases documentaires externes.
• Protection du modèle et des artefacts : contrôle des accès aux poids du modèle, vérification des journaux d’accès, dispositifs anti‑extraction (rate limiting, monitoring des requêtes).

Cette couche étend les pratiques DevSecOps à l’univers MLOps, en intégrant la sécurité dès les opérations d’entraînement et de déploiement.

5. Transformer les résultats d’audit en plan de remédiation

Un audit LLM n’a de valeur que s’il débouche sur un plan d’action clair et hiérarchisé :

• Sécurisation des flux et des données : réduction des données sensibles envoyées au modèle, cloisonnement par périmètre, anonymisation systématique.
• Durcissement des intégrations : filtres et validations sur les entrées/sorties, authentification forte des plugins, contrôle fin des droits et limitation des actions.
• Gouvernance et supervision : intégration des risques LLM dans la cartographie globale, revue régulière des prompts système, modèles et données.

L’objectif : passer d’un audit ponctuel à une boucle continue d’amélioration, en phase avec les pratiques existantes (SOC, gestion de vulnérabilités, revue d’architecture).

6. Vers un programme d’audit LLM récurrent

Avec la généralisation des LLM dans les processus métiers, la question n’est plus « faut‑il auditer ? » mais « à quel rythme et sur quel périmètre ? »
Un programme mature combine :

• Audits et tests d’intrusion réguliers sur les nouvelles implémentations LLM.
• Contrôles intégrés CI/CD et MLOps pour surveiller la dérive, la qualité des données et les nouveaux vecteurs d’attaque.
• Montée en compétence des équipes SOC, GRC et Dev selon les cadres ANSSI et NIST.

Conclusion : sécurisez l’usage de l’IA dans votre structure

Les LLM ne sont plus un sujet expérimental : ils sont désormais au cœur de vos processus métiers et interactions clients.
Un audit cyber ou un test d’intrusion spécialisé IA générative est devenu nécessaire pour éviter compromissions et non‑conformités.

Intrinsec, expert en sécurité offensive depuis 30 ans, vous accompagne pour transformer ces risques en leviers de résilience :

• Audit technique et pentest LLM pour cartographier et prioriser vos vulnérabilités.
• Red Team et Purple Team pour évaluer votre maturité face aux attaques IA avancées.
• Accompagnement stratégique : gouvernance MLOps, intégration SOC, conformité ANSSI et EU AI Act.