Injection de prompt indirecte : cadrer un agent IA connecté

Un email arrive dans une boîte partagée. Il contient une demande banale, une signature, un lien et du texte cité. Un agent IA le lit pour préparer une réponse. Le risque commence ici : le contenu vient d’un tiers, mais il entre dans le même contexte que les instructions données à l’agent.

Une injection de prompt indirecte est une instruction introduite via une ressource contrôlée ou influencée par un tiers, plutôt que saisie directement par l’utilisateur. Cette ressource peut être un email, un document, une page web, un dépôt de code ou la sortie d’un outil.[1][2] Le modèle peut alors traiter comme une consigne ce qui devait rester une donnée à analyser.

Le bon réflexe n’est pas de chercher un prompt « inviolable ». Il faut décider ce que l’agent peut atteindre après avoir lu un contenu non fiable, puis placer des limites hors du modèle.

Décision avant connexion

Si une source externe peut influencer l’agent, séparez au minimum la lecture, la préparation d’un brouillon et l’exécution. Un même appel ne devrait pas transformer silencieusement un texte reçu en action métier.

Cadrer un agent connecté

Injection directe ou indirecte : la différence utile

Dans une injection directe, une personne essaie de détourner l’agent dans son échange avec lui. Dans une injection indirecte, la consigne arrive cachée dans le matériau que l’agent doit traiter. La définition du NIST repose précisément sur ce contrôle d’une ressource.[1]

Cette différence change le périmètre de conception. Filtrer uniquement le champ de saisie de l’utilisateur ne couvre pas un agent qui ouvre une pièce jointe, consulte un site ou lit le résultat d’un connecteur. Le NCSC rappelle aussi qu’un modèle ne crée pas, à lui seul, une frontière de sécurité robuste entre instructions et données réunies dans un prompt.[4]

Il ne faut pas pour autant considérer chaque document comme une attaque. Il faut le considérer comme non fiable par défaut. L’agent peut en extraire des faits, mais ce contenu ne doit pas obtenir automatiquement le droit de changer les règles, d’élargir les permissions ou de déclencher une action sensible.

Le vrai risque : ce que l’agent peut faire après avoir lu

Une injection sans capacité d’action peut produire une mauvaise réponse. La même injection devient plus préoccupante si l’agent peut consulter des données privées, appeler des outils ou communiquer vers l’extérieur. Le NIST décrit l’agent hijacking dans des scénarios où des agents traitent des emails, des sites ou des dépôts et peuvent être détournés vers des actions non prévues.[2]

Pour cadrer le risque, posez ces questions dans cet ordre :

1. Quelle source externe entre dans le contexte ?
2. Quelles données l’agent peut-il consulter à ce moment-là ?
3. Quels outils, destinations et actions sont accessibles ?
4. Quelle règle indépendante autorise ou refuse l’action ?
5. Qui peut arrêter le flux et reprendre proprement ?

Ce raisonnement évite un faux débat sur la « qualité » abstraite du modèle. Un agent très capable, mais limité à un brouillon sans droit d’envoi, n’expose pas le même risque opérationnel qu’un agent moyen muni de droits larges et permanents.

Cartographier la frontière de confiance

Dessinez le flux avant de choisir les garde-fous. Une carte simple suffit :

source externe -> contenu non fiable -> extraction structurée -> règle déterministe -> lecture / brouillon / exécution

Sous cette ligne, notez quatre choses : les données accessibles, les identifiants utilisés, les sorties réseau possibles et la procédure d’arrêt. Vous obtenez une frontière testable, pas une promesse de sécurité.

Cette carte complète le travail sur la base de connaissances d’un agent IA. La base de connaissances traite la qualité, la fraîcheur et les droits des sources internes. Ici, le sujet est différent : une ressource externe peut-elle influencer une action ?

Séparer lecture, brouillon et exécution

La séparation la plus utile est souvent fonctionnelle.

