Liste de contrôle de durcissement contre les injections de prompts pour les équipes LLM et d'agents

1. Inventaire de chaque canal d'instruction

Avant de durcir, cartographiez les endroits où les chaînes de caractères deviennent des instructions. Les canaux typiques incluent les invites de système chargées côté serveur, les messages des développeurs dans les API de chat, les morceaux de documents récupérés, les charges utiles de retour d'outils, les corps de webhooks, les forwards d'e-mail et les champs de métadonnées que les utilisateurs ne voient pas mais que les modèles lisent encore. Ne pas inclure un canal garantit un point aveugle que les attaquants vont sonder.

Documentez chaque canal avec le propriétaire, la classification des données et si le contenu est contrôlé par l'utilisateur final. Marquez les canaux qui peuvent contenir du HTML, du markdown, du code ou du JSON sérialisé séparément - les astuces d'encodage se regroupent là. Réexaminez l'inventaire trimestriellement ou chaque fois que vous ajoutez des plugins.

2. Séparez la politique des données non fiables

La politique du système devrait vivre dans des modèles contrôlés par le serveur que les utilisateurs ne peuvent pas éditer. Le contenu non fiable doit arriver à l'intérieur d'enveloppes clairement étiquetées : balises XML, champs JSON ou sections markdown dont les titres indiquent qu'ils ne sont pas des directives. Ne jamais interpoler le texte de l'utilisateur dans la chaîne de système sans échappement et sans séparation structurelle recommandée dans la feuille de triche OWASP.

Pour RAG, stockez les citations séparément des phrases impératives lorsque cela est possible. Les pipelines de récupération devraient supprimer les balises de script et les attaques d'homoglyphe avant de les intégrer. Si votre pile doit intégrer des morceaux, préfixez un avertissement fixe que le texte du morceau est uniquement de référence.

3. Minimisez l'agentivité du modèle sur les actions sensibles

Chaque autorisation d'outil est un paiement d'injection. Listez les outils qui lisent des secrets, envoient des e-mails, déplacent de l'argent ou modifient les configurations de production. Exigez une confirmation humaine, une authentification à plusieurs niveaux ou des chemins de code déterministes pour ces actions. Les agents qui peuvent parcourir des URL arbitraires et publier des résumés internes ont besoin de limites plus serrées que les bots de FAQ.

Appliquez le principe du moindre privilège aux étendues OAuth qui soutiennent les outils. Faites pivoter les jetons et auditez quelles personnes agent peuvent invoquer quelles API. Une injection qui ne peut atteindre qu'un index de FAQ en lecture seule fait moins de dégâts qu'une injection attachée à une API de déploiement.

4. Validez et normalisez les entrées tôt

Définissez des longueurs maximales par champ, rejetez les charges utiles binaires inattendues et normalisez l'Unicode à une forme canonique avant la tokenisation. Bloquez ou supprimez les caractères de contrôle connus que certains modèles traitent de manière étrange. La validation appartient au code d'application, et non à la prose d'invite espérant que le modèle sera « sécurisé ».

Pour les téléchargements, exécutez un antivirus et une détection de type ; ne faites pas confiance aux extensions. Convertissez les documents en texte dans un bac à sable avec des délais d'attente. Enregistrez les échecs de conversion au lieu de les supprimer silencieusement à des chaînes vides qui pourraient plus tard être remplacées par le contenu de l'attaquant lors d'une répétition.

5. Exécuter une régression d'injection déterministe

Maintenir un corpus d'exemples malveillants et bénins. Exécuter PromptShield ou des moteurs de règles équivalents dans CI lorsque les invites, les outils ou les configurations de récupération changent. L'ensemble de règles prompt-injection@2026-07-19.2 couvre les familles de phrases, les personnages de jailbreak, les attaques de délimiteurs et les formulations d'exfiltration courantes - l'étendre avec des incidents internes.

Traiter la régression comme des tests unitaires : échouer un exemple d'attaque connu est un bloqueur de fusion. Passer tous les exemples est nécessaire mais pas suffisant ; les paraphrases nouvelles nécessitent une architecture et une surveillance. Publier les modifications du corpus dans les demandes de tirage pour que les réviseurs voient l'intention.

6. Renforcer les chemins de jailbreak et sociaux

