Déconstruction technique 020｜ARTEX : Tests de pénétration intégrés au flux de travail des agents, dépôt de sauvegarde à 721 étoiles en un jour

Le 8 octobre, le dépôt mhtsec/ARTEX est apparu sur GitHub, avec une ligne de présentation dans la section about : système de test de pénétration autonome par IA, projet champion du défi d’attaque et de défense « agent+ » de Baidu (selon la description du projet). Un jour plus tard, 721 étoiles. Ce n’est pas encore un autre script de scanner, mais un système multi-agents complet : 327 fichiers sources pour le backend en Go, plus de dix mille lignes pour le package agent, le frontend Next.js intégré en un seul binaire, et deux graphes stockés dans PostgreSQL. Plus intéressant encore, l’identité du dépôt : le premier écran du README déclare qu’il s’agit de la « sauvegarde de code source pur de la dernière version », et le dépôt original est déjà inaccessible. Cet article décompose le sujet en six points : ce que c’est, pourquoi maintenant, les mécanismes centraux, les chiffres et les limites, comment l’exécuter, et l’évaluation de sa valeur.

I. Qu’est-ce que c’est

Parlons d’abord de l’identité du dépôt ; il y a ici un détail souvent source d’erreurs. mhtsec/ARTEX est un dépôt de sauvegarde : le README se décrit comme « Ce dépôt est une sauvegarde de code source pur de la dernière version d’ARTEX », et précise que la source de déploiement docker est obsolète et qu’il faut effectuer la construction localement soi-même. Dans le script d’installation du dépôt, l’adresse de clone indiquée est toujours Autumn-27/ARTEX. Ce dépôt d’origine renvoie désormais une erreur 404 sur GitHub ; qu’il ait été supprimé ou passé en privé, la raison est inconnue. Autrement dit, l’historique de développement du projet, les issues et les releases sont restés dans le dépôt d’origine ; ce dépôt actuel n’est qu’un instantané du code source ; les 721 étoiles représentent l’attention portée par la communauté de sécurité en l’espace d’une journée à la « sauvegarde du code source du projet champion », et non la réputation accumulée par le projet sur le long terme.

Parlons maintenant du système en lui-même. ARTEX est un projet complet qui modélise les tests de pénétration sous forme de flux de travail d’agent (agent workflow) : backend en Go, 327 fichiers .go, dont 10391 lignes pour le paquet agent ; frontend Next.js, exporté statiquement puis intégré dans un seul binaire via go:embed ; base de données PostgreSQL. Les dépendances principales se résument à une seule ligne : la propre bibliothèque de framework d’agent de l’auteur, norma (fournissant les modules agentcore, tool, permission, transcript, etc.), ainsi que quelques bibliothèques de base. La licence est AGPL-3.0, mais à la fin du README s’ajoute une couche de restrictions d’utilisation plus stricte que la licence, ce qui sera abordé plus loin.

L’ossature du système repose sur une division du travail multi-agent : le planner est responsable de la planification, le worker de l’exécution, et le mainagent prend en charge les dialogues avec l’humain dans la boucle (human-in-the-loop). Le support de cette division du travail repose sur deux graphes : le graphe d’actifs (asset graph) et le graphe d’exploration (exploration graph) ; le mécanisme sera détaillé dans la troisième partie.

II. Pourquoi il vaut la peine de s’y intéresser maintenant

Trois raisons.

Premièrement, les tests de pénétration par LLM (modèles de langage de grande taille) constituent la tendance majeure des compétitions de sécurité actuelles, et les défis d’attaque-défense de type « agent+ » en ont fait une catégorie officielle. ARTEX, qui se présente comme le projet champion (selon ses propres dires), apparaît à ce moment précis, ce qui constitue en soi un baromètre de la tendance : les compétitions forcent les équipes participantes à amener l’ingénierie des agents à un niveau de maturité suffisant pour entrer en lice ; il est donc pertinent de voir à quoi ressemble la solution championne.

Deuxièmement, les composants génériques de l’ingénierie des agents sont désormais matures. L’ordonnancement piloté par les événements, le stockage partagé inter-sessions, les portails d’approbation des outils, la traçabilité des preuves — ces composants ont été peaufinés pendant plus d’un an dans des scénarios comme les assistants de programmation et l’Ops automatisé, et ARTEX les assemble dans un domaine vertical. Voir comment il les assemble et ce qu’il modifie dans les scénarios de sécurité a plus de valeur que lire 10 articles conceptuels.

Troisièmement, cela clôture parfaitement le sujet. Sur le thème de la sécurité de l’IA, nous avons précédemment abordé le versant offensif (empoisonnement du modèle) et le versant défensif (exfiltration complète des poids) ; cet épisode comble la partie intermédiaire : le flux de travail d’attaque-défense lui-même réécrit par l’agent. En reliant ces trois articles — attaque, défense, flux de travail —, le panorama complet de cette direction est dressé.