• Lecture : l’agent consulte, classe ou extrait des éléments. Il ne modifie rien.
• Brouillon : il prépare une réponse ou une action, mais un autre composant conserve l’autorité d’exécution.
• Exécution : un outil borné réalise un changement explicitement autorisé, avec une destination et des paramètres vérifiés.

Un premier pilote peut rester sur les deux premiers niveaux. L’agent lit un email et prépare une réponse, sans pouvoir l’envoyer, supprimer un message, publier, payer, changer des permissions ou écrire en production. Ce choix ne supprime pas le risque de contenu erroné. Il réduit ce que cette erreur peut produire immédiatement.

Le NCSC recommande d’ajuster les contrôles au niveau d’autonomie, de limiter les permissions et les identifiants, d’isoler l’environnement et de conserver un moyen d’arrêter l’activité autonome.[3] Le guide de l’ANSSI place lui aussi le moindre privilège, le cloisonnement et la défense en profondeur parmi les principes à adapter au système concerné.[6]

Mettre les décisions critiques hors du modèle

Le modèle peut proposer une intention, extraire des champs ou signaler un doute. Il ne devrait pas être seul à décider qu’une action sensible est autorisée.

Une règle déterministe peut vérifier une destination autorisée, le type d’action, les champs obligatoires et la présence d’une approbation. L’outil peut aussi refuser toute capacité non déclarée. Ces contrôles restent compréhensibles même si le texte d’entrée change.

La documentation d’OpenAI, à lire comme une recommandation fournisseur, déconseille notamment de placer des données non fiables dans des instructions privilégiées et recommande des sorties structurées pour limiter la circulation de texte libre entre étapes.[7] Ce sont des réductions de surface d’attaque, pas une garantie. Le NCSC indique que les protections intégrées au modèle peuvent être contournées ou insuffisantes seules dans les environnements plus risqués.[3]

Une validation doit montrer le changement exact

Une fenêtre « Autoriser ? » n’est pas une validation utile si la personne ne voit pas la conséquence. L’écran d’approbation devrait montrer :

• la source qui a déclenché le flux ;
• les données utilisées pour préparer l’action ;
• le destinataire, l’outil et le changement exact ;
• les champs qui partiront vers l’extérieur ;
• la possibilité de corriger, refuser ou escalader.

Le placement de cette étape dépend du risque. L’article sur les workflows IA avec validation humaine détaille ce choix. Pour l’injection indirecte, le point essentiel est plus étroit : l’approbateur ne doit pas valider à l’aveugle une action dérivée d’un contenu externe.

Tester avec du contenu hostile ou ambigu

Les tests ne doivent pas contenir seulement des emails propres et des pages bien structurées. Ajoutez des documents contradictoires, du texte cité, des instructions qui ressemblent à des règles internes et des demandes hors périmètre. Restez sur des scénarios non offensifs : le but est de vérifier le comportement du système, pas de publier des recettes de contournement.

Pour chaque scénario, observez si l’agent :

• conserve la source comme donnée non fiable ;
• respecte ses droits de lecture ou de brouillon ;
• demande une approbation avant l’action ;
• refuse une destination ou une capacité non autorisée ;
• produit une trace qui permet de comprendre l’arrêt.

OWASP présente les risques agentiques comme un sujet distinct des seules erreurs de réponse et propose un cadre pour les agents qui planifient et agissent dans des workflows.[5] Ce cadre est utile pour construire une campagne de tests, mais il ne vaut ni certification ni preuve qu’un agent est « sécurisé ».

Observer, couper, reprendre

Même un périmètre bien borné garde un risque résiduel. Prévoyez donc le fonctionnement du jour où le flux doit être interrompu.

Les traces doivent relier la source, l’extraction, la décision de politique, l’approbation et l’action réellement exécutée. Les détails d’observabilité d’un agent IA méritent un chantier dédié ; ici, exigez au moins de savoir quelle ressource externe a influencé quelle proposition.