Les jailbreaks exploitent l'empathie et l'autorité : fausses urgences, suppliques pour aider un enfant, allégations de statut de personnel OpenAI ou scénarios de jeu de rôle demandant au modèle d'ignorer les politiques éthiques. Former les équipes de support et de PM pour ne pas intégrer le langage de contournement dans les macros. L'éducation des utilisateurs réduit les auto-jailbreaks accidentels même en l'absence de malice.

Aligner les refus et les copies d'escalade avec ce que votre backend impose réellement. Si le modèle s'excuse mais que les outils exécutent toujours, les utilisateurs apprennent que les garde-fous textuels sont du théâtre. Faire correspondre les limites narratives aux limites techniques.

7. Contrôler l'injection indirecte dans la récupération

Les attaquants empoisonnent les wikis partagés, les sections de commentaires ou les pages SEO que vous crawl. Signer les documents de confiance ; vérifier les signatures avant l'indexation. Down-ranker ou exclure les pages générées par l'utilisateur des corpus de haute confiance. Surveiller les changements lexicaux soudains dans le contenu indexé qui pourraient indiquer une activité de campagne.

Au moment de la réponse, afficher aux utilisateurs quels morceaux ont influencé une réponse pour qu'ils puissent repérer les citations absurdités. Lorsque les morceaux contiennent des phrases impératives, envisager un down-weighting heuristique à moins qu'ils soient corroborés par des sources de confiance.

8. Gestion de la sortie et résistance à l'exfiltration

Même les filtres d'entrée parfaits échouent parfois. Appliquer des politiques de sortie : bloquer les regex d'API, les noms d'hôte internes et les modèles de PII en bloc avant que les réponses n'atteignent les clients. Pour les agents, nettoyer les sorties d'outils avant de réintégrer la boucle de contexte du modèle. Limiter la quantité de texte qu'une seule session peut exporter vers des webhooks externes.

Désactiver le rendu de HTML brut dans le chat visible par l'utilisateur lorsqu'il n'est pas requis. Les liens Markdown peuvent appeler à la maison ; utiliser des domaines autorisés ou supprimer les liens dans les modes d'entreprise.

9. Journalisation, confidentialité et rétention

Enregistrez les tentatives d'injection avec des charges utiles hachées, des ID de règles et des métadonnées de canal - et non nécessairement les secrets complets que les utilisateurs ont collés par erreur. Définissez une rétention conforme au GDPR sur la base d'un intérêt légitime ou d'un consentement, documentez-la dans les avis de confidentialité et prenez en charge les demandes de suppression. La surveillance de la sécurité doit respecter la minimisation des données.

Fournissez aux ingénieurs de garde des carnets de route distinguant les scanners, les blocages WAF et les refus de modèle. Les tempêtes de faux positifs doivent être ajustables sans désactiver complètement la journalisation.

10. Cahiers de jeux de réponses aux incidents

Lorsque l'injection réussit, gélez les versions d'agent affectées, faites pivoter les informations d'identification qui pourraient avoir fui et capturez les invites pour une analyse post-mortem. Informez les clients si leurs données ou locataires ont été impactés selon les conseils de vos conseillers juridiques. Mettez à jour le corpus avec la variante de charge utile réussie et ajoutez des mappages de feuille de triche.

Pratiquez des exercices de tableau twice par an. Incluez les services juridiques, PR et réussite client - et non seulement les ingénieurs. Les incidents LLM s'aggravent rapidement lorsque les agents peuvent agir de manière autonome.

11. Angles multi-locataires et de chaîne d'approvisionnement

Les produits SaaS doivent isoler les index de récupération des locataires et les magasins de mémoire. Les fine-tunes partagés ou les caches de invites de système partagés peuvent contaminer les instructions. Les plugins tiers introduisent des risques de chaîne d'approvisionnement ; vérifiez les éditeurs et épinglez les versions.

Lors de l'intégration d'agents externes via des protocoles tels que MCP ou similaires, traitez les descriptions d'outils à distance comme des entrées non fiables - ce sont des invites sous un autre nom.

12. Matrice de tests (staging)

Pour chaque candidat de version, suivez cette matrice manuellement même si l'automatisation passe :

