Les agents encodent leur graphe d'appels d'outils : une nouvelle surface de supervision

De quoi s’agit-il ?

Le 25 mai 2026, Tianda Sun et Dimitar Kazakov (University of York) ont publié Tool-Call Dependency Structure is Linearly Decodable in LLM Agent Residual Streams sur arXiv. Le résultat est étroit mais net : lorsqu’un agent outillé s’exécute, la structure de dépendance qui relie ses appels d’outils — quelle sortie d’un appel antérieur alimente l’argument de quel appel suivant — est inscrite dans les activations internes du modèle, sous une forme qu’une simple sonde linéaire sait relire.

Les auteurs ont utilisé Qwen3-32B comme politique d’un agent sur la partie « retail » de τ-bench, un benchmark multi-tour agent-outil, puis entraîné une sonde de régression logistique de faible capacité sur le flux résiduel gelé. Elle retrouve l’arête de dépendance entre deux appels avec une AUROC de 0,869, très au-dessus de tous les contrôles testés. À la connaissance des auteurs, il s’agit de la première sonde structurelle du graphe de dépendance des appels d’outils à l’exécution, et non de code statique ou de texte de raisonnement.

Comment ça marche

Chaque trajectoire d’agent induit un graphe orienté : une arête de l’appel i vers l’appel j existe dès que la sortie de i fournit un argument à j. Les auteurs construisent ce graphe à partir d’un oracle indépendant, puis vérifient s’il est présent dans les activations.

Ils enregistrent le flux résiduel des 65 couches de représentation à chaque frontière de décodage, puis entraînent une sonde linéaire régularisée en L2 sur les activations moyennées aux tokens-frontières des deux appels. L’arête devient linéairement décodable à partir de la couche 14 environ. Trois contrôles rendent le résultat difficile à balayer : un contrôle Hewitt–Liang à étiquettes aléatoires (la sonde le dépasse de +0,304 d’AUROC), une base positionnelle par sondage conditionnel pour écarter le simple ordre des appels (dépassée de +0,0775), et un contrefactuel qui corrompt les valeurs d’identifiants versus une perturbation de la structure — la sonde suit la topologie abstraite, pas les identifiants précis. Un patching d’activations couche par couche déplace la lecture d’une sonde ultérieure non patchée, signe que la représentation se propage dans le réseau plutôt que d’être lue passivement. Le signal non positionnel se répète sur trois autres benchmarks multi-sauts et disparaît en planification en un coup, où l’ordre des appels prédit déjà la dépendance.

Point essentiel : les auteurs précisent que leurs affirmations portent sur la représentation, pas sur le contrôle du comportement — le patching a déplacé la lecture de la sonde, mais pas le choix d’outil réellement effectué par l’agent.

Pourquoi c’est important

Le détournement du flux de contrôle par les outils — une injection indirecte qui redirige les outils appelés et la façon dont leurs sorties s’enchaînent — figure parmi les menaces majeures des agents. Jusqu’ici, la défense observait surtout l’extérieur de l’agent : les tokens émis, les appels réellement déclenchés, le texte de la trace de raisonnement. Ces travaux suggèrent que la structure d’appels voulue est aussi lisible depuis l’intérieur, dans un sous-espace linéaire, avant et indépendamment de la sortie de surface.

C’est une nouvelle surface de supervision. Elle complète les défenses fondées sur les activations — détection de dérive de tâche, sondes par étape indiquant si un outil est nécessaire ou lequel — mais vise ce qu’elles ne couvrent pas : la structure relationnelle entre appels. Si un opérateur peut reconstruire le graphe de dépendance que le modèle « entend » suivre et le comparer à ce qui s’est exécuté, un écart devient un signal candidat de plan réécrit.

Les réserves comptent autant que le résultat. Il s’agit d’un constat de décodabilité sur un domaine principal et deux familles de modèles, pas d’un détecteur déployé, et la représentation n’est pas le comportement. C’est une fondation pour la défense, pas une défense.

Défenses

Pour les équipes exploitant des agents auto-hébergés en boîte blanche, les enseignements pratiques concernent l’orientation des efforts, pas un outil clé en main.

1. Traiter les activations internes comme une surface d’observabilité, pas seulement la sortie. Le graphe d’appels voulu semble linéairement accessible ; une sonde sur le flux résiduel est un endroit plausible pour guetter une structure d’exécution détournée.
2. Combiner avec les défenses existantes fondées sur les activations. Associez le sondage du graphe d’appels à la détection de dérive de tâche et aux sondes par étape — elles couvrent des modes de défaillance complémentaires.
3. Ne pas confondre une sonde et un contrôle. Décoder le graphe voulu dit ce que le modèle représente, pas ce qu’il fera. Tout détecteur exige ses propres seuils, un budget de faux positifs et une évaluation adverse avant de bloquer quoi que ce soit.
4. Se rappeler la frontière de déploiement. Cela requiert l’accès aux activations internes : réservé aux déploiements auto-hébergés ou côté fournisseur — inaccessible aux seuls consommateurs d’API.
5. Garder l’application hors du modèle. Les signaux internes servent au diagnostic ; l’autorité d’autoriser ou de refuser un appel d’outil doit rester dans une politique déterministe, hors du modèle, et non dans une sonde qui lit l’esprit de l’agent.

Status

Élément	Référence	Date	Notes
Première sonde structurelle du graphe d’appels d’un agent à l’exécution	arXiv 2605.25310 (Sun & Kazakov, University of York)	2026-05-25	Qwen3-32B sur τ-bench ; AUROC d’arête 0,869 ; affirmation limitée à la représentation
Ligne convergente : appels d’outils lisibles et pilotables linéairement	arXiv 2605.07990	2026	Lit/pilote l’outil choisi ; signal par étape complémentaire

En une phrase : le graphe de dépendance des appels d’outils d’un agent est inscrit dans ses activations de façon linéairement lisible — prometteur comme signal de supervision d’une exécution détournée, mais c’est un constat de représentation, pas un détecteur abouti, et jamais un substitut à une autorisation hors modèle.