Prompt injection : protéger les agents IA et leurs accès

Un e-mail lu par votre agent ne doit jamais lui donner le droit d’en envoyer un autre, d’exporter des données clients ou de modifier une opportunité commerciale. L’Open Worldwide Application Security Project (OWASP) classe la prompt injection au rang LLM01 de son Top 10 des risques pour les applications utilisant des LLM. Pour les équipes de développement, la réponse concrète consiste à limiter ce que l’application peut faire, même lorsque le modèle suit la mauvaise instruction. Aucune défense ne résout aujourd’hui entièrement le problème.

Informations vérifiées le 26 octobre 2026 à partir des recommandations en ligne de l’OWASP et d’Anthropic. Les scénarios de messagerie et de CRM ci-dessous illustrent des choix de conception ; ils ne décrivent pas les résultats de déploiements réels.

Qu’est-ce que la prompt injection ?

Une injection de prompt se produit lorsqu’une entrée détourne un modèle de langage des instructions qu’il est censé suivre. Un grand modèle de langage, ou LLM, interprète le langage pour formuler des réponses et proposer des actions. Le problème apparaît lorsqu’un contenu qu’il devrait simplement lire devient une consigne à laquelle il obéit.

Imaginez un salarié qui examine un courrier de fournisseur. Ce courrier peut signaler un problème de livraison ; il ne peut pas accorder au fournisseur un accès à votre base clients. Un agent doit distinguer de la même manière ce qui l’informe de ce qui l’autorise à agir. C’est à l’application de faire respecter cette distinction.

L’OWASP identifie deux points d’entrée dans sa fiche LLM01:2025 Prompt Injection : les saisies directes des utilisateurs et, indirectement, les contenus externes. L’enjeu est de savoir qui peut définir la tâche et les permissions, pas de juger si un texte suspect semble professionnel.

Une réponse erronée n’est pas forcément le résultat d’une injection. Le modèle peut inventer un fait sans manipulation extérieure. L’injection suppose, elle, qu’une entrée oriente son comportement. Les deux peuvent causer des dommages, mais un filtre conçu pour repérer des instructions hostiles ne détectera pas toutes les erreurs ordinaires du modèle.

Comment fonctionne l’injection de prompt en IA générative ?

Le modèle lit à la fois les instructions et les contenus nécessaires à la tâche. Il peut alors attribuer à ces contenus une autorité qu’ils ne devraient pas avoir. Les rôles des messages et les indications de provenance l’aident à faire la distinction, mais ne remplacent pas les contrôles d’accès.

Avec un agent, une étape supplémentaire rend l’erreur plus lourde de conséquences : l’application transforme une action proposée en appel d’outil. Un outil est une fonction qui agit en dehors de la conversation, par exemple pour rechercher des fiches ou envoyer un message. Si l’application exécute tout ce que propose le modèle avec des identifiants disposant de droits étendus, une erreur d’interprétation peut se transformer en action sur l’activité de l’entreprise.

Tout agent qui utilise des outils doit donc respecter cette limite : comprendre une demande ne suffit pas à établir qu’elle est autorisée.

Exemples de prompt injection directe et indirecte

La différence tient au point d’entrée de l’instruction hostile. Les exemples suivants décrivent le comportement recherché par l’attaquant, sans reproduire le texte des attaques.

Injection de prompt directe

Un client écrit à un assistant d’assistance et tente de le convaincre de révéler les notes du compte d’un autre client. Il prétend que sa demande bénéficie d’une autorisation interne spéciale. L’attaquant utilise directement le canal de saisie de l’application.

La défense doit inclure un service d’accès aux fiches qui vérifie les droits du client authentifié. Même si le modèle croit à son histoire, ce service doit refuser l’accès à la fiche d’un autre client. Une consigne de refus dans le prompt système aide à orienter le modèle ; c’est le contrôle d’accès aux fiches qui impose réellement la limite.

Prompt injection indirecte

Un fondateur chargé des ventes demande à un agent de résumer l’e-mail d’un prospect et de proposer la suite à donner. Cet e-mail contient des éléments conçus pour pousser l’agent à exporter, depuis le logiciel de gestion de la relation client (CRM), des contacts sans rapport avec la demande vers un destinataire externe. La demande du fondateur est légitime ; l’instruction hostile provient de l’e-mail traité.

