Les grands modèles de langage sont désormais intégrés au support client, à la recherche interne, aux assistants de programmation et aux agents autonomes. Chacun de ces déploiements ajoute une surface d’attaque pour laquelle la sécurité applicative traditionnelle n’a pas été conçue. Le point essentiel à comprendre : un LLM ne sait pas distinguer de manière fiable vos instructions de celles dissimulées dans le contenu qu’il traite.
C’est l’essence même de l’injection de prompt, classée au premier rang de l’OWASP Top 10 for LLM Applications. Comme aucun modèle actuel n’y est immunisé, la bonne question n’est pas « comment bloquer toutes les injections ? », mais « que peut réellement accomplir une instruction injectée dans notre système ? »
1. Cartographier ce que le modèle peut voir et faire
Commencez par un inventaire : quelles sources de données le modèle peut-il lire, quels outils peut-il appeler, avec quelles permissions et pour le compte de qui ? Tracez le flux de données et repérez chaque point où un contenu non fiable (saisies utilisateur, documents téléversés, e-mails, pages web, sorties d’outils) entre dans la fenêtre de contexte. Chacun de ces points est une porte d’entrée pour une injection.
2. Appliquer le moindre privilège au modèle, pas seulement aux utilisateurs
Traitez le LLM comme un composant non fiable. Accordez-lui les permissions les plus restreintes possibles, limitées aux droits propres de l’utilisateur courant. Un assistant de support n’a pas besoin d’un accès en écriture au CRM ; une fonction de synthèse n’a pas besoin d’accéder à Internet. Si un outil peut modifier des données, transférer de l’argent ou envoyer des messages, il mérite le même examen qu’une API publique.
3. Appliquer le contrôle d’accès dès la recherche documentaire
Les systèmes de génération augmentée par récupération (RAG) laissent fréquemment fuiter des données, car les documents sont indexés sans leurs permissions d’origine. Filtrez les résultats de recherche selon les droits d’accès de l’utilisateur à l’origine de la requête avant qu’ils n’atteignent le modèle. Ne comptez jamais sur le prompt pour « ne répondre qu’avec les documents que l’utilisateur est autorisé à consulter ».
4. Garder l’humain dans la boucle pour les actions lourdes de conséquences
Pour les actions ayant un impact réel, comme l’envoi d’e-mails, l’exécution de code, la modification d’enregistrements ou les paiements, exigez une confirmation explicite de l’utilisateur, qui montre précisément ce qui va se passer. Concevez ces confirmations de sorte que le texte généré par le modèle ne puisse pas les contourner.
5. Encadrer les sorties
Traitez la sortie du modèle comme une entrée non fiable pour le système suivant. Encodez-la avant affichage pour prévenir le cross-site scripting, validez les sorties structurées au regard d’un schéma et bloquez les images ou les liens pointant vers des domaines inconnus, un canal courant d’exfiltration de données.
6. Superposer les garde-fous, sans s’en remettre uniquement à eux
Les classifieurs d’entrée et de sortie, le durcissement du prompt système et les filtres de contenu augmentent le coût des attaques et éliminent une bonne partie du bruit. Ils sont utiles, mais probabilistes. C’est l’architecture (permissions, isolation et confirmation) qui limite l’impact lorsque les garde-fous échouent.
7. Journaliser, surveiller et tester en continu
Journalisez les prompts, le contexte récupéré, les appels d’outils et les réponses, avec des mesures de confidentialité appropriées, afin de pouvoir enquêter sur les incidents. Ajoutez des cas de test adverses à votre suite d’évaluation et exécutez-les à chaque changement de modèle, de prompt ou d’outil. De nouvelles techniques de jailbreak apparaissent sans cesse ; vos tests doivent évoluer avec elles.
Liste de contrôle express
- Chaque entrée non fiable du modèle est identifiée et documentée.
- Les outils s’exécutent avec les permissions de l’utilisateur, jamais avec un compte superutilisateur partagé.
- La recherche documentaire applique un contrôle d’accès au niveau de chaque document.
- Les actions lourdes de conséquences nécessitent une confirmation humaine.
- Les sorties sont encodées, validées et débarrassées des liens non fiables.
- Les évaluations de sécurité s’exécutent automatiquement avant chaque mise en production.
Si vous vous apprêtez à lancer une fonctionnalité LLM ou un agent IA, un test de sécurité IA indépendant est le moyen le plus rapide de savoir comment ces contrôles résistent à un attaquant déterminé.