Un modèle de langage traite des instructions et des données sous forme de texte ou de contenu multimodal. Cette souplesse crée une ambiguïté fondamentale : un document consulté peut contenir une phrase qui ressemble à une instruction. Un agent peut alors interpréter une donnée externe comme une commande, tenter d’accéder à un outil ou révéler des informations.
La prompt injection ne se résout pas par un prompt système plus ferme. Le modèle reste un composant probabiliste. La sécurité consiste à limiter ses pouvoirs, isoler les sources, vérifier les actions et empêcher qu’une erreur d’interprétation produise un impact.
Injection directe et indirecte
Une injection directe est saisie par l’utilisateur dans la conversation pour contourner les règles. Une injection indirecte est cachée dans un email, une page web, un document, une image ou une sortie d’outil que le système consulte.
L’injection indirecte est particulièrement importante pour les agents : le contenu malveillant peut provenir d’une source que l’utilisateur croit légitime. Le modèle ne doit pas lui accorder le même niveau de confiance qu’aux politiques du système.
Les conséquences possibles
Selon les outils et données accessibles, une injection peut provoquer :
- divulgation d’informations du contexte ;
- envoi vers une destination externe ;
- action non autorisée ;
- modification de données ;
- mémorisation d’une instruction persistante ;
- utilisation abusive d’une ressource ;
- réponse trompeuse ;
- contournement d’une validation ;
- saturation ou dépense excessive.
Un chatbot sans outil a un rayon d’impact plus faible qu’un agent capable d’envoyer des emails ou d’exécuter du code. Le risque se mesure par les pouvoirs, pas uniquement par la probabilité d’une mauvaise réponse.
Cartographier les frontières de confiance
Le schéma doit distinguer :
- instructions système et politiques ;
- saisie utilisateur ;
- contenu récupéré ;
- mémoire ;
- sorties de modèles ;
- outils ;
- secrets ;
- services externes ;
- validations humaines.
Chaque flux précise son origine, son niveau de confiance, ses transformations et les actions qu’il peut influencer. Un contenu non fiable ne doit jamais modifier une politique ou une liste d’outils.
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Couches de défense indépendantes limitant les conséquences d’une prompt injection.
Séparer instructions et données
Le système délimite clairement les contenus récupérés et indique au modèle qu’ils ne sont pas des instructions. Cette technique réduit certains risques, mais n’est pas une garantie.
La vraie protection vient de l’architecture : même si le modèle suit une instruction malveillante, il ne possède pas l’accès ou l’autorisation nécessaire pour produire l’impact.
Les sorties d’un modèle sont elles-mêmes non fiables lorsqu’elles alimentent un outil. Elles doivent être validées comme toute entrée externe.
Réduire le contexte
Plus le modèle reçoit de données, plus la surface d’exposition et le risque de fuite augmentent. Le RAG doit récupérer uniquement les passages nécessaires et autorisés. Les secrets ne sont pas ajoutés au contexte par commodité.
La mémoire conserve le minimum et possède une durée. Les conversations de plusieurs utilisateurs ou dossiers sont isolées. Les données anciennes sont relues depuis leur source avant une action.
Concevoir des outils à moindre privilège
Un outil doit :
- accomplir une action précise ;
- vérifier l’identité ;
- valider un schéma strict ;
- limiter la portée ;
- appliquer les règles métier ;
- être idempotent ;
- journaliser ;
- renvoyer un résultat structuré.
Les outils génériques de shell, SQL, navigateur libre ou requête HTTP arbitraire sont interdits par défaut. Lorsque du code doit être exécuté, il l’est dans un environnement isolé, éphémère et sans accès inutile au réseau.
Contrôler les destinations
Les capacités d’envoi, de téléchargement et de publication sont des canaux d’exfiltration. Les destinataires, domaines, buckets, URLs et types de fichiers sont limités par une politique indépendante.
L’agent ne peut pas créer lui-même une destination autorisée. Les nouvelles destinations nécessitent une action administrative distincte.
Protéger les secrets
Les clés ne sont pas présentes dans le prompt ni retournées par les outils. Un service côté serveur effectue l’appel et limite les opérations. Les journaux masquent les secrets et les paramètres sensibles.
Les comptes techniques ont des permissions minimales, une rotation et une surveillance. Une fuite supposée déclenche une révocation rapide.
Valider les sorties structurées
Un appel d’outil doit respecter un schéma : types, valeurs, formats, longueurs et relations. Les champs inconnus sont rejetés. Les valeurs critiques sont recalculées ou relues depuis la source.
Un JSON valide n’est pas nécessairement autorisé. La policy engine vérifie utilisateur, ressource, montant, destination et contexte.
Ajouter des approbations proportionnées
Les actions réversibles et faibles peuvent être exécutées automatiquement. Les actions sensibles sont prévisualisées et confirmées. Les actions à fort impact nécessitent une approbation indépendante.
La validation est liée aux paramètres exacts et expire. Une instruction externe ne peut pas produire une approbation implicite.
Isoler la navigation et le code
Un agent qui consulte le web ou exécute du code doit utiliser une sandbox avec :
- système de fichiers éphémère ;
- réseau limité ;
- durée et ressources bornées ;
- aucune clé générale ;
- téléchargements contrôlés ;
- résultat filtré ;
- journal d’activité.
Les documents actifs, scripts et macros ne sont pas exécutés dans le contexte principal.
Sécuriser la mémoire
Une injection peut demander d’enregistrer une règle pour les conversations futures. Les écritures mémoire sont séparées, limitées et parfois soumises à validation. Chaque élément possède provenance, date, propriétaire et périmètre.
Le système peut distinguer préférences utilisateur, faits vérifiés et résumés générés. Une sortie de modèle ne devient pas une vérité durable sans règle.
Contrôler les connecteurs et MCP
Un serveur d’outils distant est un fournisseur de code et de données. Il doit être inventorié, authentifié, évalué et limité. Les métadonnées d’un outil ne sont pas automatiquement fiables.
Les jetons sont spécifiques au serveur et à l’utilisateur. Les redirections, consentements, changements de capacités et mises à jour sont surveillés. Un serveur ne peut pas demander des secrets destinés à un autre.
Détecter sans dépendre de la détection
Des filtres peuvent repérer certaines formulations, domaines ou comportements. Ils sont utiles pour l’alerte, mais un attaquant peut varier la forme. La politique doit rester sûre même si la détection échoue.
Les anomalies de volume, destination, outil, coût et refus sont surveillées. Un mécanisme de coupure désactive rapidement une capacité.
Tester de manière adversariale
Le red teaming couvre :
- contenu non fiable dans chaque source ;
- tentatives de changement de rôle ;
- demandes de secret ;
- outils en chaîne ;
- données encodées ;
- mémoire ;
- langues et formats ;
- erreurs et timeouts ;
- approbations ;
- destinations.
Les tests doivent être autorisés, isolés et orientés vers les contrôles. Les cas détectés deviennent des régressions automatisées sans conserver de données sensibles.
Préparer l’incident
Le plan prévoit coupure des outils, révocation des jetons, conservation des preuves, analyse des actions, notification et restauration. Le journal relie identité, contenu, modèle, outils, paramètres et résultat.
Une erreur de modèle peut déclencher une action métier ; l’équipe sécurité et l’équipe produit doivent donc partager les procédures.
Accepter le risque résiduel
Aucune combinaison ne garantit qu’un modèle ne suivra jamais une instruction. L’objectif est que cette erreur ne permette pas une action interdite ou une fuite significative.
Certaines capacités restent trop risquées et doivent être exclues, limitées à une proposition ou réservées à un environnement isolé.
La sécurité vient des frontières
Un système sûr considère le modèle comme un interpréteur non fiable, utile mais limité. Les politiques, droits, validations et outils restent déterministes et auditables.
Partitech peut réaliser le threat modeling, concevoir les contrôles, sécuriser les connecteurs et mettre en place les tests d’agents et de RAG. La défense en profondeur protège le système même lorsque le modèle se trompe.
Parlons de votre projet
Auditer la sécurité de votre RAG ou de vos agents avec Partitech. Contactez Partitech.