Dans la démo qui accompagne ToFu, une prépublication mise en ligne le 9 octobre, un agent appelle un outil factice puis annonce qu’il ne peut pas répondre à la demande. Regarde l’ordre des opérations, il te dit tout : l’exécution d’abord, le refus ensuite. Six chercheurs viennent de documenter ce que pas mal de monde soupçonnait sans vouloir y regarder de près. Ton garde-fou parle, mais c’est l’orchestrateur qui décide d’appuyer sur le bouton.
Le mécanisme n’a rien de sorcier. Le modèle produit le nom d’un outil et ses arguments. L’orchestrateur, le bout de code qui relie le modèle aux outils, décide quoi faire de cet appel structuré. Tu peux coller toutes les consignes système du monde pour ordonner au modèle de refuser les requêtes dangereuses, ça ne change pas qui exécute quoi. Les auteurs le formulent mieux que moi : « La consigne système a façonnée ce que le modèle disait, pas ce que l’orchestrateur faisait. »
L’attaque, baptisée « Repeat-After-Me », tient en deux tours. Au premier, le modèle refuse et recopie l’appel dans sa réponse en texte brut. Rien ne part, tout va bien. Au second, l’attaquant présente la même demande comme « hypothétique » et exige que le modèle ne produise rien d’autre que la chaîne citée. Le modèle renvoie alors un message vide, flanqué d’un appel structuré à launch_missiles avec exactement les arguments écrits par l’attaquant. L’outil s’exécute aussitôt, le refus n’arrivant qu’après le retour de l’outil.
Les chercheurs disent avoir reproduit le comportement sur six orchestrateurs : LangGraph, Microsoft Agent Framework, Google ADK 2.0, AutoGen, AWS Strands et CrewAI. La démonstration complète, elle, n’est publiée que pour LangGraph. Version 1.2.0, nœud d’exécution d’outils prêt à l’emploi (ToolNode), Llama 3.1 8B servi par Ollama à température nulle, deux outils factices sans effet (make_bomb, launch_missiles), et une seule protection : une consigne système qui demande de refuser. Le montage est franchement favorable à l’attaquant, le papier ne mesure pas le taux de réussite sur des modèles plus costauds, et il ne détaille pas les versions testées pour chaque framework. Ça reste une démo, pas une preuve généralisée. Mais le principe, lui, ne dépend pas de la taille du modèle : il dépend de l’endroit où tu vérifies.
Le vrai gisement est dans les outils, pas dans la tête du modèle
Si un attaquant peut dicter les arguments d’un appel (via le prompt utilisateur, un contenu récupéré ou la sortie d’un autre outil), alors chaque argument doit être traité comme hostile au moment où il atteint l’outil. ToFu part de ce constat pour dériver des contrôles à partir des métadonnées que les serveurs MCP exposent déjà au modèle. Un argument décrit comme « fichier dans l’espace de travail » ne doit pas permettre de lire ../../etc/passwd. Les chercheurs génèrent ensuite des entrées adverses et vérifient à l’exécution si la promesse est tenue, avec 74 détecteurs pour la plupart rattachés à une classe de faiblesses CWE.
Leur banc de test a passé 273 serveurs Python ou JavaScript, en a extrait 3 405 outils dont une partie seulement a pu être exercée, et retient après vérification manuelle 253 bogues reproductibles dans 118 serveurs. Attention au périmètre : ces résultats portent sur le corpus sélectionné, ils ne donnent pas un taux de vulnérabilité de tout l’écosystème MCP. Côté types, on trouve des sorties qui reproduisent l’entrée sans l’échapper, des traversées de chemin hors périmètre, des injections dans les journaux, des requêtes réseau détournées, des exfiltrations et trois injections de commandes système. Le détail qui doit te réveiller la nuit : ces défauts peuvent frapper sans plantage. Un test qui ne surveille que les arrêts de programme passe à côté, pendant que l’outil lit tes fichiers ou ferme une session de terminal qui n’était pas la sienne.
Le premier auteur, Nazmul Islam Ananto, a ouvert le ticket #8817 le 4 septembre pour réclamer un point d’interception documenté avant exécution, ou au minimum un avertissement explicite sur le comportement du nœud d’outils. Au 16 octobre, le ticket reste ouvert. Des contrôles existent pourtant déjà : le paramètre optionnel wrap_tool_call de langgraph-prebuilt 1.1.0 permet d’intercepter un appel, CrewAI fournit aussi un hook avant l’appel capable de le bloquer. Sauf que tout ça doit être configuré. Et le code du ticket LangGraph, lui, utilise un nœud maison qui exécute gentiment les appels émis par le modèle.
La conséquence pour une équipe qui déploie des agents est bête comme chou : l’autorisation doit être vérifiée sur l’outil et ses arguments, indépendamment du texte produit par le modèle. Un appel parfaitement conforme au schéma peut demander une action que l’utilisateur n’a pas le droit d’effectuer.
Pendant ce temps, la vraie monnaie bouge
Ce n’est pas qu’un débat d’ingénieurs. Le jour même, le Financial Times rapporte que Citi est devenue la dernière grande banque américaine à restreindre l’accès des agents IA aux comptes. Les prêteurs outre-Atlantique craignent que des chatbots fassent filer des milliards de dollars de dépôts vers des comptes mieux rémunérés. Quand ta carte bleue est tenue par un agent, tu comprends soudain l’intérêt d’un garde-fou qui fonctionne vraiment.
Et la parade existe, sous une forme nettement plus austère. Le projet Agentic-seL4, mené par le professeur Brijesh Dongol au Centre for Cyber Security de Surrey avec Sheffield et Melbourne, vient de décrocher plus de 3,2 millions de livres de l’ARIA britannique dans son programme Safeguarded AI. Objectif : un bac à sable formellement vérifié qui contrôle ce que l’agent peut atteindre et faire, avec des permissions modifiables ou révocables pendant qu’il tourne. Un agent qui a touché des données confidentielles pourrait ainsi être bloqué avant de communiquer à l’extérieur, ou uniquement après passage par un filtre de nettoyage de confiance. Tout ça adossé à des modèles mathématiques et des preuves garantissant que la politique est toujours appliquée, testés sur des scénarios réalistes d’« évasion » d’agent.
Dongol ne mâche pas ses mots : « Les garde-fous qu’on met autour de ces systèmes doivent progresser au même rythme ». Son projet fait partie des huit retenus dans la piste Cybersécurité TA2, qui se partagent 22 millions de livres. La différence avec ToFu, c’est la couche visée. Le sandbox de Surrey borne ce que l’agent peut atteindre ; ToFu valide ce qu’un appel précis a le droit de faire. Les deux racontent la même histoire : l’application de la règle vit à l’extérieur du texte du modèle.
On te disait déjà que surveiller ses agents à la main te crame le cerveau, dans un précédent papier. Mauvaise nouvelle supplémentaire : même un humain attentif surveillait au mauvais étage. Pendant qu’on relit la prose du modèle pour voir s’il a dit « non », le code a déjà appuyé. Le refus, c’est de la décoration. La sécurité, c’est le videur à l’entrée de l’outil, pas le physionomiste qui te raconte qu’il a dit non.
Sources :
Comments are closed