- Chaînes de remplacement directes dans le chat de l'utilisateur. - Instructions indirectes cachées dans les pieds de page PDF téléchargés. - Contournement d'arguments d'outils via des champs JSON imbriqués. - Persistance de mémoire de phrases hostiles à plusieurs tours. - Charges utiles codées (base64, hex, scripts mixtes). - Personas de jailbreak et mises à jour de stratégie fictives.

Enregistrez des captures d'écran pour les auditeurs. Notez lesquels des contrôles ont bloqué l'impact par rapport à ceux qui ont simplement produit un refus poli tandis que les outils fonctionnaient toujours - un refus sans application est une constatation.

13. Gouvernance et propriété

Attribuer un propriétaire transversal pour le suivi de. La sécurité définit les seuils ; la plateforme met en œuvre des portes ; le produit accepte les risques résiduels documentés dans les notes de publication. Les cadres supérieurs reçoivent des métriques trimestrielles : taille du corpus, éléments de durcissement ouverts, incidents, temps moyen de correction des modèles.

Éviter la « sécurité par démo ». Les captures d'écran marketing devraient refléter les mêmes restrictions d'outils que la production. Les modes administrateurs cachés pour les ventes invalident la confiance des clients s'ils sont découverts.

14. Utilisation des sorties de PromptShield dans les examens

Exporter les résultats de l'analyse comme artefacts de discussion attachés aux tickets de lancement. Chaque ligne signalée devrait être liée à un élément de checklist ci-dessus et à un ingénieur nommé. Fermer les éléments avec des preuves : demande de tirage, différence de configuration ou capture d'écran de surveillance - et non assurance verbale.

Lorsque PromptShield reste silencieux sur un échantillon inquiétant, traiter cela comme un écart de règles à évaluer - et non comme une preuve de sécurité. Proposer de nouvelles règles déterministes avec des balises de version suivant les conventions de nommage prompt-injection@2026-07-19.2.

15. Maintenance à long terme

S'abonner aux mises à jour OWASP GenAI et aux flux de recherche réputés. Ré-effectuer des recherches trimestrielles ; les dates de mitigation obsolètes sont des bogues. Lors de la mise à niveau des modèles, ré-exécuter la matrice complète - le tokenizer et le fine-tuning de la sécurité déplacent le comportement.

Budgetter du temps d'ingénieur pour l'hygiène du catalogue. Les attaquants itèrent ; votre checklist doit itérer plus vite que les cycles marketing mais honnêtement, sans promettre la perfection.

Traquer la dérive des règles de la même manière que vous traquez les CVE des dépendances : chaque nouvelle version de modèle ou connecteur d'outil gagne un court passage de régression contre les trois dernières semaines de tickets réels, et non seulement des corpora synthétiques. Préférer de petits paquets de règles versionnés à un filtre monolithique que personne n'ose toucher. Lorsqu'une règle se déclenche trop souvent en production, la déclasser en avertissement avec un ticket - ne pas supprimer silencieusement la couverture pendant un week-end de garde.

16. Garde-fous d'accessibilité et d'UX

Les interfaces de chat compatibles avec les lecteurs d'écran exposent toujours des instructions cachées dans les étiquettes ARIA et le texte de remplacement que les attaquants peuvent manipuler. Examinez ces champs dans votre modèle de menace. Les suggestions d'autocomplétion ne doivent pas préfixer silencieusement les directives système dérivées de l'historique non fiable.

Les clients mobiles qui mettent en cache les brouillons hors ligne peuvent rejouer des chaînes hostiles obsolètes lorsque la connectivité revient ; effacer les brouillons risqués après les mises à jour de stratégie. Les équipes UX devraient coordonner avec la sécurité avant d'expédier des invites « amusantes » qui ressemblent à des modèles de jailbreak.

Tableau de référence rapide

- Scope de : injection directe et indirecte contre les applications et les agents. - Sources principales : page OWASP + feuille de triche de prévention d'injection de prompt. - Rôle de PromptShield : modèle déterministe + régression de jailbreak sur les échantillons. - Étiquette de jeu de règles : prompt-injection@2026-07-19.2. - Résultat : tâches de durcissement prioritaires — et non une note de pentest pass/fail.

Références

- OWASP : 2025 — Injection de prompt - Feuille de triche de prévention d'injection de prompt OWASP LLM

PromptShield ouvert

Mis à jour 2026-09-26 · checklist pour la prise de décision · aucune garantie de couverture complète