L’attaque peut emprunter le même chemin à travers une page web, un document, une pièce jointe ou le résultat d’un outil. Un stockage interne ne rend pas toutes les données dignes de confiance : un texte présent dans votre CRM peut avoir été fourni par un client. Anthropic, qui développe le modèle de langage Claude, traite ces sources tierces comme un modèle de menace distinct dans ses recommandations de protection contre l’injection de prompt.

Pour un agent de messagerie, l’expéditeur d’un e-mail ne doit jamais hériter des permissions d’utilisation des outils du propriétaire de la boîte, au seul motif que celui-ci a demandé un résumé.

Prompt injection et jailbreak IA : quelle différence ?

Un jailbreak cherche à contourner les restrictions de sécurité d’un modèle. Une injection de prompt peut aussi viser la tâche habituelle de l’application ou ses permissions. Un résumé commercial faussé ou une modification non autorisée d’un contact peuvent sembler anodins à un système de modération des contenus, tout en enfreignant les règles de l’entreprise.

Prévoyez à la fois des protections sur les contenus et des contrôles d’autorisation. Ils répondent à des questions différentes.

Pourquoi l’injection de prompt devient-elle un risque pour l’entreprise ?

Les dommages potentiels augmentent avec l’étendue des données et des actions accessibles à l’agent. Dans sa fiche distincte sur l’autonomie excessive des agents, l’OWASP identifie l’excès de fonctionnalités, de permissions et d’autonomie comme des causes de comportements dommageables.

Pour une messagerie ou un CRM, les conséquences correspondent à des incidents bien concrets :

• Des données confidentielles sortent du système. Une réponse, une pièce jointe, une requête sortante ou un message contient des informations que son destinataire ne devrait pas recevoir.
• Des fiches sont modifiées sans autorisation. L’agent modifie un compte, supprime un historique utile ou change l’étape d’une opportunité commerciale parce qu’un texte récupéré l’a détourné de sa tâche.
• Une décision est faussée à bas bruit. Un prospect paraît plus qualifié, une réclamation disparaît d’un résumé ou un fournisseur bénéficie d’une recommandation injustifiée.

Un accès en lecture seule est plus restreint qu’un accès en écriture, mais il n’empêche pas à lui seul les fuites de données confidentielles. Si l’application récupère des fiches privées et peut en divulguer le contenu dans une réponse ou par une connexion sortante, leur confidentialité doit toujours être protégée.

Dans une étude publiée le 3 mars 2026, Unit 42 de Palo Alto Networks a documenté des instructions malveillantes intégrées à des contenus web en ligne. Repérer une tentative ne prouve pas que toutes les cibles l’ont suivie. Cela montre néanmoins pourquoi les contenus externes doivent entrer dans le modèle de menace avant qu’un agent soit autorisé à agir.

Les fondateurs doivent valider l’ampleur maximale des dommages qu’un workflow est autorisé à provoquer. Les équipes de développement doivent rendre cette limite effective aux points d’accès aux données et aux outils. Les équipes d’exploitation doivent pouvoir suspendre l’exécution et enquêter lorsque ces limites sont mises à l’épreuve.

Comment empêcher une attaque par injection de prompt de provoquer un incident ?

Concevez le système en partant du principe qu’une injection peut passer. Les contrôles ci-dessous constituent une architecture recommandée pour un agent de messagerie ou de CRM. Ils appliquent les recommandations de l’OWASP sur les privilèges et les validations à un workflow concret. Il ne s’agit ni d’un comparatif de produits ni d’une garantie d’immunité.

Commencez par les permissions réelles de l’outil. Une fonction appelée « résumer la boîte de réception » n’est pas limitée à la synthèse si les identifiants qu’elle utilise permettent aussi d’envoyer des messages et de supprimer des e-mails. Vérifiez la configuration du compte et du service sous-jacents, pas seulement le nom de la fonction.

Contrôlez ensuite les données qui quittent l’application. Une liste d’autorisation réseau, qui énumère les destinations permises, contribue à réduire les voies possibles de divulgation. Mais autoriser un service de messagerie ne revient pas à autoriser tous les destinataires ; autoriser le domaine d’un CRM ne revient pas à autoriser tous les comptes ni toutes les opérations d’export. Vérifiez aussi la demande au sein du service autorisé.

