Injection indirecte d’instructions : comment empêcher qu’un document, un e-mail ou une page web transforme un assistant connecté en canal de fuite ou d’action indue

La menace : des données qui cherchent à se comporter comme des ordres

Une injection indirecte d’instructions survient lorsqu’un assistant intègre du contenu provenant d’une source qu’il ne contrôle pas — par exemple un e-mail, un PDF, une page web, un ticket ou le résultat d’un outil — et que ce contenu tente de modifier son comportement. Le texte hostile peut demander d’ignorer des restrictions, de rechercher des secrets, de transférer des informations, de modifier le destinataire d’une action ou d’utiliser un outil autre que celui qui est nécessaire. Le vecteur est indirect, car l’attaquant n’a pas besoin d’écrire dans la zone de conversation : il lui suffit d’amener le système à lire la ressource manipulée.

Ce phénomène n’est pas une hallucination. Une hallucination est une réponse incorrecte ou non étayée ; l’injection vise à faire suivre au système une instruction qui ne devrait pas faire autorité. Elle ne se réduit pas non plus à une demande maladroitement formulée par un utilisateur légitime. La question centrale est celle de la provenance et du privilège : qui peut fixer l’objectif de la tâche, autoriser une capacité et déterminer quelles informations peuvent sortir de l’environnement.

Le risque augmente lorsque l’assistant combine recherche documentaire, navigation, e-mail et outils produisant des effets externes. Un assistant purement informatif peut fournir une réponse déviée ; un assistant connecté peut en outre envoyer un message, consulter des données hors du périmètre prévu, modifier un enregistrement ou transmettre des informations vers une destination non autorisée. La publication du NIST classe l’injection indirecte parmi les attaques par injection et décrit des scénarios de détournement d’agents, de fuite de données et de contenu malveillant dans des ressources telles que des documents ou des systèmes de récupération.

La défense ne doit pas reposer sur la détection d’une liste de formulations suspectes. Un attaquant peut reformuler, fragmenter, masquer ou obfusquer des instructions. Plus fondamentalement, même une détection parfaite de certains motifs ne résoudrait pas le problème de conception : aucun contenu non fiable ne devrait pouvoir acquérir l’autorité de modifier l’objectif, d’étendre des autorisations, de choisir une destination externe ou de changer une politique de divulgation.

Cartographie des frontières : séparer contrôle, données, capacités et effets

Avant de sélectionner un modèle ou un filtre, représentez le parcours complet d’une tâche. Distinguez les instructions de contrôle définies par l’organisation, la demande explicite de l’utilisateur, les données qu’il fournit, le contenu obtenu de sources internes ou externes, les descriptions d’outils, les secrets et les actions qui produisent des effets. Ces catégories peuvent coexister dans une même conversation, mais elles ne doivent pas être confondues au moment de décider ce que le système peut faire.

Les instructions de contrôle comprennent la politique de sécurité, le but du flux, les exigences d’autorisation et les restrictions de sortie. La demande de l’utilisateur peut préciser une tâche dans ces limites. Les documents, e-mails, pages et résultats d’outils sont des éléments de preuve ou de contexte : ils peuvent influencer une réponse factuelle, mais ne peuvent pas décider que le système doit exporter des données, modifier des droits ou contacter une personne. Une séparation conceptuelle explicite aide la conception, les journaux et les tests à appliquer des règles différentes à chaque élément.

Il est également utile de séparer le plan de l’exécution. Le modèle peut proposer une action, mais un composant de politique indépendant doit vérifier si l’outil est autorisé, quelle identité sera employée, quels arguments sont valides, vers quelle destination l’opération se dirige et si une revue humaine est nécessaire. Traiter un appel d’outil comme une proposition vérifiable, plutôt que comme un ordre exécutable, réduit la dépendance à une interprétation toujours correcte de la hiérarchie par le modèle.

