Une défense au décodage bloque les instructions cachées avant les appels critiques
Agentic AI Defense: Decode-Time Provenance Binding for MCP · arXiv:2610.31974
En termes simples
Un agent peut ne pas repérer une instruction cachée dans l’image jointe à un courriel avant qu’un outil d’image ne la décode. Ensuite, cette instruction peut circuler entre agents sous la forme d’une sortie qui semble ordinaire.
L’article présente une défense qui marque le contenu décodé comme non fiable et vérifie sa provenance enregistrée avant d’autoriser les appels critiques aux outils. Lors d’un test comprenant 24 attaques, la défense les a toutes bloquées, tout comme une méthode de référence de suivi de contamination intégrée au processus. Le résultat se limite au cadre testé.
La recherche
Comment une instruction cachée dans l’image d’un courriel peut-elle devenir une commande fiable après qu’un agent l’a décodée et en a relayé le texte ? L’article examine cette faille des défenses axées sur le texte : l’instruction ne devient lisible qu’au moment du décodage.
Les auteurs présentent une défense à l’exécution qui marque le contenu décodé comme non fiable et vérifie sa provenance enregistrée avant les appels critiques aux outils.
Les auteurs présentent la traçabilité de provenance au moment du décodage, une défense à l’exécution pour les agents qui utilisent des outils via le Model Context Protocol.
Elle marque les sorties décodées comme non fiables et permet à la couche du protocole de vérifier leur provenance enregistrée avant un appel critique à un outil.
Lors d’un test de 24 attaques, la défense et une méthode de référence de suivi de contamination intégrée au processus n’ont laissé fuiter aucun contenu, tandis que les filtres textuels ont chacun laissé fuiter du contenu dans 62.5 % des cas.
Cette comparaison étaye l’intérêt des vérifications de provenance pour ce groupe d’attaques ; elle ne montre pas un avantage général sur les autres systèmes de traçabilité.
Les résultats proviennent d’un banc d’essai contrôlé comprenant 24 attaques, un logo de couverture et un petit modèle local.
La garantie de sécurité dépend aussi du fait que la couche MCP intercepte chaque appel critique et consigne l’intégralité de la provenance ; les instructions reformulées en dehors de ce circuit ne sont pas couvertes.
Ce que montrent les preuves
- Quand les images portent des instructions
La traçabilité de provenance au moment du décodage est une défense à l’exécution destinée aux agents qui utilisent des outils via le Model Context Protocol (MCP). L’article demande comment une instruction cachée dans l’image d’une signature de courriel peut devenir une entrée fiable après son décodage par un outil et le relais de son texte entre agents.
Dans l’attaque décrite, les filtres textuels ne détectent aucun mot suspect dans l’image ; l’instruction n’entre dans le contexte de l’agent qu’au moment du décodage.
- Suivre le moment du décodage
La défense marque comme non fiable la sortie des outils de décodage enregistrés, dès sa production. La couche MCP signe un relevé de cette sortie et de ses dépendances, conserve elle-même le registre de provenance et vérifie ce relevé ainsi que le contexte avant un appel critique à un outil.
Elle cible le moment où le contenu caché devient lisible, au lieu de chercher à déterminer si l’image elle-même paraît suspecte.
- Comparer les défenses testées
Dans un banc d’essai MCP réel, les chercheurs ont compté les fuites lors de 24 attaques utilisant trois types d’images porteuses et huit techniques d’évasion. Le pipeline sans défense a laissé fuiter du contenu dans toutes les attaques, tandis qu’un filtre par mots-clés et un analyseur fondé sur des expressions régulières ont chacun laissé fuiter du contenu dans 62.5 % des cas.
La défense proposée et une méthode de référence de suivi de contamination intégrée au processus n’ont laissé fuiter aucun contenu dans ce groupe d’attaques, ce qui montre que les deux ont bloqué les attaques testées au sein d’un même domaine de confiance.
- Vérifier deux protections distinctes
Une étiquette de confiance valide ne suffisait pas à empêcher un agent de dissimuler le décodage non fiable qui avait influencé un appel critique : le vérificateur fondé uniquement sur l’étiquette l’a autorisé, tandis que la vérification de provenance de la couche l’a bloqué.
Dans un test de trois scénarios portant sur les composants, la suppression des vérifications de signature a permis le relais falsifié entre domaines de confiance, tandis que la suppression du suivi de provenance a permis la substitution d’étiquette. Ces résultats distinguent le rôle des deux protections dans les scénarios testés.
- Préserver les tâches autorisées
Considérer toute valeur décodée comme non fiable a bloqué à tort l’une des trois tâches légitimes : un paiement autorisé utilisant un numéro de facture lu dans une image. Une procédure de promotion auditée a permis de traiter cette valeur comme fiable : les trois tâches ont alors abouti sans blocage injustifié, et l’attaque non autorisée est restée bloquée. Ces résultats, comme ceux des tests d’attaque, proviennent d’un banc d’essai contrôlé ; la garantie suppose que la provenance soit intégralement enregistrée et que les appels critiques soient interceptés.
Détails
- Auteurs de l’article original
- Eric Yocam, Varghese Vaidyan, Paris Kalathas, Patrick Tague, Bruce DeBruhl
- Soumis à arXiv
- Licence
- CC BY 4.0