Le modèle
Résistance aux formulations détournées, aux attaques multi-tours, à l’obfuscation et aux tentatives de jailbreak.
AUDIT DE SÉCURITÉ CHATBOT IA
Que vérifie réellement un audit de chatbot ?
Un audit de sécurité de chatbot vérifie si un utilisateur peut modifier son comportement, contourner ses règles, récupérer des informations internes ou atteindre des données auxquelles il ne devrait pas accéder. Le test porte sur l’application complète : instructions système, modèle, historique, base documentaire, contrôles d’accès et logique métier.
Pourquoi un chatbot IA crée-t-il une surface d’attaque particulière ?
Un chatbot fondé sur un grand modèle de langage traite souvent les instructions du développeur et les demandes de l’utilisateur sous une forme proche : du texte. Cette proximité rend possible la prompt injection, c’est-à-dire l’introduction d’instructions conçues pour modifier le comportement prévu de l’application.
Le risque ne dépend pas uniquement du modèle utilisé. Il dépend surtout de ce que l’application place dans son contexte : prompt système, historique de conversation, informations client, données issues d’un CRM, documents récupérés par un système RAG ou règles commerciales. Un chatbot sans accès sensible peut produire une réponse indésirable ; un chatbot connecté à des données métier peut provoquer une fuite ou faciliter un abus.
L’orchestration
Ordre des messages, séparation entre instructions et données, filtrage des entrées et traitement des sorties.
Les données
Historique, mémoire, informations personnelles, contexte RAG, isolation entre utilisateurs et secrets techniques.
La logique métier
Tarifs, conditions d’éligibilité, politiques internes, limites transactionnelles et règles qui ne doivent jamais dépendre du seul LLM.
Les scénarios testés pendant l’audit
1. Prompt injection directe
L’auditeur fournit au chatbot des instructions concurrentes ou contradictoires afin de déterminer si une entrée utilisateur peut prendre le pas sur les consignes légitimes. Les tests évoluent selon les refus observés : reformulation, changement de contexte, séquences multi-tours et variations sémantiques.
2. Jailbreak des mécanismes de sûreté
Le jailbreak vise à obtenir un comportement que le modèle devrait normalement refuser. Il ne doit pas être confondu avec toutes les prompt injections : une injection peut détourner une règle commerciale ou révéler une donnée sans chercher à produire un contenu interdit.
3. Fuite du prompt système
Le test recherche l’extraction textuelle, la reconstruction partielle et l’inférence des règles internes. L’OWASP LLM07 rappelle qu’un prompt système ne doit ni contenir de secret ni servir de contrôle d’autorisation. Sa divulgation devient surtout critique lorsqu’elle révèle une donnée sensible, une permission ou une faiblesse exploitable.
4. Fuite de données et défaut d’isolation
L’audit vérifie si une conversation peut révéler le contexte d’un autre utilisateur, des fragments de documents internes, des informations personnelles ou des données conservées dans une mémoire persistante. Les contrôles d’accès doivent être appliqués avant que les données n’entrent dans le contexte du modèle.
5. Contournement d’une règle métier
Une réponse apparemment anodine peut devenir une vulnérabilité si elle modifie un prix, ignore une condition, fabrique une autorisation ou contourne un parcours prévu. Le constat est retenu lorsque l’effet peut être reproduit et relié à un impact concret.
Ce que contient le rapport
| Élément | Contenu | Utilité |
|---|---|---|
| Preuve | Conversation, entrée utilisée, réponse obtenue et préconditions. | Reproduire le comportement sans ambiguïté. |
| Impact | Donnée exposée, règle contournée, utilisateur affecté ou fonction atteinte. | Prioriser selon le risque métier réel. |
| Cause | Défaut de séparation, permission excessive, contrôle absent ou confiance placée dans le LLM. | Corriger le mécanisme, pas seulement le prompt. |
| Remédiation | Contrôle déterministe, filtrage, isolation, limitation des données ou nouvelle validation. | Donner une action exploitable à l’équipe technique. |
| Retest | Nouvelle exécution du scénario après correction, selon l’offre choisie. | Vérifier que le chemin d’attaque est fermé. |
Quand faut-il auditer un chatbot ?
Un audit est particulièrement pertinent avant une mise en production, après l’ajout d’une base documentaire, lors d’un changement de modèle ou lorsque le chatbot commence à traiter des données client. Il est également utile avant un questionnaire de sécurité, un contrat B2B ou une ouverture à un public plus large.
Pour un chatbot conversationnel simple, Heldguard propose un diagnostic ciblé. Si le système consulte un RAG, conserve une mémoire, traite des données internes ou appelle des API, le périmètre doit être approfondi ou basculer vers un audit de sécurité d’agent IA.
Sources techniques de référence
Votre chatbot est-il dans le périmètre ?
Décrivez le modèle, les données accessibles et les fonctions disponibles. Le premier échange sert à déterminer la profondeur de test nécessaire.