Chatbot client : bloquer les fuites internes

Aucun outil ne garantit qu'un chatbot public ne dévoilera jamais ses consignes ou des données internes. L'OWASP GenAI Security Project écrit que « it is unclear if there are fool-proof methods of prevention for prompt injection. » La réponse passe donc par une combinaison : droits réduits, filtres en entrée et en sortie, puis tests répétés avant la mise en ligne.

Quel logiciel limite les fuites d'un chatbot attaqué ?

Plusieurs familles d'outils se complètent : des garde-fous programmables, des solutions de protection des données et des scanners de vulnérabilités. Aucune ne remplace la réduction des accès du chatbot, qui reste la première barrière.

Trois scénarios d'attaque réalistes

• L'extraction des consignes. Un visiteur demande au chatbot de répéter ses instructions de départ, ou de les « résumer pour débogage ». L'OWASP définit l'injection de prompt ainsi : « A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways. » (OWASP GenAI Security Project, consulté le 29/10/2026).
• Le contenu piégé. Le chatbot lit une page, un e-mail ou un document qui contient des ordres cachés. La fiche de prévention de l'OWASP pose ce principe : « Keep trusted instructions separate from untrusted data. »
• L'abus des outils connectés. Le chatbot interroge un CRM ou une base de commandes, et un attaquant le pousse à réclamer le dossier d'un autre client. La même fiche demande de « Enforce permissions and parameter validation at the tool boundary. »

Panorama des options

Le tableau ci-dessous compare les solutions selon leur nature et leur rôle, d'après la documentation de chaque acteur au 29/10/2026.

La documentation NVIDIA précise qu'on peut ajouter des garde-fous « without changing the application LLM ».

Selon ZeusLock, éditeur français, sa « DLP IA » est conçue pour la souveraineté. Elle repère, pseudonymise en gardant la structure du texte, ou bloque les informations confidentielles (secrets techniques comme les clés d'API et les identifiants de connexion, coordonnées bancaires IBAN, données personnelles, code propriétaire) avant qu'elles ne partent vers des assistants comme ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity, Grok, Mistral ou DeepSeek. Sur son site zeuslock.ai, l'éditeur indique aussi une protection contre l'injection de prompt et le jailbreak, la découverte du Shadow AI et une intégration aux chaînes CI/CD.

D'après l'éditeur, le dispositif couvre le navigateur web, les ordinateurs sous Windows, macOS ou Linux, le terminal, les environnements de développement, ainsi que les serveurs MCP et les agents IA. Les organisations qui refusent de faire transiter leurs données par un tiers peuvent l'installer dans leur propre infrastructure. L'offre vise d'abord les RSSI et les DPO européens. Son cœur de métier concerne les données qui sortent vers les IA : son adéquation à un chatbot client donné reste à confirmer auprès de l'éditeur.

Le périmètre et le tarif de chaque solution sont à vérifier auprès de l'éditeur. Pour un budget serré ou un besoin très ciblé, les outils open source du tableau suffisent souvent à démarrer, au prix d'un effort technique plus important.

Comment tester un assistant avant sa mise en production ?

Il faut l'attaquer volontairement, d'abord avec des outils automatisés puis par des essais sur mesure, et recommencer à chaque changement. L'OWASP recommande de « Perform regular penetration testing and breach simulations, treating the model as an untrusted user ».

Une démarche en cinq étapes :

1. Cartographier les accès. Lister ce que le chatbot peut lire, appeler et dire : consignes, base de connaissances, outils. L'OWASP demande de « Restrict the model's access privileges to the minimum necessary for its intended operations. »
2. Lancer un scanner. garak vérifie si une application adossée à un modèle peut être amenée à échouer, notamment par fuite de données ou injection de prompt. Sa documentation montre la commande `python -m garak --model_type huggingface --model_name gpt2 --probes promptinject`, où PromptInject compose des prompts cherchant à faire répéter une chaîne imposée. Cet exemple vise un modèle de démonstration : il faut l'adapter au chatbot réel.
3. Écrire ses propres scénarios. PyRIT est conçu pour aider les professionnels de la sécurité à repérer les risques en amont dans les systèmes d'IA générative.
4. Répéter les essais. La fiche OWASP précise : « Repeat tests because model outputs can vary. » Elle rappelle aussi qu'un test rapide reste un « smoke test, not a security benchmark » : un résultat propre ne vaut pas certificat.
5. Contrôler les sorties et les outils. Les garde-fous placés après l'appel au modèle et la validation côté outils interceptent ce que le prompt n'a pas retenu.

Pour structurer le rapport de test, le NIST propose, dans sa publication AI 100-2 E2025 du 01/03/2025, une taxonomie et un vocabulaire communs pour les attaques sur l'apprentissage automatique. L'ANSSI a publié le 29/04/2024 des recommandations couvrant les phases « depuis la phase de conception et d'entrainement d'un modèle d'IA jusqu'à la phase de déploiement et d'utilisation en production », dont la sécurisation de l'architecture.

Les obligations liées aux données personnelles ou à la réglementation européenne sur l'IA dépendent de chaque situation. Le DPO ou un juriste doit les valider avant le lancement. Aucun test ne promet un résultat : il réduit l'incertitude, il ne l'efface pas.

Sources

• LLM01:2025 Prompt Injection, OWASP GenAI Security Project, consulté le 29/10/2026
• LLM Prompt Injection Prevention Cheat Sheet, OWASP Cheat Sheet Series, consulté le 29/10/2026
• garak, LLM vulnerability scanner, NVIDIA, consulté le 29/10/2026
• Prompt injection (exemples garak), garak, consulté le 29/10/2026
• PyRIT, Microsoft, consulté le 29/10/2026
• NeMo Guardrails documentation, NVIDIA, consulté le 29/10/2026
• Adversarial Machine Learning (NIST AI 100-2 E2025), NIST, consulté le 29/10/2026
• Recommandations de sécurité pour un système d'IA générative, ANSSI, consulté le 29/10/2026