La provenance au niveau des arguments arrête l'injection là où les défenses par appel échouent

De quoi s’agit-il ?

Le 11 mai 2026, des chercheurs de l’Université Renmin de Chine, de KAUST, de l’Université de finance et d’économie du Nord-Est et de l’USTC ont publié The Granularity Mismatch in Agent Security: Argument-Level Provenance Solves Enforcement and Isolates the LLM Reasoning Bottleneck. Sa thèse centrale reformule notre façon de penser l’injection indirecte : le danger n’est pas qu’un texte non fiable apparaisse dans le contexte d’un agent, mais qu’il soit autorisé à déterminer un argument porteur d’autorité d’un appel d’outil privilégié.

L’injection de prompt indirecte désigne le cas où un agent lit une donnée tierce — page web, e-mail, fichier récupéré, réponse d’API — et où cette donnée contient des instructions que l’attaquant veut voir exécutées. La tâche de l’utilisateur est légitime ; le canal de données ne l’est pas. La contribution du papier est de situer la frontière de sécurité plus précisément que les travaux antérieurs, et de construire un moniteur d’exécution autour de cette frontière.

Comment ça marche

Le point de départ du papier est un décalage de granularité. La plupart des défenses existantes arbitrent la confiance au niveau d’un appel d’outil entier : elles autorisent ou bloquent l’appel dans son ensemble. Prenons un agent chargé de résumer une page web et d’envoyer le résumé à un destinataire fixé. La page est censée déterminer le corps de l’e-mail : c’est la tâche. Elle ne doit jamais déterminer le destinataire. Une politique globale sur un appel comme send_email(recipient, body) ne peut pas exprimer cette distinction. Bloquez l’appel dès qu’un argument dépend de la page et vous détruisez le workflow légitime « récupérer puis agir » ; autorisez-le et une instruction injectée peut rediriger le destinataire vers l’attaquant.

La réponse des auteurs est PACT (Provenance-Aware Capability Contracts), un moniteur d’exécution qui déplace l’application à l’intérieur de l’appel d’outil. Chaque outil reçoit un contrat au niveau des arguments qui attribue des rôles sémantiques — target, command, credential, content — à ses arguments. Pendant l’exécution, PACT suit l’origine de chaque valeur à travers les étapes de replanification, et avant chaque invocation il vérifie si l’origine d’un argument satisfait l’exigence de confiance imposée par son rôle. Une donnée externe est autorisée à remplir un champ content comme un résumé ou un corps de rapport, mais bloquée pour lier un champ porteur d’autorité comme un destinataire, une URL, une commande shell, une requête de base de données, un chemin de fichier ou un identifiant. Point crucial : PACT n’est pas un détecteur de chaînes d’apparence malveillante — c’est une contrainte structurelle sur ce que la donnée non fiable a le droit de contrôler, qui tient même quand le texte hostile n’est pas parfaitement identifié.

Les résultats rapportés étayent le cadrage. Sous provenance oracle sur des suites de diagnostic à confiance mixte, PACT atteint 100 % d’utilité et 100 % de sécurité, tandis que les moniteurs au niveau de l’appel produisent des faux positifs, des faux négatifs, ou les deux. En déploiement complet sur AgentDojo et cinq modèles avec inférence automatique de provenance, PACT atteint 100 % de sécurité sur les trois modèles les plus forts tout en récupérant 38,1 à 46,4 % d’utilité, soit 8 à 16 points de plus que la référence CaMeL au même niveau de sécurité. Les ablations montrent que les deux ingrédients sont essentiels : retirez les rôles sémantiques et l’utilité bénigne s’effondre ; retirez la provenance inter-étapes et la sécurité échoue.

Pourquoi c’est important

La leçon pratique concerne l’endroit où tracer les frontières de confiance. Les défenses par appel entier imposent un choix binaire fragile entre sécurité et utilité, précisément parce qu’un même appel mélange souvent des arguments fiables et non fiables. Reformuler l’injection comme un problème de liaison d’autorité dissout ce compromis, en principe. PACT nomme aussi honnêtement sa propre faiblesse résiduelle : l’écart de déploiement se concentre dans l’inférence de provenance et la synthèse des contrats — décider du rôle de chaque argument et tracer correctement son origine — plutôt que dans la politique d’application elle-même. C’est une cible plus abordable que « faire ignorer le texte hostile au modèle ».

Défenses

Points concrets applicables dès maintenant :

• Déplacez la décision de confiance sous l’appel d’outil. Demandez non pas « une donnée non fiable a-t-elle influencé cet appel ? » mais « quel argument a-t-elle influencé, et ce rôle a-t-il le droit de porter des données externes ? » Laissez le contenu externe remplir les champs de contenu tout en lui interdisant de lier destinataires, commandes, chemins, requêtes ou identifiants.
• Classez les arguments d’outil selon l’autorité. Pour chaque outil que votre agent peut appeler, étiquetez les arguments qui dirigent l’autorité (où va une action, ce qui s’exécute) par rapport à ceux qui ne portent que du contenu. Cet inventaire est le prérequis de l’application au niveau des arguments.
• Suivez la provenance à travers la replanification, pas seulement une étape. L’injection atterrit souvent plusieurs appels avant l’action dangereuse. Une application qui n’inspecte que l’appel immédiat manque les valeurs blanchies ; propagez les étiquettes d’origine sur toute la chaîne.
• Traitez cela comme complémentaire, pas comme une solution miracle. Les contrats de rôle d’argument contraignent la liaison d’autorité même si une chaîne malveillante passe, mais ils n’arrêtent pas un contenu nuisible dans un champ content légitimement externe, ni les erreurs d’attribution de rôle. Superposez-les au filtrage de contenu, au contrôle de flux d’information et aux politiques d’accès au niveau système.

Statut

Le travail est un préprint de recherche (arXiv 2605.11039, soumis le 11 mai 2026), évalué sur le benchmark ouvert AgentDojo et comparé à CaMeL et à des références de contrôle de flux d’information. C’est une méthode défensive, pas une vulnérabilité produit divulguée : il n’y a ni CVE ni correctif à appliquer. Les chiffres rapportés sont ceux des auteurs et attendent une réplication indépendante.