Injection de prompt : risques de fuite de données des assistants IA

Qu'est-ce qu'une injection de prompt ?

L'injection de prompt est une cyberattaque contre les grands modèles de langage (LLM) : l'attaquant déguise des entrées malveillantes en entrées légitimes [10]. Elle vise les services qui s'appuient sur l'IA [11]. Son but est de pousser le modèle à ignorer ses instructions d'origine [13] et à suivre à la place celles de l'attaquant [27].

Les trois éléments de la définition

• Une entrée d'apparence légitime : le texte piégé ressemble à une requête ou à un contenu ordinaire [10].
• Un effet sur les consignes : le modèle abandonne les instructions qui encadraient son comportement [27].
• Un bénéficiaire : ce sont désormais les ordres de l'attaquant qui sont suivis, et non ceux du concepteur ou de l'utilisateur légitime [27].

Une source la présente comme un moyen de détourner une IA sans exploiter de faille au sens classique [28]. Pour un RSSI, cela change la nature du problème : la manipulation passe par le canal normal d'utilisation du modèle, et pas par une vulnérabilité de code qu'un correctif suffirait à fermer.

Deux analogies courantes, à manier avec prudence

Deux comparaisons reviennent dans la littérature des éditeurs :

• L'injection SQL : Flutteris décrit l'injection de prompt comme « l'équivalent IA de l'injection SQL » [27].
• L'ingénierie sociale : OpenAI la qualifie d'attaque d'ingénierie sociale spécifique à l'IA conversationnelle [16].

Ces deux sources sont des acteurs commerciaux. Leurs comparaisons sont pédagogiques : elles aident à situer le risque par rapport à des attaques connues, mais elles ne démontrent pas une équivalence technique. La première met l'accent sur l'entrée forgée qui détourne un système, la seconde sur la persuasion d'un interlocuteur. L'injection de prompt emprunte un peu aux deux sans se confondre avec l'une ni l'autre.

Reste à comprendre pourquoi un modèle se laisse ainsi détourner, et par quels chemins l'entrée malveillante lui parvient : ce sont les objets des sections suivantes.

Pourquoi les LLM se laissent-ils manipuler ?

Les LLM se laissent manipuler parce qu'ils ne séparent pas les instructions qu'on leur donne des données qu'ils lisent : le modèle traite toutes les entrées comme un prompt continu [34].

Une frontière qui s'efface

Quand un agent reçoit « analyse ce contrat », « résume cet email » ou « reformule ce paragraphe », il exécute la consigne. Mais pour accomplir la tâche, il lit un document, et le contenu de ce document n'a pas pour lui un statut distinct de celui de la consigne initiale [34]. Un texte glissé dans le document peut donc être pris pour un ordre. L'IA devient ainsi un vecteur d'attaque parce qu'elle efface la frontière entre données et instructions [21].

Les conséquences se voient dans le cas indirect : l'IA exécute alors les ordres cachés comme s'ils venaient de l'utilisateur légitime [36]. Une analyse de Palo Alto Networks sur les assistants de codage va dans le même sens : le modèle ne distingue pas de façon fiable les instructions système des requêtes utilisateur [33].

Une attaque qui n'exploite aucune faille

Le prompt injection détourne une IA sans exploiter de faille au sens traditionnel [28]. Il ne s'appuie pas sur une erreur d'implémentation. Il exploite le fonctionnement normal du modèle pour le retourner contre ses concepteurs [24]. Le modèle fait ce pour quoi il a été conçu : suivre les instructions qu'il lit.

Les comparaisons proposées par les sources reflètent cette particularité. Certaines assimilent l'attaque à l'injection SQL, puisque l'attaquant pousse le modèle à abandonner ses instructions d'origine pour suivre les siennes [27]. D'autres y voient une attaque d'ingénierie sociale propre à l'IA conversationnelle [16]. Ce second parallèle est le plus parlant : on ne force aucune protection, on convainc le modèle.

