Injection de prompt : comment un agent IA se fait pirater

L’injection de prompt consiste à faire passer une instruction malveillante pour une consigne que le modèle doit suivre, notamment en la plaçant dans un document, un e-mail ou une page web qu’il consulte. Un agent IA peut alors abandonner votre objectif, fausser sa réponse ou utiliser ses outils au profit d’un attaquant. Les conséquences dépendent des données auxquelles il accède et des actions que son application autorise.

Le point de rupture : une donnée devient une consigne

Vous demandez à un assistant de résumer un document. Ce document contient des informations utiles, mais aussi un passage lui demandant de modifier sa mission. Si le modèle suit ce passage, le contenu à analyser a pris la place des instructions de travail.

Un modèle reçoit pourtant des messages de rôles différents, avec des priorités définies par l’application. Cette organisation aide à distinguer les consignes des données, mais elle ne constitue pas une frontière de sécurité infaillible. Le sens d’un texte externe peut influencer la décision du modèle, même quand ce texte arrive comme résultat d’outil.

Les travaux de Kai Greshake et de ses coauteurs, déposés le 23 février 2023, ont montré comment des instructions placées dans des données récupérées peuvent détourner des applications intégrant un modèle de langage. Leur publication sur l’injection indirecte décrit notamment la manipulation des réponses et des interactions avec les outils.

L’attaquant n’a donc pas forcément besoin de votre mot de passe ni d’un accès au serveur. Il peut chercher à contrôler un contenu que l’agent rencontrera pendant une tâche légitime. La différence entre agent IA et chatbot devient décisive : une réponse détournée peut se transformer en action lorsque des outils sont disponibles.

Injection directe et indirecte : deux portes d’entrée

La distinction porte sur le chemin emprunté par l’instruction. Dans une injection directe, elle arrive par l’interface de conversation. Dans une injection indirecte, elle vient d’une source que l’assistant consulte pour accomplir votre demande.

Critère	Injection directe	Injection indirecte
Point d’entrée	Message envoyé à l’assistant	Document, page, e-mail ou résultat d’outil
Contrôle de l’attaquant	Texte de sa demande	Une partie du contenu consulté
Situation de l’utilisateur légitime	Il peut être distinct de l’attaquant	Il déclenche souvent une tâche ordinaire
Frontière attaquée	Règles de l’application face à une demande	Instructions de travail face aux données externes

L’OWASP distingue ces formes d’injection et rappelle que leurs effets dépendent des capacités accordées au système. Une tentative ne réussit pas automatiquement : le modèle peut l’ignorer, un contrôle peut bloquer l’action, ou l’outil demandé peut être inaccessible.

Le jailbreak vise plus précisément à contourner les restrictions de comportement ou de sécurité du modèle. Il peut recouper l’injection de prompt, sans décrire tous ses objectifs : fausser discrètement un résumé commercial ne nécessite pas forcément de lui faire produire un contenu interdit.

Une hallucination, elle, peut survenir sans intervention adverse. Une réponse erronée ne prouve donc pas une attaque. Pour établir une injection, il faut rechercher le contenu qui a tenté de détourner le comportement et examiner son influence sur la suite.

Un e-mail piégé peut détourner une tâche légitime

Prenons un scénario fictif : vous demandez à un agent de lire les demandes reçues et de préparer les réponses. Un expéditeur malveillant ajoute à son message une instruction présentée comme une vérification interne, lui demandant de transmettre des informations sans rapport avec la demande.

La chaîne de risque est la suivante :

1. L’agent récupère l’e-mail dans le cadre de votre mission.
2. Le modèle reçoit le corps du message comme contenu à analyser.
3. Il interprète le passage malveillant comme une instruction applicable.
4. Il propose un appel d’outil pour rechercher ou transmettre des données.
5. L’application exécute cet appel si ses contrôles le permettent.

Le franchissement critique se situe entre la lecture du message et l’autorisation d’agir. Un e-mail peut demander un rendez-vous ; il ne devrait pas pouvoir élargir les droits de l’assistant qui le traite.

