système : OPÉRATIONNEL
← retour à tous les hacks
DEFENSE LOW NEW

Lire l'intention d'un agent avant qu'il n'agisse : sondes pré-action

Un article de juin 2026 lit deux signaux — un outil est-il nécessaire, et à quel point est-il risqué — directement dans les activations d'un agent avant l'exécution, transformant les logs a posteriori en couche de supervision pré-action.

2026-07-08 // 6 min affects: llm-agents, tool-calling-agents, gpt-oss-20b, gemma-3-27b

De quoi s’agit-il ?

Le 8 juin 2026, Hariom Tatsat et Ariye Shater (Barclays Quantitative Analytics) ont publié Beyond the Black Box: Interpretability of Agentic AI Tool Use, une étude d’interprétabilité mécaniste au message défensif clair : la décision d’un agent de recourir à un outil — et le caractère plus ou moins conséquent de cette action — est souvent lisible dans l’état interne du modèle avant même que l’action ne se produise.

L’observabilité des agents est le plus souvent externe et tardive. Les prompts révèlent des corrélations, les évaluations notent les sorties, et les logs n’arrivent qu’après que le modèle a appelé l’outil. La thèse de l’article est que c’est le mauvais moment pour des décisions relevant de la sécurité. Dans les exécutions à long horizon, un appel erroné en début de course remodèle chaque étape suivante ; un moniteur qui lit l’intention à la frontière de décision — avant l’exécution — offre donc une fenêtre d’intervention que l’outillage fondé sur les logs n’a jamais.

Comment ça marche

La méthode combine deux outils d’interprétabilité éprouvés. Un auto-encodeur parcimonieux (SAE) décompose les activations denses d’un agent en features parcimonieuses et inspectables ; des sondes linéaires — de légers classifieurs logistiques — en extraient ensuite des signaux précis. Juste avant chaque action, le cadre agrège les états cachés des 32 derniers tokens pré-action, les encode via des SAE publics (GPT-OSS SAEs et Gemma Scope), et exécute deux lectures :

  • une sonde « outil nécessaire » (binaire : le modèle va-t-il appeler un outil à cette étape ?), et
  • une sonde « risque de l’outil » (trois niveaux : faible, moyen, élevé) qui estime la conséquence de la prochaine action.

Ici, le risque porte sur l’impact, pas sur le sujet : les actions à faible risque sont des lectures et des récupérations en lecture seule, celles à risque moyen des écritures bornées, et celles à risque élevé l’authentification, la communication sortante ou l’exécution de code — pensez à getusertoken, sendemail ou shell-exec. De façon révélatrice, les features qui pèsent le plus sur la sonde de risque s’agrègent autour de concepts d’identifiants et d’authentification, et le signal de décision se concentre dans les couches tardives du transformeur, près du point où le modèle s’engage à répondre directement ou à déléguer.

Les sondes n’ont été entraînées que sur le jeu de données de function calling Nemotron de NVIDIA, puis appliquées à deux modèles open-weight, GPT-OSS 20B et Gemma 3 27B, en gardant le Berkeley Function Calling Leaderboard comme test de transfert strict en zero-shot.

Pourquoi c’est important

Pour les défenseurs, cela reformule la sûreté des appels d’outils comme quelque chose que l’on peut inspecter de façon proactive. Une action d’outil à risque élevé — envoyer un e-mail, émettre un jeton, lancer une commande shell — est précisément le type d’étape qu’exploitent l’injection de prompt et les attaques de député confus. Une sonde pré-action donne à une couche de supervision la possibilité de suspendre l’action ou d’exiger une confirmation avant qu’elle ne se déclenche, plutôt que de la découvrir ensuite dans les logs. Le procédé se généralise : puisque le moniteur lit des représentations internes plutôt que des motifs de sortie propres à un outil, un même cadre de sonde peut surveiller de nombreux outils et de nombreuses étapes.

Les résultats sont prometteurs mais honnêtes. La précision « outil nécessaire » est de 75,3 % sur GPT-OSS et de 71,4 % sur Gemma ; le « risque de l’outil » atteint environ 90 % sur les étapes avec appel d’outil, même si son macro-F1 est tiré vers le bas car les cas à risque moyen sont rares et difficiles à séparer. En rejeu, la sonde a signalé environ trois quarts des appels d’outil manqués — son rôle le plus fort est celui d’auditeur d’omissions. En transfert zero-shot vers un nouveau benchmark, le signal « outil nécessaire » survit (accord de la Probe-1 avec la vérité terrain de 87,7 % sur GPT-OSS), mais les seuils dérivent nettement d’un espace de noms d’outils à l’autre, produisant de forts taux de fausses alertes tant qu’ils ne sont pas recalibrés.

Défenses

Traitez ces sondes comme une couche de supervision interne, pas comme une frontière de sécurité. Bien déployée, la recette est peu coûteuse et interprétable : capturez les activations de façon sélective aux points de décision à forte valeur, exécutez les deux lectures avant de dispatcher un appel d’outil, et placez les actions conséquentes — authentification, communication sortante, exécution de code — derrière une étape de confirmation lorsque la sonde de risque se déclenche à « élevé ». Associez-la à des contrôles externes (portées d’outils au moindre privilège, validation humaine pour les actions irréversibles, journalisation des exécutions) plutôt que de les remplacer.

Gardez à l’esprit les limites que les auteurs assument franchement. Le « risque de l’outil » dépend d’un schéma de risque heuristique et transfère moins proprement que « outil nécessaire » ; les seuils doivent donc être recalibrés par distribution d’outils avant qu’on ne se fie à une alerte. Seuls deux modèles open-weight et un ensemble choisi de couches ont été étudiés, si bien que la portabilité entre architectures et recettes de post-entraînement reste à prouver. Surtout, une sonde lit le signal interne propre au modèle : c’est un moniteur d’honnêteté d’intention, pas un détecteur d’injection — un attaquant qui remodèle ce que le modèle a l’intention de faire peut, en principe, en déplacer aussi le signal. Utilisez-la pour attraper les appels manqués et risqués, non comme une garantie autonome.

Statut

ÉlémentDétail
PublicationPreprint, 8 juin 2026 (arXiv:2605.06890v3)
AuteursHariom Tatsat, Ariye Shater (Barclays)
Modèles évaluésGPT-OSS 20B, Gemma 3 27B (instruction-tuned)
Précision « outil nécessaire »75,3 % (GPT-OSS) / 71,4 % (Gemma)
Précision « risque » (étapes avec outil)90,3 % / 88,5 %
Meilleur usageAudit pré-action des omissions et du risque à la frontière d’appel d’outil

Ce travail s’inscrit dans une lignée croissante de recherches sur le sondage des activations — dont des sondes qui signalent les sélections d’outils hallucinées et les interactions à fort enjeu à partir des états cachés — et désigne la supervision interne pré-action comme un complément pratique aux évaluations et logs externes sur lesquels reposent aujourd’hui la plupart des piles d’agents.

Sources