Les recommandations d’Anthropic pour un déploiement sécurisé préconisent de conserver les identifiants hors de l’environnement de l’agent, de restreindre l’accès réseau et de valider les requêtes au moyen d’un proxy. Un proxy est un intermédiaire qui peut appliquer des règles avant de transmettre une requête. Pour une intégration de messagerie hébergée, votre propre service d’outils peut jouer ce rôle : il détient les identifiants et refuse les opérations hors périmètre.

Pour une vue plus large des contrôles sur les entrées, les sorties et l’exécution, consultez le guide des garde-fous pour l’IA.

Comment appliquer les recommandations d’Anthropic aux contenus récupérés ?

Anthropic recommande de transmettre les contenus tiers dans des blocs tool_result, d’en indiquer la source, de définir une politique explicite pour les contenus non fiables et d’encoder les chaînes en JSON plutôt que de les insérer dans des instructions en texte libre. Ses recommandations prévoient aussi l’analyse des sorties d’outils et la surveillance du comportement. Voir les recommandations actuelles pour Claude.

Dans l’exemple commercial, le corps de l’e-mail du prospect doit rester identifiable comme un e-mail provenant de cet expéditeur. Ne le copiez pas dans une instruction privilégiée simplement parce qu’une étape précédente du modèle l’a résumé. Conservez la référence de la source lorsque vous transmettez les informations extraites à une autre étape.

JSON est un format de données structurées. Échapper correctement le texte évite qu’il ne casse la sérialisation qui l’entoure ; cela n’empêche pas le modèle de se laisser convaincre par le sens de ce texte. L’encodage constitue donc une couche de protection, tandis que les autorisations doivent toujours être imposées ailleurs.

Lier la validation à l’action exacte qui sera exécutée

Un bouton de validation ne protège l’entreprise que si l’exécution dépend de ce que la personne a réellement examiné. « Continuer le traitement de ce compte » est trop vague pour un agent capable d’envoyer des pièces jointes ou de réécrire des fiches clients.

Prenons une proposition consistant à répondre à un prospect et à mettre à jour une opportunité commerciale. La personne chargée de la validation doit voir le destinataire réel, le message, la liste des pièces jointes, la fiche concernée et les valeurs des champs avant et après modification. L’application doit conserver la proposition validée et exécuter cette version. Si le modèle modifie ensuite le destinataire ou une pièce jointe, une nouvelle validation doit être exigée.

La validation doit également provenir d’une personne authentifiée qui dispose des droits nécessaires. Un e-mail affirmant que quelqu’un a déjà approuvé l’opération reste un contenu source, pas un acte de validation. Le modèle ne doit pouvoir ni créer sa propre preuve de validation ni accéder à un autre outil qui contournerait ce contrôle.

Laissez l’action en attente si la personne refuse de la valider, si la validation expire ou si le système de vérification est indisponible. Un délai dépassé ne doit pas se transformer silencieusement en permission. Concevez les nouvelles tentatives d’exécution pour qu’un échec de livraison ne provoque pas l’envoi répété du même message approuvé.

Il s’agit de recommandations de mise en œuvre pour ce workflow, pas d’une affirmation selon laquelle la vérification humaine détecte toutes les attaques. Le guide de l’IA avec intervention humaine explique comment organiser le traitement des files de validation et les procédures d’escalade.

Checklist pour un agent de messagerie ou de CRM

Commencez par le workflow utile le plus restreint possible. Passez cette checklist en revue avant d’activer des actions externes autonomes :

• Identité : chaque lecture et chaque modification sont limitées au périmètre de l’utilisateur authentifié et du compte d’entreprise autorisé. Le modèle ne peut pas choisir une identité disposant de privilèges supérieurs.
• Données : ne récupérez que les fiches et les champs nécessaires à la tâche. Gardez les secrets hors des contenus visibles par le modèle et conservez la provenance des textes issus des e-mails, des documents et du CRM.
• Outils : la lecture, la rédaction de brouillons, l’envoi, l’export et la modification relèvent de permissions distinctes. Retirez les capacités dont le workflow n’a pas besoin.
• Transmission : contrôlez les réponses et les arguments des outils avant leur transmission. Vérifiez les destinataires, les pièces jointes, les destinations et les modifications de fiches autorisées.
• Validation : les actions à fort impact exigent une vérification de l’action exacte, imposée par le code de l’application. Une validation manquante ou modifiée entraîne une mise en attente.
• Exploitation : tenez un journal des actions respectueux de la confidentialité, désignez un responsable des alertes, prévoyez un mécanisme de pause et testez tout le workflow avant d’élargir les accès.