III. Mécanismes techniques fondamentaux

Un ensemble de quatre éléments : Planner (planificateur) piloté par les événements, double graphe avec tableau noir, approbation par interception, chaîne de preuves. Voyons-les un par un.

Planner piloté par les événements. Le commentaire dans agent/planner.go indique clairement son positionnement : « Planner is the event-driven LLM planner ». Il ne procède pas par scrutation, mais est réveillé dès qu’il y a un changement dans le graphe d’actifs ou le graphe d’exploration (avec anti-rebond, pour éviter que les fluctuations du graphe ne déclenchent des planifications en cascade). À son réveil, il lit la situation actuelle, détermine si l’objectif est atteint, puis répartit de 0 à N intentions d’exploration dans la file d’attente des intentions à réclamer (frontier). Deux conceptions sont à retenir : premièrement, il est le « seul générateur d’intentions » de tout le système, les workers se contentent de prendre des intentions, ils n’en créent pas, le pouvoir de planification n’est pas dispersé ; deuxièmement, la plupart des réveils répartissent 0 intention : s’il n’y a pas de nouvelle direction, il reste silencieux, il ne cherche pas forcément du travail. De plus, il y a deux rappels (callbacks), killWork et steerWork, qui permettent d’arrêter ou de rediriger en cours de route un travail en cours d’exécution ; les nœuds froids disposent d’un mécanisme de compression pour contrôler la longueur du contexte des tâches longues.

Todolist (liste de tâches) partagée. Chaque réveil du Planner est une toute nouvelle session, il est sans état (stateless) en lui-même. Cependant, le processus d’exploitation réel est souvent une séquence en plusieurs étapes avec des dépendances, où le résultat de l’étape précédente est l’entrée de l’étape suivante ; les répartir toutes en parallèle en une seule fois ne ferait que créer du désordre. La solution est une liste de tâches conservée par tâche et partagée entre les réveils : le Planner enregistre une chaîne d’exploitation série une seule fois, puis à chaque tour, il ne répartit des intentions que pour l’étape suivante dont « l’étape précédente est terminée », débloquant progressivement les étapes suivantes au fur et à mesure que les faits sont écrits en retour. Dans un environnement piloté par les événements et avec des sessions sans état, les séquences en plusieurs étapes peuvent ainsi progresser de manière stable, sans répétition ni désordre. C’est une étape clé pour que le système puisse parcourir de longs processus de manière autonome.

Double graphe et tableau noir. « Quel est l’objectif » et « Jusqu’à quel point est-il testé » sont divisés en deux graphes. Le graphe d’actifs est partagé globalement, ses nœuds allant du domaine racine et du sous-domaine à l’IP, au service et au point d’accès (endpoint). Les relations parent-enfant et les clés de déduplication sont toutes calculées par le programme, l’agent se contente de soumettre les informations brutes et n’est pas responsable de déterminer les doublons. Le graphe d’exploration est indépendant pour chaque tâche, ses nœuds sont des objectifs, des intentions, des faits, des vulnérabilités et des indices, reliés par des arêtes de type dérivation, production, preuve, etc. pour former un lignage. On peut consulter sur le graphe quelle direction a dérivé de quels faits et ce qu’elle a produit. Les deux graphes sont reliés par des points d’ancrage, ce qui permet de suivre la direction d’exploration pour voir quels actifs ont été touchés, mais aussi de rechercher en sens inverse quelles intentions ont testé un certain actif. L’état est transmis entre les tâches via le tableau noir : les tâches suivantes voient une vue en lecture seule des données actives des tâches précédentes, les preuves de vulnérabilité héritées sont en lecture seule et ne peuvent être modifiées. L’état peut être hérité, la pollution ne peut y entrer.

Approbation par interception. Le système a établi une porte d’approbation pour les appels d’outils. Les règles intégrées bloquent d’abord les opérations destructrices explicites : en plus de la méthode HTTP DELETE, une règle de « chemin d’interface de type suppression » a été ajoutée, couvrant les requêtes où le chemin contient /delete, /del, /remove, /unlink, /erase, /destroy, et exigeant qu’un séparateur suive le verbe, de sorte que /delivery, /details, etc., ne soient pas interceptés par erreur. La motivation pour l’ajout de cette règle est écrite dans le journal des mises à jour : les interfaces de suppression de la plupart des applications peuvent être déclenchées par des méthodes GET ou POST, se fier uniquement à la méthode DELETE ne suffit pas à les bloquer. La partie en dehors des règles est confiée à une « approbation de secours par le modèle », laissant le LLM décider de l’autorisation ou non ; la consommation de tokens de cette partie est mesurée séparément, et l’interface comprend une carte d’utilisation et un graphique en barres quotidien des 30 derniers jours. L’approbation elle-même coûte de l’argent au modèle, et le montant dépensé vous est montré de manière transparente.

