Ce qu’il faut retenir
- Un document retrouvé peut contenir des consignes qui tentent de détourner la réponse ou les actions d’un assistant.
- La recherche RAG ne neutralise pas cette attaque. La défense doit limiter les capacités et contrôler les effets hors du modèle.
- Une recette utile mesure ce qui a été divulgué ou exécuté, y compris lorsque la réponse affichée semble normale.
Références vérifiées le 1er octobre 2026. Les tests présentés sont des scénarios de défense, sans garantie d’élimination de l’attaque.
Une équipe ouvre ses documents à un assistant de recherche. Parmi les passages remontés, un fichier contient une consigne qui se présente comme une règle de service : envoyer certains éléments à une adresse externe, ignorer les références habituelles ou favoriser une recommandation. Le fichier n’est pas un utilisateur autorisé. Il entre pourtant dans le contexte qui influence la génération.
L’entrée est une donnée, mais le modèle peut y lire une consigne
Une injection directe est portée par la demande adressée au modèle. Une injection indirecte arrive par un contenu externe : fichier, page, courriel ou résultat d’outil. Le référentiel OWASP sur l’injection de prompts distingue ces formes et rappelle que les approches documentaires ne suppriment pas le problème. La confiance accordée à la source par un humain ne se traduit pas automatiquement en frontière d’exécution.
Le contenu peut être évident, masqué dans une partie moins visible ou intégré à une image lue par un composant multimodal. Il peut aussi se présenter comme une procédure légitime. Bloquer une formule connue réduit certains cas sans fournir une règle complète. Les variantes linguistiques et le contexte rendent la simple liste de mots fragile.
Le défaut le plus visible est une réponse modifiée. Le plus coûteux peut se situer ailleurs : un appel réseau, une exportation, une modification de fiche ou une fuite dans les traces. L’article sur la cybersécurité des agents IA donne ce cadre plus large. La surface d’attaque dépend surtout des capacités accessibles au système.
Séparer le contenu et l’autorisation
Identifier les passages retrouvés comme des données non fiables aide le modèle à conserver son rôle. Cette séparation doit être accompagnée de contrôles applicatifs. Le document ne peut pas choisir les destinations autorisées, les privilèges d’un outil ou l’identité de l’utilisateur. Ces décisions appartiennent à du code et à des politiques gérées hors du texte généré.
Un assistant de consultation peut être limité à la lecture. S’il n’a aucun outil d’envoi, une tentative d’exfiltration par cet outil ne pourra pas l’exécuter. Cela ne protège pas contre toutes les fuites : une réponse contenant un secret peut encore être vue par un utilisateur non autorisé, et un lien généré peut transporter des informations si l’interface le charge automatiquement.
Les connecteurs MCP facilitent l’exposition d’outils mais exigent une politique par opération. Une connexion autorisée à un service n’autorise pas tous les objets ni toutes les actions de ce service. La validation doit porter sur l’identité, la ressource, les paramètres et l’effet demandé, à chaque appel.
La sortie peut elle aussi franchir une frontière
Le texte généré ne doit pas devenir du HTML ou une commande de confiance par simple copie. Le rendu contrôle les balises, les liens et les chargements externes. Les objets structurés passent par un schéma, puis par les règles métier. Une adresse syntaxiquement valide n’est pas forcément une destination autorisée.
| Étape | Tentative possible | Contrôle observable |
|---|---|---|
| Ingestion | Pièce ajoutée à un périmètre trop large | Provenance et droits enregistrés |
| Recherche | Passage malveillant remonté avec une bonne pertinence | Origine conservée, accès appliqués |
| Génération | Consigne du document suivie comme autorité | Évaluation adversariale sur la sortie |
| Outil | Export ou modification non autorisés | Validation hors modèle et refus journalisé |
| Affichage | Lien ou média servant de sortie de données | Rendu sûr et politique de chargement externe |
Un document autorisé à la lecture peut néanmoins être malveillant. Un salarié peut déposer un fichier externe dans un espace partagé sans en voir les consignes cachées. Le contrôle de provenance réduit l’incertitude ; il ne remplace pas la limitation des effets. Inversement, une phrase qui ressemble à une instruction peut appartenir légitimement à un manuel : la défense doit rester compatible avec la lecture de procédures.
Construire des tests qui ne se limitent pas au refus verbal
- Nommer les biens à protéger. Données privées, intégrité des réponses, objets métier et disponibilité du service.
- Créer des documents factices. Inclure des tentatives de modification de rôle, de fuite et d’action, sans employer de secrets réels.
- Varier les emplacements. Texte principal, métadonnées, tableaux, résultats d’outils et images si ces canaux sont pris en charge.
- Rejouer des tâches légitimes. Vérifier que la défense n’empêche pas de résumer une procédure qui contient naturellement des verbes impératifs.
- Observer les effets. Consulter les appels d’outils, les destinations réseau et les changements d’état, pas uniquement le texte affiché.
- Conserver les versions. Modèle, index, consignes, outils et règles de rendu doivent être identifiables pour expliquer une régression.
Le résultat distingue tentative détectée, instruction suivie, effet bloqué et effet effectivement réalisé. Un assistant peut suivre une consigne mais rencontrer une interdiction dans l’outil ; la barrière a alors fonctionné, même si la génération reste vulnérable. Dire simplement « attaque empêchée » ferait disparaître une information utile pour la prochaine évolution du produit.
Un RAG qui prépare une réponse de support
Exemple hypothétique. Un service utilise des procédures internes et des courriels clients pour préparer des réponses. Un courriel joint demande à l’assistant de joindre un historique complet à une adresse nouvelle. La tâche autorisée est la rédaction d’un brouillon ; l’envoi n’en fait pas partie. Les outils de lecture limitent les pièces au dossier concerné et aucun outil d’expédition n’est accessible dans cette étape.
Le brouillon doit citer les éléments pertinents et signaler les demandes du client comme demandes, sans leur donner valeur de consigne système. La validation humaine examine contenu et destinataire dans l’application de support. Si un jour un envoi automatique est ajouté, la recette doit être refaite : la limite qui empêchait l’exfiltration par messagerie n’existe plus.
Le test inclut aussi un document qui prétend posséder une autorisation déjà donnée. L’application ne prend pas cette affirmation comme preuve. Une autorisation vient d’un canal et d’une identité vérifiables, avec un périmètre explicite. Le texte d’une pièce ne peut pas reconstituer seul cette chaîne.
Le moindre privilège se vérifie dans les outils
Le référentiel OWASP sur l’autonomie excessive distingue capacités, permissions et autonomie. Pour l’équipe produit, cela conduit à exposer des opérations étroites plutôt qu’un outil universel : lire une pièce autorisée, préparer une modification ciblée, demander une validation. Les secrets des connecteurs restent dans le service d’exécution et ne sont pas insérés dans le contexte.
Limiter nombre d’appels, volume exportable et durée d’exécution réduit également le coût d’une boucle induite. Les plafonds doivent être observables et accompagnés d’un état final compréhensible. Un agent arrêté doit indiquer ce qui a déjà eu lieu, afin que l’opérateur n’exécute pas une seconde fois une action partiellement accomplie.
Le temps de ces contrôles appartient au coût complet d’une chaîne IA. Une démonstration sans autorisation, observabilité et procédure d’arrêt peut sembler plus rapide ; elle ne mesure pas le processus que l’entreprise devra réellement exploiter.
Des défenses cumulées, avec des défauts résiduels
Ni une consigne renforcée, ni un détecteur, ni une liste de contenus interdits ne permet d’affirmer que toutes les injections sont éliminées. Les tests représentent un ensemble d’attaques et de tâches, pas l’ensemble des entrées possibles. La limitation des actions réduit l’impact lorsque la génération échoue, mais une information fausse peut encore affecter une décision humaine.
Avant d’élargir les outils, relire les effets désormais possibles et les tests qui les couvrent. Chaque nouvelle capacité doit avoir son contrôle hors modèle, son journal de résultat et son circuit de recours. L’objectif pratique est de rendre les détournements moins puissants et leurs effets plus faciles à repérer, corriger et contenir.
Sources et références
Sources primaires consultées le 1er octobre 2026 : OWASP, Prompt Injection ; OWASP, Excessive Agency. Les scénarios et le protocole sont des propositions de défense ; ils ne décrivent pas un audit réalisé.
