Documents qui tentent de donner des instructions : limiter l’injection de prompts dans une application PHP

Une fonctionnalité qui répond à des questions sur des documents peut récupérer du texte pertinent et l’envoyer à un modèle d’IA. Ce texte n’est toutefois pas toujours inoffensif : un document, une page web ou un fichier fourni par un utilisateur peut contenir des phrases qui tentent de modifier la tâche, d’obtenir des informations auxquelles elles ne devraient pas avoir accès ou de provoquer une action. Ce risque est appelé injection de prompts dans des documents, ou injection indirecte, car les instructions sont intégrées au contenu traité et ne figurent pas nécessairement dans la question de l’utilisateur.

Pour atténuer ce risque, il ne suffit pas de trouver la formulation parfaite pour le message système. Il faut concevoir l’application de telle sorte que le contenu récupéré ne puisse pas modifier les autorisations, les politiques ni les décisions métier, et qu’une réponse du modèle ne constitue jamais à elle seule une autorisation d’agir.

Quel risque faut-il maîtriser ?

Un document peut contenir des instructions explicites, comme « ignore les instructions précédentes », ou un texte plus trompeur, comme une demande de révélation de données internes. Il peut aussi contenir des instructions dissimulées dans du contenu extrait de HTML, des commentaires, des métadonnées ou du texte généré par OCR. Si ces éléments sont mêlés sans distinction aux instructions de l’application, le modèle pourrait en suivre une partie, produire un résumé biaisé ou générer une réponse imprévue.

Le risque dépend de ce que la fonctionnalité peut faire. Un assistant qui rédige uniquement une réponse destinée à être vérifiée n’a pas le même impact qu’un assistant capable de consulter des comptes, d’émettre des remboursements ou d’envoyer des messages. Avant de rendre la fonctionnalité accessible aux utilisateurs, il faut définir les informations qu’elle peut recevoir, les réponses qu’elle peut produire et les conséquences qui peuvent en découler.

À elle seule, une injection ne prouve pas que les contrôles d’accès de l’application ont été contournés. Elle peut toutefois exposer des informations incluses à tort dans le contexte ou inciter le modèle à demander une opération. La protection doit couvrir les entrées, les données disponibles et les actions ultérieures.

Séparer les données des politiques et des autorisations

Le contenu récupéré doit fournir des éléments utiles à la réponse, et non devenir une source d’autorité. Un document peut décrire une politique d’entreprise, mais l’application doit déterminer séparément si l’utilisateur est autorisé à consulter ce document ou à effectuer une opération connexe. Cette décision ne doit être déléguée ni au texte ni à la réponse générée.

• Autorisation avant la récupération : appliquez les contrôles d’accès lors de la recherche et filtrez les documents en fonction de l’identité de l’utilisateur et de ses autorisations en vigueur.
• Contexte minimal : envoyez uniquement les extraits nécessaires à la tâche. N’incluez pas de données d’autres comptes, de secrets, d’informations d’identification ni d’informations dont le modèle n’a pas besoin.
• Politiques appliquées en dehors du modèle : calculez les autorisations, les limites et les conditions métier dans le code de l’application ou dans des services autorisés.
• Réponse à titre de proposition : traitez la sortie du modèle comme un contenu à valider, et non comme une instruction exécutable.

Une instruction système peut aider à exprimer le comportement attendu, par exemple en indiquant que le texte récupéré est une documentation de référence. Elle ne constitue pas une frontière de sécurité : elle ne garantit pas que le modèle ignorera les instructions malveillantes et ne remplace ni les contrôles d’accès, ni la validation, ni les restrictions techniques.

Concevoir le flux PHP avec des limites explicites

En PHP, il est préférable de séparer les étapes d’autorisation, de récupération, de construction du contexte, d’appel au modèle et de validation de la sortie. Cette séparation facilite la vérification de chaque limite et évite de relier directement un résultat d’IA à une opération sensible.

L’extrait suivant est un pseudocode illustratif, et non un appel exécutable à un client particulier. La façon de construire la requête et les champs acceptés dépendent de l’API et du SDK utilisés :

$user = $auth->currentUser();
$documents = $repository->searchAuthorized($user, $question);
$snippets = $contextBuilder->selectRelevant($documents, $maxItems);

// Pseudocode : adaptez la requête à l’API concernée.
$response = $aiClient->answer([
    'task' => 'Réponds en utilisant la documentation de référence ; n’autorise aucune action.',
    'untrusted_context' => $snippets,
    'question' => $question,
]);

$answer = $responseValidator->validate($response);
return $answer;

Les noms utilisés dans l’exemple sont donnés à titre indicatif. Étiqueter le contexte comme non fiable aide à en préciser le rôle, mais ne l’isole pas de manière infaillible : ni le format ni les instructions ne suffisent à empêcher le modèle de suivre une instruction intégrée. La séparation effective dépend également des données envoyées, des autorisations appliquées en dehors du modèle et des capacités disponibles.