Pour l’assistant commercial d’un fondateur, un périmètre initial raisonnable consiste à lire un fil de discussion choisi avec un prospect et à proposer un brouillon. L’export massif, l’envoi automatique ou la mise à jour en masse d’opportunités commerciales doivent chacun faire l’objet d’une justification distincte. Définissez les permissions à partir du travail que vous souhaitez proposer, plutôt qu’à partir de tout ce que l’intégration permet techniquement.

Le guide pratique pour limiter les conséquences d’une défaillance d’agent IA en production développe l’architecture de confinement dans son ensemble. Le rayon d’impact, ou blast radius, désigne l’étendue de la propagation possible d’une défaillance dans les systèmes connectés.

Tester la prompt injection : vérifier les effets, pas seulement la réponse

Un test réussit lorsque le résultat interdit ne se produit pas. Un assistant peut afficher un refus alors qu’un appel d’outil a déjà modifié une fiche. Inspectez le service d’outils et l’état obtenu, pas seulement la conversation.

Pour répéter le lancement, utilisez des contacts fictifs, des boîtes de test et un environnement contrôlé. La procédure suivante est un plan de test de l’application, pas un ensemble de charges d’attaque.

1. 1

   Établir le fonctionnement normal autorisé

   Exécutez une tâche ordinaire de synthèse des échanges avec un prospect. Vérifiez que les bonnes fiches sont récupérées, que le brouillon est utile et que la validation est exigée exactement là où vos règles le prévoient. Le travail légitime doit continuer à aboutir.

2. 2

   Tester les deux points d’entrée

   Introduisez une demande non autorisée au point de saisie utilisateur et un message tiers qui tente de détourner la tâche. Vérifiez que les fiches sans rapport avec la demande restent inaccessibles et que les opérations d’outils interdites sont refusées.

3. 3

   Mettre à l’épreuve la validation et la gestion des échecs

   Testez une modification des détails de l’action après validation, un refus de validation, l’indisponibilité du service de contrôle des règles et une nouvelle tentative d’exécution. Vérifiez que l’application suspend ou refuse l’action et évite de produire deux fois le même effet.

4. 4

   Examiner les traces et les alertes

   Contrôlez l’état final du CRM, les messages sortants, les destinations tentées, la trace de validation et le journal des décisions de contrôle. Vérifiez que l’équipe d’exploitation peut identifier la source et arrêter le workflow sans dépendre des explications du modèle.

Répétez les tests concernés lorsque les prompts, les modèles, la récupération de données, les outils ou les permissions changent. Un résultat vaut pour la configuration testée ; il ne certifie pas toutes les versions futures.

Consignez assez d’éléments pour reconstituer la décision, sans transformer la piste d’audit en une nouvelle copie de toute la boîte de réception. Privilégiez des références stables aux fiches, les détails d’action nécessaires, les versions des règles et des éléments de preuve dont l’accès est contrôlé. Confiez à une personne la responsabilité d’enquêter sur les destinations bloquées, les exports inattendus et les échecs répétés de validation.

Quelles promesses sont exagérées, et quels problèmes restent ouverts ?

Aucun modèle, prompt, filtre ou produit de protection ne doit être considéré comme une solution complète. L’OWASP précise que la génération augmentée par récupération et le fine-tuning ne permettent pas de neutraliser entièrement l’injection de prompt. La génération augmentée par récupération, ou RAG, fournit des documents pour aider le modèle à répondre ; elle ne donne pas à ces documents le droit de modifier la tâche.

Un prompt système plus solide peut améliorer le comportement. Il ne peut pas restreindre des identifiants aux droits étendus. Un classificateur peut signaler un contenu suspect. Il ne peut pas décider si tel salarié est autorisé à divulguer telle pièce jointe. Faire vérifier le premier modèle par un second ajoute un contrôle, mais ne dispense pas de règles indépendantes appliquées par l’application.