Dans une publication du 24 novembre 2025 sur les agents navigateurs, Anthropic présente un scénario analogue d’e-mail contenant des instructions cachées pour provoquer une fuite. L’éditeur souligne que l’amélioration de la résistance des modèles ne rend pas ces agents immunisés.

Le détournement peut aussi rester discret : omettre une réserve, favoriser un fournisseur ou ajouter une affirmation au compte rendu. Une injection réussie n’a pas besoin d’ouvrir un terminal. Modifier l’information sur laquelle vous décidez peut suffire à servir l’attaquant.

Les contenus consultés élargissent la surface d’attaque

Une instruction malveillante peut apparaître dans un texte visible, une image interprétée par le modèle, un commentaire de code ou une extraction de document. Elle n’a pas besoin d’être cachée : une fausse note technique peut sembler assez plausible pour influencer l’assistant.

Un système de RAG récupère des passages documentaires pour alimenter la réponse. Cette récupération ne certifie pas leur autorité. Un passage pertinent pour votre question peut aussi contenir une instruction étrangère à votre objectif ; sa présence dans une base interne ne le rend pas automatiquement fiable.

Les outils ajoutent une autre voie. Une recherche, un lecteur de fichiers ou un connecteur métier renvoie du contenu au modèle. Il faut distinguer la confiance accordée au logiciel qui transporte ce contenu de celle accordée au contenu lui-même : un connecteur légitime peut restituer un message hostile.

La spécification des outils MCP décrit comment un modèle peut découvrir et appeler des outils, et recommande une intervention humaine permettant de refuser leur invocation. Le protocole ne dispense pas l’application de définir ses autorisations et ses confirmations.

Une mémoire durable mérite aussi une attention particulière. Si une instruction externe est enregistrée comme préférence ou règle de travail, elle peut influencer des tâches ultérieures. L’article sur la mémoire des agents IA aide à comprendre pourquoi la provenance des informations conservées compte autant que leur contenu.

Les protections utiles séparent lecture, décision et exécution

La première mesure consiste à réduire ce qu’une décision détournée pourrait provoquer. Un agent chargé de préparer un résumé n’a généralement pas besoin de pouvoir envoyer des messages, modifier une base ou consulter tous les dossiers de l’entreprise.

Appliquez le moindre privilège aux comptes, aux fichiers et aux outils. Privilégiez un accès en lecture lorsque la tâche le permet. Gardez les secrets dans un gestionnaire utilisé par le logiciel, plutôt que de les inclure dans les messages transmis au modèle.

L’autorisation doit ensuite être vérifiée au moment de l’exécution, par du code indépendant de la réponse du modèle. La fiche OWASP sur la sécurité des agents recommande notamment de limiter les capacités et de contrôler les opérations sensibles. Une consigne demandant au modèle de respecter les permissions ne remplace pas ce contrôle.

Pour un envoi externe, la confirmation devrait montrer le destinataire, le contenu exact et les pièces jointes. Pour une modification, elle devrait exposer les ressources concernées. Une approbation générale donnée au début d’une longue tâche permet difficilement de vérifier une action apparue après la lecture d’un contenu hostile.

Enfin, limitez les destinations réseau et isolez l’exécution de code. Un environnement isolé protège seulement ce qui reste hors de son périmètre : s’il contient des documents confidentiels et peut communiquer librement, il conserve un chemin de fuite. Le guide Sécuriser un agent IA détaille ces arbitrages.

Pourquoi une consigne de prudence ne suffit pas

Indiquer clairement que les documents externes sont des données reste utile. Conserver leur provenance, séparer les passages récupérés des instructions de l’application et limiter le contexte transmis peuvent aider le modèle à respecter votre objectif.

Ces mesures ne garantissent toutefois pas qu’il résistera à toutes les formulations. Une attaque peut prétendre corriger une erreur, invoquer une urgence ou présenter une action indésirable comme un préalable nécessaire. Chercher uniquement une formule demandant d’ignorer les instructions laisse passer de nombreuses variantes.

