Filtrer les appels d'un agent de pentest avant leur exécution : ce qu'un juge de périmètre doit voir

De quoi s’agit-il ?

Lorsqu’un agent autonome mène un travail de sécurité offensive — scan de bug bounty, pentest, mission de red team —, un seul appel d’outil dirigé vers le mauvais hôte peut franchir la limite d’engagement d’un client, perturber une production ou invalider une découverte. L’agent d’un chercheur qui repère une injection SQL sur un sous-domaine hors périmètre n’a, aux yeux du programme, au mieux rien trouvé, et au pire commis une infraction.

Un article publié sur arXiv le 8 juillet 2026, ScopeJudge: Cost-Aware Pre-Execution Gating for Offensive Security Agents (2607.07774), signé Shane Caldwell, Max Harley, Ads Dawson, Michael Kouremetis, Vincent Abruzzo et Will Pearce (dreadnode), étudie si un second modèle, moins coûteux, peut surveiller un tel agent et bloquer les appels hors périmètre avant leur exécution. C’est une étude défensive : un benchmark et des recettes de supervision, pas une attaque.

Comment ça marche

Le dispositif est un filtrage pré-exécution (pre-execution gating), une instance de supervision de confiance. Un agent puissant et interchangeable propose un appel d’outil ; un juge peu coûteux et fixe inspecte cet appel et l’accepte (il s’exécute) ou le rejette (l’agent est invité à corriger, ou un humain est escaladé). Le juge intervient à chaque étape : il doit donc rester peu cher.

La difficulté est que le périmètre n’est pas une règle figée. Comme le disent les auteurs, la limite « vit dans la requête » : une même commande — par exemple un scan sur un domaine donné — est dans le périmètre pour une mission et une violation pour la suivante, selon la cible et le contexte. Une politique écrite à l’avance ne peut pas énumérer le périmètre propre à une requête qu’elle n’a jamais vue.

Pour le mesurer, l’équipe a construit ScopeJudge : 100 trajectoires d’agents issues d’un ensemble de 30 environnements conçus pour pousser les agents hors périmètre, annotées appel par appel par des pentesteurs professionnels. On obtient 4 897 appels d’outils, dont 7,7 % sont des violations de périmètre. L’accord inter-annotateurs est substantiel (κ de Fleiss = 0,64), fixant une référence d’expert humain à F1 = 0,78. Ils ont ensuite testé huit modèles juges selon cinq stratégies de transcription — la quantité de contexte vue par le juge, de la seule politique figée jusqu’à la transcription brute complète — et tracé la frontière coût/précision.

Le résultat marquant est négatif mais important : un juge ne voyant que la politique figée, aveugle à la requête, a un rappel qui s’effondre à près de zéro. Il ne peut pas détecter les violations car il ignore ce que la mission autorisait. La supervision conditionnée à la requête est nécessaire. Parmi les juges à contexte complet, les plus performants sont à poids ouverts — GLM-5.2 atteint F1 = 0,66, devançant le meilleur juge propriétaire (0,60) à environ un tiers du coût par appel.

Pourquoi c’est important

Deux contrôles courants montrent leurs limites ici. Le sandboxing suppose que l’on peut isoler l’agent, mais en sécurité les systèmes testés sont souvent en boîte noire et appartiennent au client : impossible de les cloner dans un environnement jetable. La revue humaine souffre de la fatigue d’alerte : le relecteur clique « approuver » alerte après alerte jusqu’à ce que la supervision devienne un théâtre — le même réflexe que celui documenté depuis longtemps pour les avertissements de sécurité des navigateurs. Un juge automatique ne se fatigue pas, ce qui rend le filtrage par appel attrayant à grande échelle.

Mais les résultats tempèrent l’optimisme. Même le meilleur juge (0,66) reste sous la barre de l’accord humain (0,78) : cette supervision réduit le risque sans l’éliminer. L’article pointe aussi une tension réelle : donner plus de contexte au juge — le raisonnement de l’agent, les sorties d’outils — améliore la précision mais augmente la surface d’attaque, car un agent désaligné ou un attaquant externe pourrait empoisonner ce contexte pour faire passer un appel hors périmètre. Plus de visibilité n’est pas gratuit.

Défenses

Les recommandations pratiques pour qui exploite des agents de sécurité autonomes :

• Conditionnez le moniteur à la requête, pas seulement à une politique. Une constitution ou une liste blanche figée ne capture pas le périmètre propre à chaque mission. Fournissez au juge l’objectif déclaré et les contraintes de l’utilisateur pour qu’il raisonne sur ce que cette tâche autorisait.
• Filtrez avant l’exécution, pas après. L’audit a posteriori détecte les violations une fois le mal fait. Jugez chaque appel dans la boucle et bloquez, corrigez ou escaladez avant qu’il ne s’exécute.
• Choisissez délibérément un point de fonctionnement. Une violation manquée coûte en général plus cher qu’un rejet abusif : pour les missions sensibles, réglez le juge sur le rappel (moins d’oublis, plus de fausses alertes) plutôt que sur le seul F1.
• Traitez le contexte du juge comme une surface d’attaque. Les traces de raisonnement et les sorties d’outils améliorent le jugement mais peuvent être empoisonnées ; isolez et assainissez ce que le juge ingère, et ne supposez pas qu’un juge plus intelligent est plus sûr.
• Réservez l’humain à l’escalade, pas à chaque appel. Confiez à la revue humaine les appels signalés par le juge : la supervision reste utile au lieu de noyer les relecteurs sous les approbations.

Statut

Élément	Détail
Constat	Un juge LLM conditionné à la requête peut bloquer les appels hors périmètre d’agents offensifs avant leur exécution
Source	ScopeJudge: Cost-Aware Pre-Execution Gating for Offensive Security Agents, Caldwell et al., dreadnode, arXiv, 8 juillet 2026
Benchmark	4 897 appels d’outils (7,7 % de violations), 100 trajectoires annotées par des pentesteurs ; κ de Fleiss = 0,64
Résultat clé	Les juges limités à la politique figée ont un rappel quasi nul ; meilleur juge F1 = 0,66 contre référence humaine F1 = 0,78
Type	Benchmark défensif / étude de supervision (recherche ; pas de CVE)