Cette cause de fond pèse davantage à mesure que les assistants s'ouvrent aux données internes et au web. Cette extension de leurs capacités introduit une forme de risque encore mal cadrée [28]. Plus l'agent lit de sources qu'il ne maîtrise pas, plus les occasions d'y glisser une instruction se multiplient. D'où l'idée, défendue par certaines sources, que la sécurité repose sur la réduction de la surface d'attaque, le moindre privilège et des contrôles à chaque étape plutôt que sur une parade unique [39].

Quelle différence entre injection directe et indirecte ?

L'injection directe est saisie par l'attaquant dans la requête qu'il adresse au modèle. L'injection indirecte est cachée dans une source que l'assistant traite, et l'utilisateur légitime l'ignore souvent. Une source la définit comme l'insertion d'instructions malveillantes dans une requête ou dans une source de données, afin d'influencer le comportement du modèle [23].

Où se cachent les instructions

• Directe : l'instruction arrive par le canal de la conversation, sous la forme d'une requête.
• Indirecte : l'instruction passe par les données que l'IA traite, souvent à l'insu de l'utilisateur [18]. Il peut s'agir d'un document, d'une page web ou d'une autre source de données.

Le second cas fonctionne parce que l'IA traite toutes les entrées comme un prompt continu. Elle ne sépare pas les instructions que l'utilisateur lui a données (« analyse ce contrat », « résume cet email ») des données qu'elle est en train de lire [34].

Un site web qui piège un assistant

Un site web peut suffire à détourner un assistant. Un article consacré à Claude décrit ce scénario : le contenu de la page porte des ordres cachés, et l'IA les exécute comme s'ils venaient de l'utilisateur légitime. Les conséquences possibles sont des fuites de données, des actions non autorisées ou des réponses biaisées [36]. L'utilisateur a seulement demandé de consulter ou de résumer une page. L'attaquant, lui, n'a jamais eu accès à la conversation.

Un point d'attention pour les agents

Les sources académiques du dossier traitent l'injection indirecte comme un risque à part. Un article sur la délégation d'une intention à un agent IA cite la prompt injection, « y compris indirecte », comme premier risque, et la fuite de données comme second [8]. Un ouvrage consacré à la responsabilité quand les machines agissent traite lui aussi explicitement l'injection de prompt indirecte [5]. Pour un agent qui lit des sources externes puis agit, la surface d'attaque ne se limite donc pas à ce que saisit l'utilisateur : elle inclut tout ce que l'agent ouvre, lit ou interroge.

Comment une injection de prompt provoque-t-elle une fuite de données ?

Une injection de prompt provoque une fuite de données par trois voies documentées : des actions indésirables de l'agent, les sorties du modèle et l'exposition du prompt système. Ces fuites provoquées par un attaquant sont à distinguer de celles qui viennent des usages quotidiens.

Trois voies de fuite provoquées par l'attaque

• Actions indésirables de l'agent. Selon Bruno Lussato, cité par franceinfo, un pirate peut élaborer des prompts qui poussent l'agent IA à agir contre son rôle : fuite de données, exécution de code ou génération de contenus malveillants [26]. La fuite de données sensibles figure aussi parmi les principaux risques recensés, avec la prise de contrôle partielle des systèmes et l'atteinte à la réputation [25].
• Fuite par les sorties du modèle. Parmi les menaces fréquentes, une source cite « de l'injection de prompt à la fuite par les sorties » [2]. Ce que le modèle répond peut donc devenir le canal de sortie des informations.
• Fuite du prompt système. Elle est techniquement apparentée à l'injection de prompt et au jailbreak [30]. Les clés API et les identifiants figurent parmi les éléments exposés [30]. On peut en déduire qu'un prompt système ne devrait pas contenir de secrets.

Fuites par usage quotidien : un autre mécanisme

Dans ce second cas, aucun attaquant n'intervient. Des informations confidentielles sont transmises involontairement à des services tiers, via les interfaces IA qu'utilisent les collaborateurs [20]. La cause est un comportement d'usage, pas une manipulation du modèle.

Les deux familles se rejoignent sur la question des données saisies dans les prompts. Une analyse du Shadow AI recommande de se demander quelles données un outil intègre dans ses prompts [3]. Les informations transmises à un service non maîtrisé sont exposées, qu'une injection ait lieu ou non.