Cette frontière est particulièrement importante pour les résultats d’outils. Une recherche, une API de tickets ou une boîte de réception peuvent renvoyer du texte contrôlé par des tiers. Si l’assistant réinsère ce texte comme s’il s’agissait d’un ordre de haut niveau, le résultat de l’outil devient une voie d’escalade. Le travail consacré à la hiérarchie des instructions analyse précisément l’absence de privilèges entre instructions comme une cause des attaques par injection.

Inventaire des surfaces et des relations de confiance

L’inventaire doit couvrir toute entrée susceptible d’atteindre le contexte pendant une tâche, pas seulement la base documentaire principale. Incluez les pièces jointes, corps et signatures d’e-mails, invitations de calendrier, commentaires, tickets, transcriptions, résultats de recherche, pages consultées, dépôts, bases vectorielles, mémoires conversationnelles et texte renvoyé par des connecteurs. Notez également si le contenu provient d’un utilisateur, d’un système interne, d’un tiers, d’une source publique ou d’une origine inconnue.

La provenance ne rend pas automatiquement une source interne fiable pour donner des instructions. Un ticket interne peut contenir du texte saisi par un client ; un wiki peut être modifié par de nombreuses personnes ; une mémoire peut avoir conservé une instruction malveillante provenant d’une session antérieure. L’étiquette doit refléter à la fois le système d’origine, le niveau de contrôle éditorial, le propriétaire, la date de récupération et la méthode par laquelle le contenu a été intégré au contexte.

Rendez visibles les déplacements de données entre zones. Par exemple, un agent de messagerie peut lire un message externe, interroger un index interne pour le contextualiser et proposer une réponse au moyen d’un service d’envoi. Ce parcours comporte au moins trois décisions distinctes : quel texte est montré au modèle, quelles données internes sont consultées et quelles informations sont envoyées à l’extérieur. Chaque décision nécessite ses propres restrictions ; une autorisation ne doit pas être héritée d’une étape à l’autre au seul motif qu’elles partagent une conversation.

La documentation de Microsoft considère les e-mails, documents, pages web et extensions comme des vecteurs d’injection indirecte et propose des contrôles de flux d’information pour distinguer contenu et confiance. Cette orientation est utile, mais son adaptation concrète dépend des identités disponibles, des connecteurs déployés et de la sensibilité des données de chaque organisation.

Règle d’architecture : les données n’accordent pas de capacités

Une politique opérationnelle peut être formulée simplement : un fragment non fiable peut être cité, résumé, comparé ou utilisé comme élément de preuve, mais il ne peut ni redéfinir l’objectif autorisé ni activer à lui seul une capacité. Cela impose que les décisions relatives aux outils reposent sur la combinaison de l’intention authentifiée de l’utilisateur, de la politique du flux et des autorisations de l’identité qui exécute l’action. Le contenu récupéré ne peut apporter des paramètres que lorsqu’ils franchissent une validation indépendante.

Appliquez le moindre privilège par tâche. Un assistant qui résume des documents n’a pas besoin d’identifiants permettant d’envoyer des e-mails. Un brouillon de réponse n’a pas besoin du droit de l’envoyer. Un outil qui consulte un enregistrement ne devrait pas réutiliser un identifiant capable de le modifier. Lorsque la plateforme le permet, utilisez des jetons de courte durée, limités à une opération et émis après vérification de la politique. La séparation des identifiants réduit les conséquences si le modèle propose une action inappropriée.

Limitez aussi l’exposition des données. Ne récupérez que les fragments nécessaires, réduisez la quantité de contexte et retirez les champs sensibles qui ne contribuent pas à la tâche. Si une requête exige des données internes et qu’une réponse ultérieure est destinée à l’extérieur de l’organisation, introduisez une porte de sortie qui évalue la classification de l’information, le domaine de destination, la finalité déclarée et l’autorisation applicable. Ne laissez pas un document suggérer le domaine ou la boîte aux lettres auxquels des données doivent être envoyées.

