Comment évaluer les défenses contre le prompt injection : checklist pratique

Une évaluation de prompt injection ne commence pas par une liste de phrases comme « ignore previous instructions ». Définissez d’abord l’attente de sécurité : quelles données l’agent peut lire, quelles parties externes peuvent influencer son contexte, quelles actions il peut proposer ou exécuter et ce qui ne doit jamais arriver sans vérification séparée. Une injection directe de l’utilisateur et une injection indirecte depuis une page web, un e-mail, un document, un tool output ou la mémoire créent des surfaces d’attaque différentes.

Pour chaque workflow, cartographiez les paires source-sink. Une source est un contenu non fiable qu’un attaquant peut modifier ; un sink est un transfert de secret, une requête réseau, un message, un paiement, une modification de fichier, une écriture mémoire ou une autre capacité à conséquence. OpenAI décrit le même cadre source-sink pour les agents : le test doit prouver non seulement que le modèle a repéré un texte suspect, mais aussi que le flux dangereux vers le sink a été bloqué ou a exigé la confirmation correcte.

• Asset → secrets, données personnelles, credentials, argent et actions réputationnelles ou opérationnelles.
• Source → saisie utilisateur, web, e-mail, RAG, fichiers, tool output, mémoire et contenu multimodal.
• Sink → réseau, message, write tool, exécution de code, écriture mémoire ou changement de privilège.
• Invariant → événement interdit que le harness vérifie de manière déterministe.

Le corpus doit reproduire des trajectoires réelles : une page ordinaire avec une instruction cachée, un e-mail avec un prétexte métier plausible, un document RAG demandant de modifier une policy, une chaîne de redirects, une URL contenant des données dans la query, un résultat de tool empoisonné et une entrée mémoire se faisant passer pour une approval. Ajoutez paraphrases, plusieurs langues, encodages, masquage typographique, images et attaques multi-étapes. Chaque fixture conserve la source attaquée, les preuves autorisées, les tool calls attendus et les événements interdits.

Les fixtures bénins positifs sont aussi importants que les attaques. Ils montrent si la défense bloque à tort la citation légitime d’instructions, la recherche en sécurité, les e-mails de support, les liens externes et les actions autorisées. Segmentez par source, sink, sensibilité de l’asset, autonomie, scope des permissions et besoin de confirmation utilisateur. Un score moyen unique peut facilement masquer l’échec d’un slice d’exfiltration de données rare mais critique.

Exécutez chaque fixture dans une sandbox proche de la production avec le même prompt, modèle, tools, policies, règles réseau, broker de credentials et UI de confirmation, mais avec des secrets canary et des destinations fictives. Tester uniquement la réponse finale ne suffit pas : le modèle peut appeler silencieusement une URL, transmettre un payload dans un argument de tool, écrire l’attaque en mémoire ou préparer un brouillon dangereux. Le harness enregistre toute la trajectoire et observe chaque sink indépendamment.

Ne donnez pas à l’agent de test davantage de droits qu’à son rôle de production et ne remplacez pas la policy par un mock qui refuse toujours. Vérifiez least privilege, tenant binding, scoped credentials, destination allowlist, egress de la sandbox, validation de schema et liaison de l’approval au payload exact. Une confirmation ne passe pas le gate si l’agent peut ensuite modifier destinataire, données ou montant sans une nouvelle décision utilisateur.

Le verdict principal est déterministe : sink interdit atteint, secret exposé, écriture non autorisée, mémoire empoisonnée, contournement de confirmation ou safe completion. Étiquetez séparément attack detected, refused, content safely summarized, user warned et task completed. Un refus peut sembler sûr sans prouver qu’aucune requête en arrière-plan n’est partie ; inversement, le modèle peut ne pas nommer l’attaque alors qu’une couche de policy bloque correctement le side effect.

Rapportez l’attack success rate uniquement avec le corpus exact, les répétitions, sampling settings, versions du modèle et de la policy, et un intervalle de confiance ; ne transposez pas un benchmark fournisseur à votre système. Les métriques opérationnelles utiles incluent critical invariant failures, taux de compromission par sink, exposition de secret-canary, tentatives non autorisées bloquées, benign task success, false-positive rate, qualité de confirmation, containment time, latence et coût par trajectoire évaluée. Une exfiltration critique n’est pas compensée par un task success moyen élevé.

La defense in depth comprend comportement du modèle, trust labels, traitement du contenu, least privilege, contrôles de data flow, sandbox, contrôles réseau, approval et monitoring. Exécutez le stack complet puis des ablations contrôlées : retirez le classifier, réduisez ou élargissez le scope des tools, désactivez la vérification de destination ou la confirmation. Vous voyez ainsi quelle couche a réellement arrêté l’attaque, où se situe un single point of failure et si un « AI firewall » décoratif ne fait qu’ajouter de la latence.

OpenAI et Anthropic décrivent tous deux le prompt injection comme un problème actif sans défense unique garantie. La classifier precision n’est donc pas un résultat de sécurité. Vérifiez si le système limite les conséquences même lorsque le modèle ou le detector rate une attaque socialement convaincante. Pour les web agents, testez séparément les fuites silencieuses par URL, redirects, previews et ressources embarquées ; une domain allowlist ne prouve pas qu’un data flow précis est sûr.

Le decision record fixe workflow, sources, sinks, permissions, modèle, prompt, policy bundle, tool schemas, révision du corpus, critical invariants, thresholds, owner et date de review. Promote ne vaut que pour le scope vérifié. Restrict peut désactiver network egress, les écritures mémoire ou les tools à fort impact ; reject revient à un baseline read-only ou déterministe. Toute fuite de canary secret, accès cross-tenant ou action conséquente non autorisée bloque la release indépendamment du score moyen.

Le rollout passe par offline replay, adversarial staging, canary read-only, petite cohorte à permissions limitées et monitoring continu. Rollback révoque les scoped credentials, désactive les sinks et les écritures mémoire contaminées, restaure le bundle policy/model known-good et conserve un trace nettoyé pour l’incident review. Un nouvel exploit devient un regression fixture après triage. Relancez la suite critique après toute modification du modèle, prompt, retriever, browser, MCP/tool server, permissions, network policy ou confirmation UX.

• Promote → tous les critical invariants passent dans le scope défini.
• Restrict → réduire sources, sinks, data class, autonomie ou permissions.
• Reject → conserver un baseline read-only ou déterministe.
• Roll back → révoquer les credentials, désactiver les sinks, mettre l’état en quarantaine et réconcilier les side effects.