Cette distinction compte pour un RSSI : les deux fuites n'appellent pas les mêmes mesures. Pour l'une des sources, avec ce type d'assistant, « le vrai sujet de sécurité est la gouvernance » [2].

Quels autres dégâts pour les agents, la mémoire et le code ?

Le risque de l'injection de prompt ne se limite pas à la fuite de données : dès qu'un assistant dispose d'outils, d'une mémoire ou d'un accès au code, une instruction détournée peut déclencher des actions et pas seulement des divulgations.

Actions non prévues et propagation

Selon Bruno Lussato, cité par franceinfo, un pirate peut élaborer des prompts qui provoquent des actions indésirables de l'agent : fuite de données, exécution de code ou génération de contenus malveillants [26]. IBM décrit en outre un scénario de propagation. L'invite malveillante demande à l'assistant de la transmettre à d'autres contacts [10]. L'attaque ne reste alors pas cantonnée à la première victime.

Empoisonnement de la mémoire

Des instructions cachées peuvent être injectées discrètement dans la mémoire d'assistants grand public : Microsoft Copilot, ChatGPT, Claude, Perplexity et Grok [29]. La cible n'est plus une conversation isolée mais la mémoire de l'assistant.

Assistants de codage détournés

L'équipe Unit 42 de Palo Alto Networks a constaté que ces assistants peuvent être détournés par des utilisateurs ou des acteurs malveillants, via le chat, l'auto-complétion ou la génération de tests unitaires. Les conséquences relevées sont l'insertion de portes dérobées, la fuite d'informations sensibles et la création de contenus préjudiciables [33]. Secure Code Warrior rapporte de son côté un agent de codage piégé pour écrire du code vulnérable aux injections SQL et installer des outils système [17].

Ce que valent ces sources

Ces cas viennent d'un média grand public (franceinfo) et d'acteurs commerciaux : IBM, Palo Alto Networks, Secure Code Warrior. L'article qui rapporte l'empoisonnement de mémoire est lui aussi celui d'un site commercial, et l'extrait disponible ne permet pas d'identifier les auteurs de l'étude qu'il cite [29]. Aucun de ces éléments n'est une étude primaire examinée ici. Ils illustrent des scénarios plausibles et documentés, mais ne mesurent ni leur fréquence ni leur taux de réussite. Un RSSI les utilisera donc pour dresser une liste de scénarios à tester, pas pour chiffrer un risque.

Que dit l'OWASP, et quelles sont les obligations RGPD ?

L'injection de prompt est présentée par plusieurs sources comme la vulnérabilité n°1 selon l'OWASP. Selon une source commerciale, une fuite de données qu'elle provoque relève du même régime RGPD qu'un piratage classique.

Sa place dans le référentiel OWASP

L'OWASP est décrite comme une organisation internationale de référence en cybersécurité. Un site spécialisé indique qu'elle classe l'injection de prompt en vulnérabilité n°1 [24]. Un autre prestataire en cybersécurité parle du « danger numéro un des LLMs selon l'OWASP » [37]. Ces deux sources sont des contenus de professionnels, pas le référentiel lui-même. Pour un classement opposable, il faut consulter directement le document de l'OWASP.

Un article consacré à l'« OWASP Top 10 LLM 2026 » évoque, lui, un focus sur les risques agentiques, l'« Unbounded Consumption », l'injection de prompt et l'OWASP ASI [40]. Le dossier ne permet pas de détailler le classement 2026, ni de dire quelle place l'injection de prompt y occupe. Nous ne l'affirmons donc pas.

Obligations RGPD en cas de fuite

Selon core.security, une source commerciale, le responsable de traitement qui subit une fuite de données clients provoquée par une injection de prompt s'expose aux mêmes obligations légales qu'avec un piratage classique [32]. La source cite :

• la notification à la CNIL sous 72 heures ;
• des sanctions financières pouvant atteindre 4 % du chiffre d'affaires mondial [32].

D'après cette source, la technique d'attaque ne change donc pas la qualification de l'incident. Pour un RSSI, l'injection de prompt est une cause possible de violation de données, à intégrer aux procédures de gestion d'incident au même titre qu'une intrusion.

Le dossier ne contient ni le texte du RGPD ni une publication de la CNIL. Ces éléments sont rapportés par un acteur commercial, et le DPO devra les confirmer sur les textes officiels.

