Injection de prompt

Vous demandez à un agent de résumer une page. Le texte de cette page contient une instruction cachée qui lui demande d’envoyer des fichiers à une adresse externe. Le contenu devait être lu comme une donnée, mais le modèle peut le traiter comme une nouvelle consigne.

Une injection de prompt modifie le comportement ou la sortie d’un modèle par une entrée conçue ou interprétée comme une instruction. Elle est directe lorsqu’elle vient de la demande. Elle est indirecte lorsqu’elle se trouve dans une ressource externe comme un document, un courriel, une page ou une image. [S1]

Le détournement d’agent, ou agent hijacking, est une injection indirecte qui pousse un agent à accomplir une tâche non voulue. Le risque augmente avec les données accessibles, les outils disponibles et les effets que l’agent peut produire. [S2]

Traiter le problème comme une frontière de confiance

Un agent réunit souvent des instructions internes fiables et des contenus externes non fiables dans une même entrée. Le modèle ne fournit pas une séparation de sécurité parfaite entre les deux. Un texte externe peut donc influencer son raisonnement même s’il est placé entre des délimiteurs ou présenté comme une citation. [S1] [S2]

La protection ne consiste pas à trouver une phrase magique. Elle consiste à limiter ce qu’une entrée hostile peut lire, déclencher et modifier.

Surface	Question de contrôle
Contenu externe	Est-il clairement identifié comme non fiable ?
Contexte	Contient-il des secrets ou des données inutiles à la tâche ?
Outils	Chaque action est-elle limitée par des permissions et des paramètres contrôlés ?
Sortie du modèle	Est-elle validée avant d’être utilisée par du code ou un autre système ?
Effet réel	Une politique indépendante peut-elle bloquer une destination, une dépense ou une suppression interdite ?

Réduire l’impact par couches

Séparer les instructions et les données

Identifiez la provenance de chaque élément du contexte. Placez les règles du système, la demande et les ressources externes dans des champs distincts lorsque l’architecture le permet. Marquez les documents récupérés comme non fiables et demandez au modèle de ne pas suivre leurs instructions. Cette séparation aide le modèle, mais ne constitue pas à elle seule une frontière de sécurité. [S1] [S2]

Réduire les données exposées

N’incluez ni secret, ni jeton, ni historique complet dans le contexte si la tâche n’en a pas besoin. Filtrez les documents selon les droits avant qu’ils atteignent le modèle. Une injection ne peut pas faire révéler une donnée que le système n’a jamais fournie ou rendue accessible.

Limiter les outils

Donnez à chaque outil une opération étroite, des paramètres typés et les permissions minimales. Séparez lecture et écriture. Appliquez les autorisations dans le code ou le service cible, car le modèle ne doit pas décider seul s’il a le droit d’accéder à une ressource. OWASP recommande le moindre privilège et le traitement des fonctions sensibles par du code contrôlé. [S1]

Valider les sorties

Considérez la sortie du modèle comme non fiable. Vérifiez le format, les valeurs autorisées, la destination, le volume et les effets avant tout appel. Une sortie JSON conforme à un schéma peut encore contenir une commande interdite ou un destinataire non autorisé.

Borner les actions sensibles

Une politique indépendante doit arrêter les envois externes, suppressions, dépenses, modifications de droits ou exécutions de code qui dépassent le périmètre autorisé. Selon le risque, l’action peut demander une confirmation explicite par la personne concernée. Ce contrôle doit intervenir avant l’effet, pas après la réponse du modèle. [S1]

Surveiller sans exposer davantage

Conservez la provenance des ressources, les outils appelés, les décisions de politique et l’état final. Évitez d’enregistrer en clair les secrets ou documents complets. Les traces doivent permettre d’identifier une tentative et son impact sans devenir une nouvelle source de fuite.

Ce qui ne suffit pas

• Un prompt système plus ferme. Il peut orienter le modèle, mais une entrée hostile peut encore le détourner.
• Des délimiteurs autour du document. Ils clarifient la structure sans créer une isolation technique.
• Une liste de mots interdits. Une attaque peut être obfusquée, répartie entre plusieurs contenus ou cachée dans une autre modalité. [S1]
• Le RAG. La récupération améliore l’accès aux connaissances, mais un document retrouvé peut lui-même contenir l’injection. OWASP indique que le RAG et l’ajustement du modèle ne suppriment pas complètement la vulnérabilité. [S1]
• Une sortie structurée. Elle borne la forme, pas l’autorisation ni la vérité des valeurs.
• Un test réussi une fois. Les modèles sont probabilistes et les attaques peuvent être adaptées au système. [S2]

Évaluer le système dans son environnement

Créez des scénarios qui combinent une tâche légitime et une instruction malveillante dans chaque source réellement consultée : demande, document, courriel, page, image ou résultat d’outil.

Pour chaque scénario, vérifiez séparément :

1. La tâche utile. Le système accomplit-il encore la demande légitime ?
2. L’attaque. L’instruction externe est-elle ignorée ?
3. Les données. Une information interdite devient-elle visible dans la réponse, les paramètres ou les traces ?
4. Les outils. Un appel non autorisé est-il tenté ou exécuté ?
5. L’état final. Un fichier, un message, une permission ou une transaction a-t-il changé ?
6. La répétition. Le résultat reste-t-il sûr sur plusieurs tentatives ?

NIST recommande d’adapter les évaluations aux nouveaux systèmes, d’observer les attaques par tâche plutôt qu’un seul score moyen et de tester plusieurs tentatives lorsque l’attaquant peut recommencer. Une défense connue peut réussir sur un jeu de tests puis échouer contre une attaque conçue pour elle. [S2]

Ajoutez chaque échec réel au jeu d’évaluation. Mesurez à la fois le taux d’attaque réussie et le taux de tâches légitimes bloquées, car une protection qui arrête tout le système n’est pas utile.

Limites à garder visibles

• OWASP ne présente aucune méthode comme une prévention infaillible. Concevez donc le système pour contenir l’impact d’un détournement. [S1]
• Les filtres et classifieurs peuvent manquer une attaque ou bloquer un contenu légitime.
• Les attaques évoluent avec les modèles, les outils, les langues et les formats. Une évaluation doit être rejouée après chaque changement important. [S1] [S2]
• La séparation visuelle d’un contenu n’est pas une isolation de sécurité.
• Une action réversible et bornée reste moins risquée qu’un accès large à une opération définitive.
• Un agent sans secret ni outil d’écriture peut encore produire une réponse fausse. L’injection de prompt n’est qu’un des risques à évaluer.

Commencez par retirer les données et permissions inutiles. Ajoutez ensuite des validations déterministes autour des outils, puis testez des attaques adaptées à chaque source externe que le système peut lire.