Les listes de destinations autorisées peuvent convenir à des intégrations à haut risque, même si elles exigent une maintenance et ne remplacent pas la vérification du contenu. Dans les flux variables, une politique de destination peut combiner des relations organisationnelles vérifiées, des règles de classification et une confirmation humaine. L’objectif est que le destinataire provienne d’une source d’autorité — par exemple un registre client ou une sélection explicite de l’utilisateur — et non d’une phrase insérée dans une pièce jointe.

Contrôles par couche et limites des contrôles apparents

L’étiquetage de provenance doit accompagner le contenu jusqu’à la génération et à l’exécution. Il ne suffit pas d’ajouter un avertissement textuel au contexte, car cet avertissement peut se perdre au cours de transformations ultérieures. Utilisez des structures de données qui préservent l’origine, la confiance, la classification et le lien avec la tâche. Délimitez simultanément les champs de ces structures que le modèle peut lire et ceux utilisés exclusivement par le moteur de politiques.

La validation des appels d’outils requiert des règles sémantiques et structurelles. Vérifiez que l’outil est autorisé pour la tâche, que ses arguments respectent un schéma, que les identifiants sont résolus à partir de registres autorisés et que l’effet demandé correspond au plan approuvé. Pour les opérations d’écriture, validez les préconditions et appliquez l’idempotence lorsque cela est possible. Pour les actions irréversibles ou de grande portée, affichez un aperçu avant l’exécution.

L’approbation humaine n’est efficace que si la personne peut décider avec des informations suffisantes. L’interface devrait montrer l’action proposée, la destination finale résolue, les données qui sortiront, la source des paramètres pertinents, l’effet attendu et son caractère réversible ou non. Une approbation qui ne présente qu’un bouton générique de confirmation peut transférer le risque à la personne sans lui donner de réelle capacité de détecter la manipulation.

Demander au modèle d’ignorer les instructions présentes dans des documents peut faire partie d’une défense en profondeur, mais ce n’est pas une frontière de sécurité. Un unique prompt système, le blocage de mots ou la confiance dans le fait que le RAG récupère des sources réputées ne suffisent pas davantage. OWASP indique que le RAG et l’ajustement fin n’éliminent pas à eux seuls le risque d’injection ; ses recommandations comprennent la séparation des instructions et des données, le moindre privilège, la validation des outils, la supervision et les tests. Ces contrôles réduisent le risque, mais ne permettent pas de promettre une détection complète du contenu hostile.

Concevoir une batterie de tests adversariaux, pas seulement des tests de qualité

Les tests doivent démontrer des propriétés observables : qu’un document ne peut pas étendre le périmètre de données ; qu’un e-mail ne peut pas changer un destinataire ; qu’une page ne peut pas initier un appel d’outil non justifié ; et qu’une instruction dans les résultats d’une API ne peut pas persister comme préférence ou mémoire. Définissez chaque cas avec une demande légitime, une entrée adverse, les capacités disponibles, le comportement attendu et les événements qui doivent être consignés.

La couverture des variantes importe davantage que la répétition littérale de la même attaque. Incluez des instructions directes, fragmentées, encodées, dissimulées dans des métadonnées si votre extracteur les traite, formulées comme des traductions ou des résumés et réparties entre plusieurs sources. Testez aussi les conflits : un document peut demander une action tandis qu’un autre la contredit, ou un résultat de recherche peut tenter de faire oublier au modèle son objectif initial. Le critère n’est pas que le système classe tout texte malveillant, mais qu’il conserve les interdictions de capacité même si le texte est interprété.

Mesurez séparément la détection, le blocage et le confinement. La détection identifie du contenu suspect ; le blocage empêche une action non autorisée ; le confinement limite les données et les privilèges si la détection échoue. Consignez les faux blocages qui interrompent des tâches légitimes, car une politique trop large peut pousser les utilisateurs vers des canaux alternatifs. Révisez les tests à chaque changement de modèle, de connecteur, de modèle d’orchestration, d’autorisation ou d’outil.

