Injection de prompt

Une injection de prompt tente de faire suivre à une IA des instructions qu’elle ne devrait pas considérer comme autorisées. Ces instructions peuvent apparaître dans une demande, un document, une page ou un résultat d’outil. L’attaque cherche à détourner la tâche, à obtenir des informations ou à provoquer une action. Le contenu consulté devient ainsi un moyen d’influencer le comportement.

Le risque est particulièrement important lorsque l’IA utilise des outils. Une mauvaise réponse textuelle et une opération sur une application n’ont pas les mêmes conséquences. Les permissions doivent limiter ce que le système peut faire même si le modèle se laisse influencer.

Une injection directe est placée dans l’échange avec le système. Une injection indirecte se trouve dans une source que l’IA consulte : document partagé, message ou page web, par exemple. L’utilisateur peut demander une synthèse normale tandis que la source contient une consigne qui tente de détourner le traitement.

La consigne peut imiter une instruction administrative ou demander d’ignorer les règles précédentes. Elle peut aussi chercher à modifier discrètement une conclusion. Il ne faut pas se limiter aux formulations évidentes : un contenu externe reste une donnée à examiner, même lorsqu’il semble rédigé comme une procédure.

Un assistant limité à la lecture peut produire une synthèse trompeuse ou exposer des informations dans sa réponse. Un agent disposant d’écriture peut également tenter de modifier, envoyer ou supprimer des données. La séparation des fonctions et les validations réduisent la portée d’une erreur.

La protection ne repose pas sur une phrase unique dans les instructions. Il faut des contrôles dans les outils : permissions adaptées, destinations vérifiées et actions limitées. Une confirmation doit présenter l’opération concrète et son périmètre pour que la personne puisse la vérifier.

Imaginons une équipe qui demande à un assistant de résumer une proposition reçue. Le document contient une phrase qui lui ordonne de transmettre le dossier à une adresse externe. Cette phrase fait partie du contenu à analyser ; elle ne constitue pas une autorisation de l’utilisateur.

Le système doit continuer la tâche de lecture et empêcher l’envoi non autorisé. Si un outil d’envoi existe, ses contrôles doivent exiger une instruction légitime et une destination vérifiée. L’équipe peut aussi signaler la présence d’un contenu suspect dans le document.

Ce scénario est illustratif. Il ne faut pas tenter une attaque sur un service tiers pour tester son propre usage. Un document de test maîtrisé permet d’observer le comportement dans un environnement adapté, sans exposer de données réelles ni provoquer une action externe.

Limitez les outils aux opérations nécessaires. Séparez la consultation d’une source de l’autorisation d’une action. Vérifiez les paramètres importants avant l’exécution : ressource, destinataire et contenu. Pour les opérations sensibles, prévoyez une validation humaine au bon moment.

Les sources externes doivent conserver leur statut de données. Un texte trouvé sur le web ne doit pas devenir une règle d’administration. Les résultats d’outils et les pièces jointes doivent être traités avec la même prudence. Les restrictions techniques restent nécessaires même lorsque les instructions sont claires.

Aucun filtre isolé ne garantit l’absence d’injection. Les formes peuvent évoluer et les interactions être complexes. Le dispositif doit combiner permissions, contrôles d’action, tests et traces. Le comportement après une erreur compte aussi : un refus doit rester un refus, sans contournement automatique.

En cas de suspicion, arrêtez les actions concernées et examinez les accès et les journaux. Vérifiez ce qui a réellement été lu ou exécuté. Une conclusion sur l’incident doit s’appuyer sur des traces, pas uniquement sur une formulation étrange dans la réponse.

Dressez la liste des contenus que l’IA peut lire et des opérations qu’elle peut réaliser. Identifiez les situations où une source externe pourrait influencer une action. Réduisez les permissions avant d’ajouter des mécanismes de détection.

Préparez des documents de test avec des instructions hors sujet et des demandes d’action non autorisées. Vérifiez le refus des outils, la préservation de la tâche initiale et les traces disponibles. Utilisez des ressources sans données sensibles.

Définissez ensuite la validation des actions et la procédure de réponse à une anomalie. Les contrôles doivent rester compréhensibles pour les utilisateurs. Revoyez les tests lorsque de nouveaux outils, des destinations externes ou des droits d’écriture sont ajoutés.

L’injection de prompt fait partie des risques étudiés par le projet OWASP de sécurité des applications LLM.

Référence consultée le 10 octobre 2026.