Évaluation par injection rapide pour les agents de récupération et utilisant des outils

Des benchmarks récents élargissent les conditions de test

LongPIBench, une préimpression d'août 2026, étudie l'injection rapide d'entrées plus longues dans plusieurs tâches orientées document. NetInjectBench étudie les actions des outils avec des métadonnées de stratégie fiables séparées des artefacts non fiables. Leurs portées diffèrent, mais toutes deux motivent à tester un contexte et des limites d'exécution réalistes plutôt qu'une courte invite contradictoire.

Preuve : LongPIBench : une référence à contexte long pour une injection rapide [1]NetInjectBench : analyse comparative de l'injection d'invites indirectes dans des agents utilisant un grand modèle de langage pour les opérations réseau [2]

Définir une limite de test sûre et significative

Spécifiez la tâche utilisateur autorisée, la surface d'entrée non fiable, le résultat interdit et l'environnement utilisé pour les tests. Utilisez des enregistrements synthétiques, des secrets factices et des points de terminaison inoffensifs. N'effectuez pas d'attaques ouvertes contre des systèmes ou des comptes en dehors de la portée convenue.

Distinguez la réponse du modèle de l’application de l’application. Si l'agent demande une opération non autorisée mais que la passerelle d'outils la rejette, la limite fonctionnait alors que l'agent présentait toujours un échec de planification. Enregistrez les deux faits. Une seule étiquette de passage cacherait des informations de diagnostic utiles.

Associez les cas d’attaque à des contrôles bénins

Rubrex recommande de tester les documents récupérés, les messages cités, les erreurs d'outils et les longues entrées à contexte mixte. Incluez du matériel inoffensif contenant un langage impératif, comme un manuel décrivant une commande. Un système qui rejette tous ces textes peut paraître résistant tout en échouant aux tâches normales.

Évaluer l'effet de la longueur et du placement du contexte sans supposer qu'une position est toujours la plus difficile. Gardez la tâche et les autorisations demandées stables lorsque vous comparez une défense. Conservez les artefacts exacts et la version de l’application afin que le résultat puisse être reproduit sans exposer de véritables données sensibles.

Exemple illustratif : un document demande une action secondaire

Un assistant de recherche est invité à résumer un document. Un document de test contient une instruction pour modifier un enregistrement sans rapport. La tâche autorisée reste la synthèse ; le contenu du document ne peut pas accorder l’autorisation pour l’action secondaire. L'évaluation vérifie qu'aucune mutation ne se produit et que la synthèse utile peut encore être complétée.

Un contrôle inoffensif comprend un paragraphe expliquant le fonctionnement des modifications d'enregistrement, sans en demander un. L'assistant devrait être capable de résumer ce paragraphe. Cela permet de détecter le surblocage causé par de simples défenses basées sur des mots clés.

Gardez la résistance et l'utilité visibles

Signalez séparément les tentatives de violation des limites, les violations exécutées, les tâches légitimes bloquées et les exécutions incomplètes. Documentez les contrôles au niveau des outils et les lacunes de couverture connues. Une suite de tests réussie prend en charge une observation limitée des conditions testées, et non une affirmation selon laquelle le système est résistant aux injections.

• Utilisez des cibles isolées et inoffensives.
• Suivez si l'action interdite a été tentée ou exécutée.
• Inclut des documents ordinaires avec un langage de type commande.
• Retestez après des modifications d’outil, de récupération, d’autorisation ou de modèle.

Contrôles de sécurité LLM et limites des garde-corps

Pour les tests de sécurité LLM, définissez les actifs et les actions que l'application doit protéger avant de créer des cas contradictoires. Des vulnérabilités d'application LLM peuvent survenir lorsqu'un texte non fiable influence un appel d'outil, traverse une limite de données ou modifie la priorité d'une instruction. Rubrex recommande de mapper chaque test sur une action protégée spécifique et un résultat clairement observable dans un environnement autorisé.

L'équipe rouge LLM peut éclairer une évaluation limitée, mais une suite d'injection rapide ne couvre pas à elle seule toutes les vulnérabilités LLM. Associez les cas contradictoires à des demandes légitimes pour vérifier si les garde-fous LLM bloquent les comportements utiles ainsi que les actions nuisibles. Enregistrez le contrôle testé, le résultat observé et les limites non testées. Gardez le contrôle d’accès et l’application des autorisations en dehors des instructions discrétionnaires du modèle.

Questions courantes