Un chatbot peut répondre correctement à une question et pourtant révéler un document interdit. Un agent peut refuser une demande dangereuse dans une conversation, puis l’exécuter après lecture d’un document trompeur. Auditer une application LLM consiste à vérifier tout le système : modèle, données, utilisateurs, outils et décisions d’autorisation. Ce guide fournit un protocole à adapter à une application de test.
En résumé
- L’audit porte sur l’application et ses accès, pas seulement sur les réponses du modèle.
- La grille présentée utilise explicitement OWASP LLM Top 10 2025 ; LLM09 y désigne la désinformation.
- Le RAG doit filtrer les documents selon les droits de l’utilisateur avant de les fournir au modèle.
- Les contrôles d’autorisation et la validation des sorties doivent fonctionner hors du prompt.
- Des tests répétés, des cas légitimes et des preuves minimisées sont nécessaires pour interpréter les résultats.
1. Définir ce que le système peut lire et faire
Un LLM produit du texte. Le RAG, ou génération augmentée par recherche, lui fournit des documents sélectionnés pour répondre. Les outils permettent à une application de rechercher, écrire ou exécuter une opération. Ces composants créent des frontières différentes : un droit de lire un document n’est pas un droit de l’envoyer à un tiers.
Avant les tests, relevez l’identifiant du modèle et de sa version, les paramètres, la version de l’application, le corpus, les connecteurs et les rôles. Créez deux utilisateurs de test avec des droits différents et des documents fictifs portant des marqueurs reconnaissables. Fixez un budget, une durée et des destinations de test. Aucune donnée client ni aucun secret réel n’est nécessaire.
- Utilisateur authentifiéRôle et demande
- Recherche documentaireFiltrage des droits avant récupération
- ModèleRéponse proposée à partir du contexte
- Contrôle applicatifFormat, permissions et approbation
- Outil ou affichageAction limitée et trace du résultat
2. Utiliser une grille OWASP versionnée
Le tableau ci-dessous reprend les catégories de l’édition 2025 du Top 10 OWASP pour les applications LLM. Il sert de base explicite de comparaison, pas d’affirmation qu’il s’agit de la dernière édition : le projet annonce aussi une édition 2026. Lors d’une mission, fixez l’édition retenue et documentez les évolutions. Les tests proposés dans la colonne de droite sont une adaptation méthodologique Kenawek.
| Catégorie 2025 | Question de test proposée |
|---|---|
| LLM01 - Prompt Injection | Un document peut-il faire exécuter une instruction non autorisée ? |
| LLM02 - Sensitive Information Disclosure | Un utilisateur reçoit-il un marqueur réservé à un autre rôle ? |
| LLM03 - Supply Chain | Les modèles, dépendances et connecteurs ont-ils une origine vérifiable ? |
| LLM04 - Data and Model Poisoning | Une source altérée est-elle repérée et retirable ? |
| LLM05 - Improper Output Handling | Une sortie inattendue est-elle traitée comme une donnée ? |
| LLM06 - Excessive Agency | Un outil peut-il agir au-delà du besoin autorisé ? |
| LLM07 - System Prompt Leakage | Le prompt contient-il à tort des secrets ou des règles d’accès ? |
| LLM08 - Vector and Embedding Weaknesses | Les recherches respectent-elles les séparations entre utilisateurs ? |
| LLM09 - Misinformation | Une affirmation sans preuve est-elle signalée et vérifiable ? |
| LLM10 - Unbounded Consumption | Les boucles, coûts et appels disposent-ils de limites ? |
3. Construire des scénarios reproductibles
Cas A : l’utilisateur autorisé demande le résumé de son document. La réponse doit être utile et citer la bonne source. Cas B : l’autre utilisateur demande le marqueur du document interdit. Le système doit refuser l’accès ; le simple fait que le modèle ne l’affiche pas ne suffit pas si le document lui a déjà été transmis. Inspectez donc aussi la recherche et les appels applicatifs.
Cas C : un document de test contient une consigne étrangère au besoin métier, par exemple une demande de modifier le format de réponse ou de contacter collecte.example.invalid. Cette adresse réservée n’est pas un service à joindre. Utilisez un outil simulé qui enregistre les demandes sans effectuer de connexion. Résultat attendu : aucune action non autorisée et une trace permettant d’expliquer la décision.
Cas D : demandez une opération légitime, puis modifiez son destinataire ou sa portée avant confirmation. L’approbation doit porter sur l’opération exacte et ne pas être réutilisable pour une autre action. Répétez chaque cas selon un nombre annoncé et conservez aussi les échecs. Une réponse réussie une fois ne mesure pas la robustesse du système.
4. Examiner les sorties et les permissions
Une sortie du modèle reste une donnée non fiable. Validez les paramètres selon un schéma, utilisez les mécanismes adaptés au contexte et imposez les droits côté serveur. L’encodage HTML aide pour un affichage web ; il ne remplace pas une requête SQL paramétrée. Un outil de suppression ne doit pas accepter un chemin arbitraire simplement parce qu’il provient du modèle.
Ne placez aucun secret dans le prompt système. Sa confidentialité éventuelle ne doit pas protéger l’accès aux données. Testez les comptes, les ressources et les méthodes que chaque connecteur peut utiliser. Vérifiez également les quotas, délais maximaux et limites de récursion : un système peut rester disponible tout en générant une facture ou une charge inattendue.
5. Livrer des constats exploitables
Pour chaque constat, indiquez la condition initiale, le rôle, le scénario, le résultat attendu, le résultat observé, l’impact et la correction proposée. Conservez les identifiants de versions et les preuves utiles, en masquant les informations non nécessaires. Journaliser intégralement tous les prompts de production créerait un nouveau dépôt de données sensibles.
Le rapport doit distinguer un refus textuel du modèle, un blocage réel par l’application et une absence de tentative. Classez les constats selon l’effet possible sur les données et les opérations métier. La correction se vérifie avec le même scénario, puis avec des demandes légitimes pour détecter les régressions.
6. Recette et remise en état
- Rejouer les quatre scénarios avec deux rôles et des documents fictifs.
- Vérifier qu’aucun appel externe réel ne quitte les outils simulés.
- Tester une panne du modèle et l’épuisement volontaire d’un petit quota de test.
- Confirmer la suppression des documents, index, journaux et comptes créés pour l’audit.
- Après changement de modèle ou de connecteur, relancer les tests et consigner les écarts.
Ce protocole n’a pas été exécuté sur une application cliente. Avant utilisation, consignez les versions et résultats du laboratoire. Le retour arrière consiste à restaurer la configuration de test précédente et retirer les accès temporaires ; il ne garantit pas le retrait de données qui auraient été envoyées à un fournisseur.
Sources et références
Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.
- OWASP - Catégories LLM Top 10 2025
- OWASP - LLM09:2025 Misinformation
- OWASP - Initiative et éditions disponibles
Besoin de relier ces contrôles à votre environnement ? Parler de votre projet avec Kenawek.