Comment réduire le risque en pratique ?

Aucune parade unique ne suffit : la défense en profondeur combine réduction de la surface d'attaque, moindre privilège et contrôles à chaque étape. [39] Chaque couche limite les dégâts que les autres n'ont pas évités.

Les leviers que le dossier permet d'appuyer

• Limiter ce que l'agent peut atteindre. L'injection de prompt est moins préoccupante si l'agent ne peut pas accéder aux données sensibles. [15] Databricks, éditeur de plateforme de données, recommande donc de restreindre les capacités de l'agent, notamment son accès aux systèmes sensibles et aux données privées. [15]
• Placer l'humain et les droits au bon endroit. Une source spécialisée cite la validation humaine et les contrôles d'accès granulaires, en particulier dans le secteur financier. [35] L'idée est qu'une action sensible ne repose pas sur la seule décision du modèle.
• Sécuriser avant de déployer. Selon Flowpi, éditeur commercial, les chatbots et copilotes doivent être protégés avant leur mise en production. Sans garde-fous, l'injection de prompt et les fuites de données menacent la marque, les clients et le retour sur investissement. [22]
• Traiter le sujet comme une question de gouvernance. Pour un assistant d'entreprise, « le vrai sujet de sécurité est la gouvernance ». Cela suppose une posture de sécurité des données dédiée à l'IA. [2]

Une limite à assumer

Ces mesures réduisent le risque sans l'éliminer. Un test mobilisant 2000 hackers contre un assistant IA conclut que l'injection de prompts reste un problème de sécurité réel. [35] Les sources du dossier ne présentent aucune mesure technique infaillible, et celles qui détaillent des mesures sont pour l'essentiel des éditeurs ou des consultants. Pour un RSSI, la conséquence est pratique : il faut concevoir l'architecture en supposant qu'une injection finira par passer, et se demander ce que l'agent pourra alors lire, exécuter ou transmettre.

Comment Oupi encadre-t-il les actions de son agent ?

Oupi encadre les actions de son agent selon deux principes : les actes sensibles sont soumis à une validation humaine, et l'exécution de l'agent est isolée. Cette section décrit ces principes sans détailler leur mise en œuvre.

Deux principes

• Validation humaine des actes sensibles. L'agent ne mène pas seul à terme une action à conséquences. Une personne la valide avant qu'elle ne soit effectuée.
• Exécution isolée. L'agent travaille dans un périmètre séparé, ce qui circonscrit ce qu'une action détournée pourrait atteindre.

Le lien avec les recommandations générales

Ces deux principes recoupent les mesures recommandées dans le reste de ce dossier.

• Limiter les capacités de l'agent. Databricks, éditeur de plateformes de données, indique que l'injection de prompt est moins préoccupante si l'agent ne peut pas accéder aux données sensibles. Il recommande de restreindre l'accès aux systèmes sensibles et aux données privées [15]. L'isolation de l'exécution va dans ce sens : elle réduit ce qu'un agent manipulé peut toucher.
• Maintenir une supervision humaine. Un article de Roboto, acteur commercial, cite la validation humaine, associée à des contrôles d'accès granulaires, parmi les réponses adoptées dans le secteur financier [35]. La validation des actes sensibles relève de cette logique : une instruction injectée ne suffit pas à déclencher seule une action critique.
• Réduire la surface d'attaque. Selon un guide technique de sécurisation des applications LLM, la sécurité repose sur la réduction de surface, le moindre privilège et des contrôles à chaque étape, pas sur une parade unique [39]. La validation humaine et l'isolation sont deux de ces contrôles.

Les limites de ce dispositif

Ces mesures réduisent le risque, elles ne l'éliminent pas. Un test mené avec 2 000 participants sur un assistant IA conclut que l'injection de prompts reste un problème de sécurité réel [35]. La validation humaine suppose aussi que la personne comprenne ce qu'elle approuve. Elle complète les autres protections (contrôle des sorties, détection, surveillance) et ne les remplace pas, conformément à l'approche en défense en profondeur [39].

Les engagements d'Oupi en matière de confiance sont présentés sur la page Confiance.