Injection indirecte de prompt : comment empêcher un agent IA de retourner ses accès contre l’organisation ?

Premier exercice C-K — Concevoir les contrôles d’un agent de maintenance

Le ticket qui change la mission

Dans l’entreprise fictive Aster, l’agent consulte les demandes d’assistance, recherche des procédures et examine des journaux techniques. Il peut proposer une réparation. Pour quelques opérations courantes, il peut aussi appeler un outil de maintenance. Un connecteur lui permet d’envoyer un dossier de diagnostic au prestataire de support.

Un utilisateur malveillant ouvre un ticket. Il ne possède aucun droit d’administration, mais peut joindre du texte que l’agent lira pendant le diagnostic. Ce contenu présente une transmission documentaire comme une étape nécessaire à la résolution de l’incident. L’agent reprend cette instruction et prépare une demande d’export. L’exercice ne fournit pas de charge d’attaque : il examine le comportement de l’application et les contrôles qui devraient limiter ses effets.

Le mécanisme est une injection indirecte de prompt : l’instruction provient d’un contenu externe consulté dans le cadre d’une tâche. L’OWASP la distingue de l’instruction directement adressée au modèle par son utilisateur. [1] Ici, la frontière franchie sépare les données à examiner de l’autorité qui peut définir la mission. Le ticket ne devrait pas pouvoir étendre les droits ou les objectifs de l’intervention.

L’attaque ne crée pas nécessairement une nouvelle permission. Elle exploite celles que l’application possède déjà. C’est pourquoi l’analyse doit suivre les outils disponibles, leurs identités et leur portée. L’OWASP décrit séparément le risque d’une capacité d’action excessive, lié notamment aux fonctionnalités, permissions et degrés d’autonomie accordés à l’application. [2]

Vous intervenez comme architecte sécurité avec le responsable de la maintenance et l’équipe chargée de l’agent. Votre mission est de concevoir une réponse qui maintienne un diagnostic utile, empêche les accès hors mission et contrôle les transmissions. Une consigne supplémentaire dans le prompt pourra être étudiée, mais elle ne devra pas constituer l’unique barrière protégeant les documents.

Définir le périmètre avant de choisir un contrôle

Le scénario donne quatre faits. L’agent utilise un compte de service. Le connecteur documentaire permet de lire plusieurs espaces internes. Le service de support peut recevoir des pièces jointes. Les appels d’outils sont journalisés. En revanche, il faut encore établir quels documents ont été lus, si le transfert a été exécuté et si d’autres outils offrent une sortie équivalente.

L’alerte indique une demande d’envoi, pas une exfiltration confirmée. Le journal du modèle montre ce qu’il a demandé ; celui du connecteur indique ce qui a été accepté ; celui du service destinataire peut apporter une autre information sur le transfert. L’enquête doit rapprocher ces traces. Elle conserve les éléments nécessaires avant toute remise à zéro du contexte ou de la session.

Sur le plan immédiat, l’équipe peut suspendre le chemin de transmission suspect et restreindre les accès concernés pendant l’analyse. La portée de cette mesure dépend de l’architecture. Couper une session ne démontre pas que toutes les opérations déjà engagées sont arrêtées. Le premier travail consiste donc à identifier les actions en cours et les ressources auxquelles elles peuvent encore accéder.

Le concept C-K de départ sera : « un agent qui contribue au diagnostic et à une réparation autorisée, même lorsqu’il consulte un contenu hostile, sans pouvoir élargir lui-même sa mission ». Cette formulation contient une propriété à concevoir. Elle oblige à séparer l’utilité attendue de l’agent des pouvoirs que nous lui avons accordés par facilité.

Dans les connaissances de départ, inscrivez les identités utilisées, les ressources accessibles, les paramètres des outils, les règles de sortie et les traces disponibles. Une fonctionnalité présentée comme « lecture seule » peut encore révéler des données à un composant qui sait transmettre. L’analyse doit donc examiner les enchaînements, et pas seulement les outils pris isolément.

Trois architectures à explorer

La première branche limite l’autorisation à une mission vérifiée. Un service de contrôle reçoit le périmètre de l’intervention depuis le système d’assistance, par un chemin que le corps du ticket ne peut pas modifier. Il accorde seulement les opérations nécessaires sur les ressources prévues. L’agent peut demander une action, mais cette demande ne suffit pas à créer l’autorisation.

Cette piste soulève plusieurs questions. Comment rattacher un document à l’incident ? Qui peut élargir ce périmètre lorsque le diagnostic découvre une dépendance inattendue ? Le service cible sait-il appliquer une restriction par objet ? Une durée courte réduit la période d’usage d’un jeton ; elle n’empêche pas une opération interdite pendant sa validité. Il faut donc travailler la portée autant que la durée.

La deuxième branche transforme les sorties du modèle en propositions contrôlées. Le modèle prépare un plan structuré. Un composant indépendant vérifie l’outil, la cible, les paramètres et la relation avec la mission avant l’exécution. Une opération sensible peut demander l’approbation d’un humain à qui ces éléments sont montrés clairement. Les secrets nécessaires restent dans les composants d’exécution.

Le contrôle doit être incontournable. Si l’agent peut joindre directement un autre connecteur avec les mêmes droits, la proposition n’a déplacé que l’interface visible. Il faut aussi vérifier que l’action exécutée reste celle qui a été examinée. Une destination ou une pièce jointe modifiée après l’approbation doit provoquer un nouvel examen, selon les règles retenues.