Normalisez et limitez le contenu extrait avant de l’ajouter au contexte : fixez des tailles maximales, supprimez les formats dont vous n’avez pas besoin et traitez avec précaution le texte obtenu par OCR ou depuis des pages externes. Évitez de concaténer des documents sans limites et de joindre par défaut l’historique complet d’une conversation. Conservez une référence à la source de chaque extrait si vous devez expliquer ou auditer la réponse, sans inclure son contenu sensible dans les journaux.

Réduire l’impact d’une réponse manipulée

Limitez les outils accessibles au modèle à ceux dont la fonctionnalité concernée a besoin. Si la tâche consiste uniquement à répondre à des questions, ne lui accordez ni outils d’écriture ni accès général aux services internes. S’il doit consulter des données, exposez une opération circonscrite qui applique une autorisation pour chaque requête, plutôt que de lui fournir des identifiants d’authentification à privilèges étendus ou un accès arbitraire à une base de données.

Lorsque le modèle propose une action, l’application doit la valider dans un flux indépendant. Au moment de l’exécution, vérifiez l’identité, les autorisations, les paramètres, les règles métier et l’état actuel de la ressource. Pour les actions à fort impact, demandez une confirmation explicite ou une vérification humaine. Une réponse textuelle du modèle, même si elle semble sûre ou cite un document, ne remplace pas cette autorisation.

Validez également la sortie avant de l’afficher ou de la traiter : vérifiez le format attendu, limitez la longueur et rejetez les champs ou les valeurs non autorisés. Si une structure précise est attendue, analysez ses champs et validez-les à l’aide de règles déterministes. L’échappement de la sortie et les protections contre les injections dans HTML, SQL ou des commandes restent nécessaires ; la génération par IA ne rend pas le texte produit fiable.

Tester les attaques et les comportements attendus

Les tests doivent couvrir l’ensemble du flux, et pas seulement vérifier si le modèle répond correctement à une instruction système. Préparez des documents bénins et des documents adverses qui tentent de modifier la tâche, de demander des données non autorisées ou de provoquer une action. Prévoyez des variations du format source, comme du texte extrait de HTML, des documents longs et du contenu mêlant des instructions à des informations légitimes.

• Vérifiez que la recherche ne renvoie jamais de documents auxquels l’utilisateur n’a pas accès, même si la question demande explicitement ces données.
• Vérifiez que les documents adverses n’activent pas d’outils et ne modifient pas les règles métier.
• Confirmez qu’une réponse mal formée ou inattendue est rejetée et qu’une opération sensible nécessite une autorisation indépendante.
• Évaluez les réponses utiles et correctes produites à partir de documents bénins afin de détecter si les restrictions dégradent la fonctionnalité de manière inacceptable.
• Répétez les tests lorsque le modèle, le gabarit d’instructions, le système de récupération, les outils ou le processus d’extraction changent.

Définissez des critères d’acceptation observables : quelles données ne doivent jamais apparaître, quelles actions doivent rester bloquées et comment le système doit répondre lorsqu’il ne dispose pas de preuves suffisantes. Un test isolé ne garantit pas la sécurité, mais une batterie de tests répétable aide à détecter les régressions et à comparer les changements de configuration.

Enregistrer les signaux sans accumuler de données sensibles

Pour enquêter sur les défaillances, consignez les identifiants de requête, la version de la configuration, les identifiants ou références internes des documents consultés, les décisions d’autorisation, les outils appelés et le résultat des validations. Consigner une référence ne signifie pas stocker le document ni ses extraits. Évitez d’enregistrer des extraits sensibles, sauf en cas de besoin précis et avec des contrôles spécifiques d’accès, de protection et de conservation.

Ajoutez des métriques sur les rejets, les erreurs de format et les défaillances du fournisseur afin de distinguer les problèmes de sécurité des problèmes opérationnels. Évitez d’enregistrer automatiquement les prompts complets, les documents et les réponses s’ils contiennent des données personnelles, des secrets commerciaux ou des informations réglementées. Définissez les règles de conservation, d’accès et de masquage des données sensibles ; lorsque cela suffit, consignez des empreintes, des identifiants et des événements structurés. Veillez à ce que les journaux ne deviennent pas un nouveau moyen d’exposer le contenu que la fonctionnalité devait protéger.

Liste de vérification avant d’activer la fonctionnalité

• Les autorisations sont-elles vérifiées avant la récupération de chaque document ?
• Le contexte envoyé est-il minimal, circonscrit et traité comme une entrée non fiable ?
• Les politiques et les règles métier sont-elles appliquées en dehors du modèle ?
• Les outils sont-ils limités, et chaque opération vérifie-t-elle à nouveau les autorisations ?
• Les réponses sont-elles validées avant d’être affichées ou converties en actions ?
• Une vérification humaine ou une confirmation est-elle prévue pour les décisions à fort impact ?
• Existe-t-il des tests adverses répétables et des journaux dont la conservation est maîtrisée ?

Si la réponse à l’une de ces questions est négative, limitez la portée de la fonctionnalité ou maintenez les actions au stade de proposition jusqu’à ce que cette lacune soit comblée. La défense contre l’injection de prompts dans des documents ne dépend pas de la capacité du modèle à toujours bien interpréter le contenu : elle dépend du maintien des limites d’accès et d’opération, même lorsque le modèle se trompe.