Chaîne de preuves. C’est l’élément qui témoigne le plus de l’ingéniosité technique. La liaison entre les vulnérabilités et le trafic est de type plusieurs-à-plusieurs, chaque liaison étant marquée comme ayant l’une des quatre utilités : baseline (contrôle normal), proof (preuve de vulnérabilité), verification (vérification supplémentaire), supporting (preuve à l’appui). Lors de la liaison, le trafic correspondant est haché selon SHA-256 pour créer un fichier de preuve archivée, et plusieurs vulnérabilités peuvent partager le même fichier de preuve. Le document spécifie une philosophie de conception : le système ne devine pas les liaisons en fonction du nom de domaine, de l’heure ou de l’historique de navigation : pour éviter les fausses attributions, il préfère vous laisser choisir explicitement plutôt que de deviner pour vous. Le rapport est généré en deux étapes par un Agent de rapport indépendant : il est automatiquement déclenché après que la découverte a été stockée, vérifie et lie le trafic, puis rédige le rapport en fonction de la dernière version des preuves ; l’écriture s’accompagne d’un verrouillage optimiste evidence_version, si les preuves changent pendant la génération, le remplacement par l’ancienne version est refusé, un conflit de version renvoie 409, et l’écriture sur des preuves héritées renvoie 403.

Ajoutons une remarque sur le profilage de la qualité du code : le journal des modifications de la version 0.3.15 (7 octobre) contient le compte rendu d’un audit de sécurité complet, parmi la dizaine de correctifs figure une vulnérabilité de fusion de configuration jugée « critique » (le masquage des identifiants pouvant être contourné par un mode de commit spécifique), chacun a d’abord été reproduit, puis corrigé, puis complété par un test de régression ; dans le paquet agent, presque chaque fichier principal possède un fichier de test correspondant. Dépôt de sauvegarde ne signifie pas dépôt bâclé.

IV. Chiffres et limites

Bilan des chiffres : 721 étoiles (au 9 octobre, en un jour) ; 327 fichiers .go ; 10391 lignes dans le paquet agent ; backend Go + frontend Next.js + PostgreSQL ; dépendance au framework norma v0.4.3 ; AGPL-3.0 ; dernière version 0.3.15 datée du 7 octobre, dépôt rendu public le 8 octobre.

Quatre limites sont à souligner.

Premièrement, le titre de champion est une auto-déclaration. « Champion du Baidu agent+ Attack & Defense Challenge » n’apparaît que dans la description « about » du dépôt, et aucune recherche sur le concours lui-même n’a permis de trouver un rapport indépendant ou un classement public pour le vérifier. Ce titre est à écouter comme une auto-présentation du porteur de projet, et non à utiliser comme un certificat de réussite.

Deuxièmement, la portée du nombre d’étoiles est à relativiser. 721 étoiles en un jour mesurent l’attention de type mirroring de la communauté de la sécurité, et non l’accumulation d’utilisateurs sur le long terme ; le dépôt original est en 404, l’historique de développement ne peut être comparé, et ce que ce code source a traversé avant la sauvegarde est invisible de l’extérieur.

Troisièmement, la maintenabilité face à un auteur unique et une archive figée. La liste des contributeurs de la version 0.3.15 ne comporte que l’auteur ; le README stipule clairement qu’il s’agit de la sauvegarde de la dernière version. Ce code source n’aura très probablement plus jamais de commits ultérieurs, le lire ou l’utiliser doit se faire avec l’attente d’une « archive figée ».

Quatrièmement, la clause de non-responsabilité est plus stricte que celle des outils de pénétration habituels. La clause de non-responsabilité de la plupart des outils de pénétration est « réservé aux tests autorisés », ARTEX (outil de test de pénétration) indique directement : il est strictement interdit de lancer des scans, des sondages, des exploitations ou des attaques contre tout site Web, service en ligne ou système connecté en réseau. Une phrase est expressément ajoutée entre parenthèses : « que l’autorisation ait été obtenue ou non, qu’il s’agisse ou non de ses propres actifs ». Même les tests en ligne autorisés sont interdits, ne laissant que trois exceptions : l’apprentissage personnel, la recherche sur le code et la vérification dans un environnement local isolé.

5. Comment l’exécuter et qui peut l’essayer