Le jeu de données LLMail-Inject étudie des tentatives adaptatives contre un assistant de messagerie doté d’outils. Il peut servir de référence pour définir des évaluations des flux d’e-mail, mais il ne démontre pas à lui seul la résistance d’une autre architecture, d’un autre modèle ou d’un environnement doté d’autorisations différentes. Complétez tout corpus externe par des scénarios tirés de vos connecteurs, données et opérations réels.

Observabilité et réponse aux incidents

Un journal utile permet de reconstruire le flux sans conserver davantage de contenu sensible que nécessaire. Il doit relier la demande authentifiée, la version de la politique, les identifiants et étiquettes des fragments récupérés, le plan proposé, les outils candidats, les arguments normalisés, les décisions d’autorisation, les approbations et le résultat. Selon la sensibilité, stockez des empreintes, des références contrôlées ou des copies chiffrées à accès restreint plutôt que de répliquer librement des documents complets.

Définissez des signaux d’alerte : écart entre l’objectif initial et une action proposée, demande d’outils indisponibles pour la tâche, changement de destinataire, tentative d’accès à des champs non récupérés, chaînes inhabituelles d’outils et sorties vers de nouvelles destinations. Les signaux ne remplacent pas la politique préventive, mais ils aident à prioriser les revues et à découvrir des chemins imprévus. La surveillance des dérives de plan et des chaînes d’outils rejoint l’approche de défense décrite par Microsoft.

Face à un incident, commencez par contenir le flux : désactivez temporairement l’outil ou le connecteur concerné, révoquez les jetons ou sessions lorsque cela est approprié et préservez les journaux. Déterminez ensuite la portée : quel contenu a été lu, quels outils ont été proposés et exécutés, quelles données sont sorties, avec quelle identité et vers quelles destinations. L’enquête doit distinguer une proposition bloquée d’une action effectivement menée à terme.

La remédiation comprend la correction de la règle qui a permis le transit, la révision des privilèges et l’ajout d’une régression reproduisant le cas. S’il y a eu sortie de données, activez les processus de réponse et de notification applicables à la classification et à la juridiction concernées. N’attribuez pas automatiquement une fuite à une injection indirecte : confirmez la chaîne causale à l’aide des traces, car des erreurs de configuration, des autorisations excessives ou des automatisations indépendantes peuvent produire des effets semblables.

Matrice de décision par cas d’usage et critères de déploiement

La même politique générale prend des formes différentes selon le cas d’usage. Un assistant documentaire exige une séparation forte entre éléments de preuve et instructions, mais ne produit peut-être aucun effet externe. Un agent de messagerie ajoute le risque lié aux destinataires et aux pièces jointes. Un navigateur doté d’outils incorpore du contenu évolutif provenant de multiples origines. Une automatisation interne peut agir sur des systèmes critiques même lorsque ses sources semblent internes. Ajustez les contrôles à l’impact des actions, et pas seulement à la probabilité de rencontrer un texte hostile.

Avant d’ouvrir un flux aux utilisateurs, exigez des tests consignés montrant que le contenu non fiable ne modifie ni l’objectif, ni les autorisations, ni les destinataires, ni les outils autorisés. Vérifiez aussi que l’identité d’exécution possède les privilèges minimaux et que les opérations à fort impact disposent d’un aperçu ou d’une porte d’approbation. Si vous ne pouvez pas démontrer ces propriétés, limitez le flux à la lecture, réduisez les connecteurs ou maintenez l’action manuelle.

Ce guide complète le guide du RAG avec sources et le guide des agents avec outils de l’index sécurité. Le premier aide à évaluer les éléments de preuve qui étayent une réponse ; le second traite plus largement des autorisations et de la récupération. La question spécifique ici est différente : même si l’assistant a récupéré un contenu pertinent et dispose d’un outil autorisé, quel mécanisme empêche ce contenu de devenir une autorité ordonnant une action ?

Il n’existe pas de garantie générale qu’un modèle reconnaîtra toute injection indirecte. Le seuil raisonnable n’est donc pas de revendiquer l’invulnérabilité, mais de démontrer des défenses en couches, de limiter les dommages si la détection échoue et de maintenir des tests de régression pour les flux réellement déployés.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.