Il n’existe pas non plus de taux de détection universel qui permette de savoir si votre agent de messagerie est prêt. Les limites utiles dépendent du workflow : les comptes qu’il peut lire, les champs qu’il peut modifier, les destinations possibles des données et les actions soumises à validation. Un résultat obtenu par un fournisseur sur une autre tâche ne prouve pas que votre circuit de validation est impossible à contourner.

L’affirmation défendable est plus modeste et plus utile : des contrôles à plusieurs niveaux réduisent l’exposition et limitent les conséquences, tandis que les tests et la surveillance font apparaître les défaillances. Un risque résiduel demeure.

Agissez maintenant si un agent lit déjà des contenus externes et peut divulguer des informations privées ou modifier des données métier. Attendez avant d’élargir son autonomie tant que les permissions, les validations et la gestion des échecs ne sont pas imposées par le système. Les conséquences possibles d’un outil qui résume des documents publics, sans données privées ni outils d’action, sont plus limitées, mais ses réponses doivent tout de même être protégées contre les manipulations.

Questions fréquentes

Comment se protéger contre les attaques par injection de prompt ?

Limitez l’accès aux données et aux outils, séparez les contenus non fiables des instructions, validez les sorties et les actions, imposez une vérification des opérations à fort impact et surveillez les résultats. Faites respecter les permissions en dehors du modèle ; aucune couche de protection ne supprime le risque à elle seule.

Quel est un exemple de prompt ?

« Résume l’e-mail de ce prospect et prépare une réponse à faire valider » est un prompt ordinaire. L’e-mail du prospect est un contenu nécessaire à la tâche, pas une autorisation de modifier la demande.

L’injection SQL est-elle encore utilisée ?

Oui. L’injection SQL reste un risque pour les applications qui construisent des requêtes de base de données non sécurisées. Elle nécessite des défenses propres aux bases de données, en complément des éventuels contrôles contre l’injection de prompt ; consultez les recommandations de l’OWASP sur les injections.

Qu’est-ce qu’une injection en programmation ?

En sécurité, on parle d’injection lorsqu’une entrée non fiable modifie ce qu’un interpréteur exécute ou traite. L’injection de prompt vise le comportement d’un modèle ; d’autres failles d’injection ciblent les requêtes de base de données, les commandes ou le code exécuté dans le navigateur.

Comment expliquer simplement une injection ?

Une entrée franchit une limite et se retrouve traitée comme une instruction qu’elle n’a jamais été autorisée à donner.

Quels sont les différents types d’injection de code ?

On peut citer l’injection SQL, l’injection de commandes du système d’exploitation et l’injection de scripts. Les défenses dépendent de l’interpréteur concerné. L’injection de prompt pose elle aussi un problème de séparation entre ce qui est fiable et ce qui ne l’est pas, mais elle n’est pas synonyme de toutes les injections de code.

Quels sont les différents types d’injection de prompt ?

La principale distinction porte sur le point d’entrée : l’attaque directe arrive par la saisie de l’utilisateur ; l’attaque indirecte, par un contenu récupéré par l’application. Du texte dans une image ou dans un autre média peut aussi contenir des instructions ; le point d’entrée et le format du support sont deux dimensions différentes.

Quels sont les 7 principaux types de hackers ?

Les catégories de hackers ne constituent pas une politique de permissions utile pour un agent. Fondez les contrôles sur l’identité authentifiée, les personnes capables d’influencer le contenu et les éléments auxquels l’application peut accéder ou qu’elle peut modifier.

Que sont le DDoS et l’injection SQL ?

DDoS signifie déni de service distribué : une attaque contre la disponibilité menée depuis des sources réparties. L’injection SQL manipule les requêtes de base de données. Ce sont des problèmes distincts de l’injection de prompt ; les recommandations de l’OWASP sur le déni de service abordent les protections de la disponibilité.

Par quoi commencer lundi ?

Choisissez un workflow de messagerie ou de CRM déjà en service et recensez les données, les outils et les destinations externes auxquels il peut accéder. Supprimez les accès inutiles, faites attendre les actions lourdes de conséquences jusqu’à la validation de leur contenu exact et démontrez qu’une proposition refusée ne produit aucun effet externe. N’élargissez l’autonomie qu’une fois la tâche utile et les mécanismes de refus tous deux opérationnels.

Retrouvez des guides pratiques pour créer des workflows d’IA dans la newsletter.