Commençons par l’exécution dans le cadre défini, qui dépend de trois éléments : un PostgreSQL, une clé LLM (ANTHROPIC ou OPENAI, également configurable via l’interface), et un environnement local isolé. Deux options de déploiement : le script d’installation vous guide pour choisir entre tout Docker ou une compilation locale, cette dernière utilisant Go pour compiler un binaire unique avec le frontend intégré ; une fois démarré, le service écoute sur le port local 8787, et la première connexion nécessite de définir le mot de passe administrateur. Notez la particularité du dépôt de sauvegarde : la source de déploiement Docker indiquée dans le README est obsolète, si l’image ne peut pas être tirée (pull), il faut passer par la construction locale, l’auteur suggère même « de laisser l’IA faire la construction locale pour vous ». Sur le plan de l’écosystème, il peut synchroniser les actifs avec l’outil de cartographie des actifs ScopeSentry du même auteur, et les importer par projet ou par tâche.

Cela s’adresse à trois types de profils. Pour les ingénieurs en offensive/défensive : le double graphe, les portes d’approbation et la chaîne de preuve sont des modèles d’architecture directement inspirables, en particulier les deux derniers, qui restent valables même dans un autre domaine. Pour les développeurs d’agents : l’approche pilotée par les événements, combinée aux sessions sans état et aux listes de tâches (todolist) partagées, est une réponse clé en main à « comment faire avancer un processus multi-étapes de manière stable dans un environnement sans état » ; le fichier planner.go mérite d’être lu dans son intégralité. Pour les chercheurs en sécurité : la chaîne de preuve avec liaison à quatre usages et verrouillage optimiste, est une implémentation de référence pour « comment transformer les résultats d’un agent en preuves auditables ».

Pour les simples curieux, le point d’entrée le plus accessible est le site de démonstration en ligne mentionné dans le README ; il suffit de cliquer pour voir à quoi ressemblent les interfaces des tâches, des actifs, du processus d’exploration et des enregistrements d’approbation, avant de décider s’il vaut la peine de lire le code source.

6. Jugement de valeur et public concerné

Valeur de l’échantillon : élevée. Il fait passer « l’IA réalisant des tests de pénétration » des rapports rapides de compétition et des vidéos de démonstration à un code source qui peut être lu ligne par ligne. Pour évaluer le véritable degré d’achèvement d’un système d’agent, j’examine trois points : le pouvoir de planification est-il centralisé, l’exécution laisse-t-elle une trace, le résultat est-il auditable. ARTEX apporte une réponse d’ingénierie à ces trois points : un générateur d’intention unique, un agent d’enregistrement à traçabilité complète, et une chaîne de preuves avec hachage et verrouillage de version.

Valeur pour l’industrie : il s’agit d’une réécriture des flux de travail, et non d’un simple remplacement d’outils. Dans les tests de pénétration, l’énumération, les essais et erreurs, l’enregistrement et l’organisation en grande quantité constituent un travail fastidieux standard ; la répartition du travail démontrée par ARTEX consiste à confier les tâches pénibles à l’agent, tandis que l’humain garde le contrôle des décisions clés, les portes d’approbation bloquent les opérations destructrices, et la chaîne de preuves permet de vérifier une par une les conclusions de l’agent. Pour l’équipe rouge, cela signifie une amplification de la capacité de production, l’élimination du travail répétitif, et une concentration humaine sur les étapes exigeant véritablement du jugement ; pour l’équipe bleue, cela signifie une escalade de l’affrontement, l’automatisation à faible coût va augmenter globalement la fréquence de la reconnaissance et des tentatives, et le camp de la défense nécessite également une détection et une réponse de type agent. Les deux camps, attaque et défense, sont poussés dans la même direction par le même code source.

Délimitons les frontières une fois de plus : l’efficacité ne repose sur aucune donnée tierce, le titre de champion est autodéclaré, et le dépôt est une sauvegarde figée. Cela vaut-il la peine d’y consacrer du temps ? Cela dépend de ce que vous souhaitez en retirer. Si vous en retirez l’architecture (portes d’approbation, chaîne de preuves, liste de tâches partagée), elle est applicable partout ; si vous cherchez à en retirer un outil de test de pénétration prêt à l’emploi, cela va à l’encontre de ses conditions d’utilisation et surestime son positionnement.

Jugement en une phrase : l’importance d’ARTEX ne réside pas dans son titre de champion, mais dans le fait qu’il a transformé le slogan « l’agent effectue des tests de sécurité en toute autonomie » en un processus d’ingénierie avec approbation, preuves et révisabilité. L’automatisation dans cette direction n’a jamais manqué de démonstrations ; ce qui manque, c’est cette retenue auditable.

Sources de référence

• Dépôt principal : github.com/mhtsec/ARTEX (après clone local, comparaison détaillée de README, CHANGELOG, docs/vulnerability-traffic-evidence.md, code source du package agent, go.mod, git log ; aucun build exécuté)
• GitHub API (721★, description about, date de création 2026-10-08)
• Dépôt d’origine Autumn-27/ARTEX, l’API a renvoyé 404 (supprimé ou passé en privé, raison non vérifiée)
• Le nombre d’étoiles 721★ correspond aux données à la date du 2026-10-09, et continue d’évoluer