La fiche de prévention de l’OWASP précise que le filtrage des entrées ne constitue pas une frontière de sécurité. Les filtres peuvent manquer une attaque reformulée ou bloquer un document légitime qui explique précisément ce type de menace.

Un second modèle chargé d’examiner les contenus peut apporter un signal supplémentaire. Il doit compléter les restrictions techniques : son verdict reste une sortie de modèle, avec ses propres limites.

Même un format structuré ne prouve pas qu’une action est autorisée. Une requête parfaitement conforme au schéma attendu peut désigner le mauvais destinataire. Le logiciel doit vérifier la relation entre l’action proposée, les droits de l’utilisateur et la tâche confiée.

Vérifier les effets réels et préparer l’arrêt

L’évaluation doit reproduire vos usages avec des données factices et des outils sans effet réel. Placez des instructions de détournement dans les types de contenus effectivement consultés : documents, messages ou réponses de connecteurs. Vérifiez ensuite ce que le système tente de faire.

Observer seulement la réponse finale serait insuffisant. Un agent peut produire un compte rendu satisfaisant après avoir tenté une opération indésirable. Examinez les appels d’outils, les refus d’autorisation, les destinations contactées et les données éventuellement inscrites en mémoire.

Consignez aussi les faux positifs : une protection qui bloque les documents ordinaires rend le service difficile à utiliser. Les résultats doivent préciser le périmètre testé et les actions empêchées, sans transformer l’absence d’échec observé en garantie générale.

Si une activité suspecte apparaît, interrompez la tâche et suspendez les accès concernés. Conservez les traces utiles en évitant d’y multiplier les secrets. Vérifiez les actions réellement exécutées, les données transmises et les éléments mémorisés avant de reprendre.

Le diagnostic de sécurité des agents IA permet de passer en revue ces points. La question pratique reste la même : si le modèle suit une mauvaise instruction, quels contrôles empêchent cette erreur de devenir un dommage ?

À retenir

• L’injection de prompt exploite le passage d’un contenu à analyser vers une instruction suivie par le modèle.
• Une source utile ou un connecteur légitime peut transporter une instruction hostile.
• Les conséquences dépendent des accès aux données, des outils disponibles et des communications autorisées.
• Les consignes et les filtres complètent les permissions, les validations humaines et les contrôles d’exécution.
• Évaluez les actions réelles de l’agent, y compris celles qui précèdent sa réponse finale.

Questions fréquentes

Une injection de prompt peut-elle voler un mot de passe ?

Elle peut provoquer une fuite si le système donne accès au secret et offre un moyen de le transmettre. Un mot de passe absent des données accessibles ne devient pas accessible par la seule formulation d’un message. La protection consiste notamment à conserver les secrets hors du contexte du modèle et à limiter les accès des outils.

Un antivirus détecte-t-il les injections de prompt ?

Une instruction malveillante peut être du texte ordinaire dans un document sans programme exécutable. Une analyse antivirus ne suffit donc pas à établir que ce document peut être traité sans risque par un agent. Il faut aussi contrôler les actions que son contenu pourrait déclencher.

Un modèle exécuté en local est-il protégé ?

L’exécution locale ne supprime pas la confusion possible entre données et instructions. Un agent local qui lit des documents externes reste exposé, surtout s’il dispose d’un terminal ou de connexions à vos comptes. L’absence de réseau peut limiter certaines fuites, sans empêcher les modifications de fichiers autorisées.

Comment reconnaître un document contenant une injection de prompt ?

Méfiez-vous des passages qui s’adressent à l’assistant, revendiquent une autorité technique ou demandent une action étrangère à votre objectif. Leur absence visible ne garantit rien : l’agent peut recevoir une extraction différente de ce que vous voyez. La vérification doit porter sur le contenu effectivement transmis au modèle et sur les appels d’outils.