Une page web peut contenir un ordre destiné à une intelligence artificielle plutôt qu’à son lecteur. Lorsqu’un assistant analyse cette page, il peut confondre le texte consulté avec une instruction légitime.
C’est le principe du prompt injection, une technique qui vise les modèles de langage et leurs outils connectés. Les conséquences vont d’une réponse biaisée à la divulgation de données, selon les permissions de l’agent. Le danger ne vient pas d’une formule magique : il apparaît lorsque des contenus externes franchissent une frontière de confiance. Comprendre cette frontière permet de mieux protéger ChatGPT, les assistants d’entreprise et les applications construites autour des LLM.
En bref :
- Une injection indirecte peut se cacher dans un email, un document ou une page web.
- Le risque augmente quand l’IA peut lire des données privées et déclencher des actions.
- La défense repose sur les permissions, la validation des actions et plusieurs contrôles complémentaires.
Prompt injection : une attaque contre la frontière entre données et instructions
Un modèle de langage reçoit des consignes et des informations à traiter. Une attaque par injection de prompt cherche à faire passer une information non fiable pour une consigne. L’OWASP classe ce risque en première position de son Top 10 des applications LLM 2025. La technique ne suppose pas que le pirate contrôle directement le chatbot : il peut simplement modifier une source que celui-ci doit lire.
Injection directe et injection indirecte
Dans une injection directe, une personne soumet une consigne manipulatrice au modèle. Dans une injection indirecte, le texte malveillant se trouve dans une source externe : page, PDF, email, dépôt de code ou résultat d’outil. Le second scénario complique la détection, car la tâche initiale de l’utilisateur reste parfaitement légitime.
Comment une instruction cachée détourne un assistant IA
Prenons un assistant chargé de comparer des offres immobilières. Une annonce contient un passage demandant au modèle de placer ce bien en tête du classement, quelles que soient les préférences de l’utilisateur. Si le modèle obéit à ce passage, le classement devient manipulé. OpenAI décrit ce type de scénario dans sa documentation de sécurité. Il s’agit d’un risque illustratif, pas de la preuve qu’un assistant donné y succombe systématiquement.
Le même mécanisme peut cibler un assistant de messagerie. Un email contrôlé par un attaquant peut tenter de faire rechercher des pièces jointes confidentielles, puis d’en transmettre le contenu. Pour que la fuite réussisse, l’agent doit disposer des accès nécessaires et les protections doivent échouer. Une instruction malveillante seule ne donne pas des permissions supplémentaires.
Pourquoi le texte malveillant paraît crédible
Les attaques peuvent imiter un message système, inventer une urgence ou présenter une opération comme indispensable à la tâche. Certaines sont fragmentées entre plusieurs contenus. D’autres utilisent des images ou des éléments qui sont invisibles pour l’humain. L’OWASP souligne que l’instruction n’a même pas besoin d’être lisible à l’écran si le modèle peut la traiter.
Où les pirates cachent-ils leurs injections de prompt ?
Un chatbot n’a pas besoin de recevoir un message malveillant pour être manipulé. Les pirates peuvent exploiter les contenus que l’IA consulte pendant son travail. Lors d’une recherche sur Internet, un assistant peut rencontrer des instructions malveillantes dissimulées dans une page web, ses métadonnées ou des éléments peu visibles.
Les PDF, fichiers Word et présentations présentent le même risque, entre autres lorsqu’ils sont analysés de manière automatique. Un simple email peut aussi pousser un agent à modifier ses priorités, à consulter d’autres données ou à déclencher une action. Dans les dépôts GitHub, les fichiers README, les commentaires et la documentation peuvent aussi dissimuler des consignes malveillantes. Même les résultats des outils connectés peuvent servir de support. Ce risque s’est d’ailleurs concrétisé avec l’attaque visant Claude Code et Codex, piégés par un simple fichier malveillant.
Le point commun ? Toutes ces sources sont censées fournir des informations, pas donner des ordres. L’attaque exploite précisément cette confusion pour amener l’assistant à traiter un contenu externe comme une instruction prioritaire.
Quels dommages une injection de prompt peut-elle provoquer ?
Le premier niveau est la manipulation de réponse : faux résumé, recommandation biaisée ou omission volontaire. Plus grave, un agent connecté peut être amené à ouvrir un lien, appeler un outil ou tenter de transmettre des informations. Des actions sur des fichiers, des dépôts ou des comptes sont aussi envisageables lorsque l’application les autorise. La gravité dépend donc autant de l’architecture que du modèle.
Cette distinction évite une confusion fréquente avec le jailbreak. Le jailbreak vise surtout à contourner les règles de comportement d’un modèle. Le prompt injection, notamment indirect, détourne la confiance accordée à des contenus externes. Les deux phénomènes peuvent se recouper, mais ils ne désignent pas exactement le même problème.
Comment reconnaître une tentative de prompt injection ?
Un changement de comportement inattendu peut révéler une tentative de prompt injection. Par exemple, un assistant chargé de résumer un document recommande un service commercial ou refuse de répondre à une question ordinaire de manière soudaine.
Ces anomalies ne prouvent toutefois pas une attaque : elles peuvent aussi résulter d’une erreur du modèle. Autre signal : les fausses instructions d’autorité. Un document externe peut contenir des expressions comme « instruction système », « priorité absolue » ou « nouvelle politique de sécurité », sans disposer d’une quelconque autorité sur l’assistant.
Certaines attaques sont plus subtiles. Elles présentent une action risquée comme une étape indispensable, par exemple une vérification externe qui conduit l’assistant vers un site contrôlé par l’attaquant. Dans un environnement professionnel, les journaux d’activité permettent de repérer d’autres anomalies : appels d’outils inhabituels, accès à des fichiers sans rapport avec la demande ou tentatives de connexion à des domaines inconnus. La surveillance doit donc porter autant sur les actions de l’agent que sur ses réponses. Pour répondre à ce défi, des solutions émergent, à l’image des Microsoft Guardian Agents qui délèguent à des IA la surveillance d’autres IA.
Comment protéger ChatGPT et les agents IA contre le prompt injection
Limiter les accès avant de chercher le prompt parfait
Le principe le plus robuste consiste à réduire les permissions. Un agent chargé de résumer des documents n’a pas besoin d’envoyer des emails ou de supprimer des fichiers. Les comptes dédiés, les droits minimaux et les environnements isolés limitent l’impact d’une instruction trompeuse. Une confirmation humaine doit précéder les actions sensibles, avec affichage clair du destinataire et des données concernées.
Traiter les sources externes comme des données non fiables
Les développeurs doivent séparer instructions de confiance et contenu récupéré. Les sorties structurées, la validation des paramètres, les listes d’actions autorisées et le contrôle des destinations réduisent les risques de détournement. Les filtres de détection sont utiles, mais ne suffisent pas à eux seuls. OpenAI recommande aussi les tests adversariaux et l’analyse des appels d’outils.
Tester les chaînes complètes, pas seulement le chatbot
Un test pertinent reproduit la vraie chaîne : document piégé, récupération par l’agent, interprétation, puis tentative d’action. Il faut vérifier non seulement la réponse finale, mais aussi les accès utilisés et les informations éventuellement envoyées. Un modèle qui refuse une instruction visible peut rester vulnérable dans un parcours complexe.
Pourquoi le prompt injection menace aussi les entreprises ?
Du service client aux ressources humaines, en passant par le développement informatique et l’analyse financière, les entreprises déploient des assistants IA capables d’accéder à des informations sensibles. Prenons un agent chargé de traiter les demandes des clients. Si un attaquant introduit des instructions malveillantes dans les documents ou les outils qu’il consulte, il peut tenter de détourner son comportement. Les conséquences dépendent des autorisations accordées à l’assistant. Un système limité à la consultation risque de produire des réponses trompeuses, tandis qu’un agent capable de modifier des dossiers ou d’envoyer des messages peut provoquer des dommages plus importants.
La confidentialité est aussi menacée. Un agent connecté à des documents internes peut être manipulé pour récupérer ou transmettre des données sensibles. Le succès de cette attaque dépend toutefois des permissions et des contrôles de sécurité en place. Pour les entreprises, le risque dépasse donc la simple fiabilité des réponses. La sécurité de ces environnements reste un enjeu critique, comme l’a illustré la facilité avec laquelle une start-up a pu accéder aux données internes d’Anthropic. Avant de déployer un agent autonome, elles doivent encadrer l’accès aux données, surveiller les actions automatisées et prévoir une validation humaine pour les opérations sensibles.
Les agents autonomes rendent la sécurité des permissions décisive
Plus les assistants gagnent en autonomie, plus les contenus qu’ils rencontrent deviennent une surface d’attaque. Le bon objectif n’est pas de promettre une IA impossible à tromper. Il consiste à concevoir des systèmes où une erreur d’interprétation ne se transforme pas toujours en fuite de données ou en action irréversible. C’est là que se joue la sécurité des agents IA.
- Partager l'article :