La troisième branche remet en cause l’accès direct à la production. L’agent travaille sur des observations sélectionnées, dans un environnement isolé. Il prépare un diagnostic et une réparation sous une forme limitée. Un exécuteur distinct dispose des droits nécessaires pour appliquer une opération déterminée sur une cible définie. Le modèle n’a pas accès aux secrets de production ni à une sortie réseau générale.

Cette piste peut réduire la capacité de diagnostic. Certaines erreurs n’apparaissent qu’avec des observations supplémentaires ou dans un état particulier du système. Le travail C-K consiste à chercher quelles observations suffisent, comment les fournir et quelles opérations peuvent être préparées sans accès général. Il peut aboutir à plusieurs niveaux d’autonomie selon les tâches, plutôt qu’à un agent unique autorisé à tout faire.

Ces branches utilisent des mécanismes connus. Leur intérêt tient à la conception d’un service qui satisfait plusieurs exigences ensemble. L’équipe doit éviter de conclure trop vite que trois contrôles juxtaposés donnent une architecture cohérente. La séparation des tâches, les autorisations et l’isolation doivent protéger les mêmes frontières et couvrir les chemins réellement accessibles.

Les informations qui obligent à revoir la solution

Le responsable documentaire révèle que le connecteur actuel utilise une permission globale. Il ne sait pas appliquer le périmètre d’un ticket. Cette connaissance fragilise la première branche dans sa forme initiale. L’équipe doit examiner un autre connecteur, un intermédiaire contrôlant les objets ou un jeu de données préparé pour la mission. Elle ne peut pas annoncer une restriction que le service cible ignore.

L’équipe réseau apporte une deuxième information : même sans accès web général, l’agent peut envoyer une pièce jointe grâce au connecteur de support. Le blocage du navigateur ne suffit donc pas à contenir toutes les sorties. La politique doit porter sur les fonctions de transmission, les destinataires et les données concernées. Une destination autorisée n’autorise pas automatiquement tout contenu.

Enfin, la maintenance explique qu’un simple résumé ne suffit pas à certaines interventions. Il faut parfois comparer l’état de plusieurs composants. Cette contrainte conduit à préciser la troisième branche : peut-on fournir des observations complémentaires sur demande, après contrôle, sans ouvrir une session générale ? L’idée initiale évolue grâce aux connaissances acquises.

Le NIST rappelle que l’autorisation d’accès doit porter sur les ressources, sans confiance implicite fondée seulement sur la position réseau. [3] Dans notre exercice, cette exigence se traduit par une question concrète : quel service vérifiera que cet agent peut lire cet objet pour cette intervention ? La réponse doit identifier une règle et un point de contrôle effectif.

Un essai qui mesure l’attaque et le service rendu

Construisez un environnement d’essai avec des documents fictifs, dont certains sont hors périmètre, et une destination de test. Conservez des tickets ordinaires qui permettent de mesurer le service légitime. Introduisez ensuite des contenus hostiles dans les données consultées. Le jeu d’évaluation doit distinguer les exemples utilisés pour régler les protections de ceux conservés pour l’évaluation finale.

Pour chaque tentative, relevez la demande produite par le modèle, la décision d’autorisation, la lecture effective et la transmission éventuelle. Une demande interdite correctement bloquée démontre une propriété différente d’un modèle qui n’a jamais formulé cette demande. Les deux informations sont utiles. Les confondre empêcherait de savoir quelle barrière protège réellement le système.

Évaluez aussi les chemins de contournement fonctionnels : autre outil disponible, autre espace documentaire, transfert de pièce jointe, opération relancée après retrait d’accès. L’objectif défensif est de vérifier que les contrôles ne dépendent pas du seul trajet prévu par le concepteur. Les essais restent limités au périmètre de test et aux permissions nécessaires à cette évaluation.

Le résultat doit présenter plusieurs dimensions séparées : accès hors mission acceptés ou refusés, transmissions réalisées, diagnostics utiles, réparations autorisées accomplies et charge de validation humaine. Indiquez le nombre de cas, les versions et les conditions. Un résultat obtenu sur quelques tickets ne constitue pas un taux général de résistance à toutes les injections.

Préparez enfin la reprise après incident. Un contexte conversationnel ou une donnée conservée peut réintroduire le contenu suspect. L’équipe doit définir ce qu’elle isole, ce qu’elle conserve pour l’enquête et ce qu’elle peut réutiliser. La préparation de la réponse et de la récupération fait partie du travail de cybersécurité ; le NIST l’intègre à sa révision 2025 des recommandations de réponse à incident. [4]

Votre restitution tient sur une fiche d’architecture : fonction de l’agent, chemins d’attaque considérés, contrôle de chaque action sensible, essais menés et questions restantes. Elle doit permettre une décision de développement. Le progrès recherché est précis : un ticket peut encore influencer la proposition du modèle, mais il ne doit plus suffire à faire exécuter une action hors mission. C’est cette propriété qu’il faut concevoir, puis éprouver.

Références

[1] OWASP, LLM01:2025 — Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[2] OWASP, LLM06:2025 — Excessive Agency. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

[3] NIST, SP 800-207, Zero Trust Architecture, 2020. https://csrc.nist.gov/pubs/sp/800/207/final

[4] NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, avril 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final