L’arrêt doit aussi couvrir les outils et les communications, pas seulement le processus du modèle. Le NCSC recommande de pouvoir interrompre l’activité autonome et restreindre rapidement les accès réseau ou les communications associées.[3] La reprise demande ensuite un état connu : action annulée si possible, identifiants renouvelés si nécessaire, cas isolé et règle corrigée avant redémarrage.

Le test de décision avant connexion

Avant de donner à un agent un accès à une boîte mail, un navigateur ou un outil métier, vérifiez que l’équipe peut répondre oui à ces questions :

• Les contenus externes sont-ils marqués comme non fiables dans l’architecture ?
• Les droits de lecture, brouillon et exécution sont-ils séparés ?
• Une règle hors modèle contrôle-t-elle les actions sensibles ?
• L’approbation montre-t-elle la conséquence exacte ?
• Les outils refusent-ils ce qui sort du périmètre ?
• Peut-on relier une action à sa source, l’arrêter et reprendre ?

Si une réponse manque, réduisez le périmètre. Le cahier des charges d’un agent IA support peut ensuite formaliser le reste du projet.

Vous voulez connecter un agent à des emails, documents ou outils métier ? Last Word peut cadrer les sources, les droits, les actions, les validations et la reprise avant le prototype. Consultez le service agent IA support ou décrivez votre contexte.

Questions fréquentes

Qu’est-ce qu’une injection de prompt indirecte ?

C’est une instruction qui atteint le modèle via une ressource contrôlée ou influencée par un tiers, comme un email, un document, une page web ou la sortie d’un outil.[1][2] Elle ne vient pas directement de la personne qui utilise l’agent.

Faut-il empêcher un agent de lire tout contenu externe ?

Non. Il peut lire, classer ou extraire des champs sans recevoir pour autant le droit d’agir. La limite utile consiste à séparer lecture, brouillon et exécution.

Une validation humaine suffit-elle avant l’exécution ?

Non. La personne doit voir la source, la destination et le changement exact, mais l’outil doit aussi appliquer ses propres règles de permissions, de schéma et de périmètre.

Quel périmètre choisir pour un premier pilote ?

Commencez par la lecture et la préparation d’un brouillon, sans droit d’envoi ni de modification. Vous pourrez ensuite ouvrir une action précise si sa destination, ses paramètres, son approbation et sa procédure d’arrêt sont vérifiables.

Sources

[1] https://csrc.nist.gov/glossary/term/indirect_prompt_injection — NIST CSRC, « indirect prompt injection », source NIST AI 100-2e2025, consulté le 31 août 2026. [2] https://www.nist.gov/blogs/caisi-research-blog/insights-ai-agent-security-large-scale-red-teaming-competition — NIST CAISI, « Insights into AI Agent Security from a Large-Scale Red-Teaming Competition », 23 mars 2026, consulté le 31 août 2026. [3] https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai — NCSC, « Managing the cyber risk of agentic AI », 20 août 2026, mis à jour le 24 août 2026, consulté le 31 août 2026. [4] https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection — NCSC, « Prompt injection is not SQL injection (it may be worse) », 8 décembre 2025, consulté le 31 août 2026. [5] https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026 — OWASP GenAI Security Project, « OWASP Top 10 for Agentic Applications for 2026 », 9 décembre 2025, consulté le 31 août 2026. [6] https://messervices.cyber.gouv.fr/documents-guides/Recommandations_de_s%C3%A9curit%C3%A9_pour_un_syst%C3%A8me_d_IA_g%C3%A9n%C3%A9rative.pdf — ANSSI, « Recommandations de sécurité pour un système d’IA générative », version 1.0 du 29 avril 2024, consulté le 31 août 2026. [7] https://developers.openai.com/api/docs/guides/agent-builder-safety — OpenAI Developers, « Safety in building agents », date non affichée, consulté le 31 août 2026. Recommandation fournisseur.