LuaN1aoAgent v2 : un agent de pentest qui écrit son raisonnement dans un graphe

Le problème : des conclusions de pentest sans traçabilité

Un agent qui pilote des outils offensifs produit vite un flux de texte convaincant et invérifiable. Le README de LuaN1aoAgent v2 formule l'objectif en une phrase : toute conclusion importante doit rester rattachée à des événements persistés, des artefacts et des preuves de graphe. C'est le contraire d'un rapport généré à la fin à partir de l'historique du modèle. Le public visé est précis : des équipes qui font du pentest autorisé et qui doivent ensuite justifier chaque constat auprès d'un client ou d'un auditeur. Si votre besoin est de lancer un scan et de lire une sortie, ce projet n'est pas le bon outil, et le README ne prétend pas le contraire.

Trois rôles, trois sessions Pi distinctes

La v2 remplace la boucle P-E-R à historique partagé par des frontières d'exécution explicites. Le Planner lit des vues compactes des graphes de tâches, de raisonnement et d'opérations, puis crée ou modifie des tâches au niveau des objectifs au lieu de prescrire des actions bas niveau. Il contrôle les dépendances, la priorité, la concurrence entre tâches indépendantes, le périmètre et les budgets, et soumet ses décisions via l'outil terminal planner_submit. L'Executor reçoit un TaskEnvelope borné, choisit lui-même sa stratégie d'outils, et rend son résultat via task_result_submit. Détail d'implémentation qui compte : un même Task réutilise la même lignée de session Pi et le même workspace d'un epoch à l'autre, alors que des Tasks différents restent isolés. L'Observer se dédouble. Le mode Supervisor examine les actions récentes de l'Executor et tranche entre continuer, poser un checkpoint, arrêter ou rendre la main au Planner. Le mode Projector convertit en asynchrone les observations normalisées en deltas de graphe. Chaque invocation ouvre une session Pi neuve, sans historique caché partagé. Les deux modes passent par control_submit et graph_delta_submit. Ce découpage a un coût : trois contrats d'appel à maintenir, et aucune trace d'un raisonnement qui n'aurait pas été soumis par l'un de ces outils.

Du constat à l'exploit : la forme du graphe causal

Le graphe relie Evidence, Hypothesis, Vulnerability, Exploit et les entités WebEndpoint ou Service. Les arêtes portent une sémantique directionnelle : une preuve soutient ou contredit une hypothèse, une hypothèse confirme une vulnérabilité, une vulnérabilité est exploitée par un exploit, une preuve est observée sur un endpoint. Deux choix de conception méritent d'être signalés. D'abord, l'incertitude est explicite : une hypothèse n'est pas une vulnérabilité confirmée, et les nœuds Vulnerability confirmés ou Exploit réussis ne peuvent pas être écrits sans référence à une preuve. Ensuite, la projection est asynchrone : le Projector produit les deltas sans bloquer la boucle de l'Executor. Le revers est une fenêtre de latence entre l'action et son inscription dans le graphe. Le README ne décrit pas de mécanisme de reprise si le processus tombe pendant cette fenêtre, et je ne peux pas affirmer depuis ce document que les observations en vol sont rejouées.

Planifier sur le graphe plutôt que régénérer une liste

Le Planner maintient un Task Graph évolutif au lieu de réécrire une checklist linéaire. Le README donne l'exemple d'un Goal qui se ramifie vers une tâche Recon et une tâche Auth, la première produisant un jalon Service Profile qui alimente une tâche Validate, la seconde alimentant la même Validate, avec un Blocker qui bloque cette dernière. Les opérations exposées sont nommées : create_tasks, patch_task, replace_dependencies, set_task_status. Un point de comportement est décrit explicitement : après un changement de graphe ou un transfert de tâche, le Planner réconcilie les tâches prêtes avec la capacité disponible sans attendre la fin d'une vague parallèle complète. C'est ce qui distingue un ordonnanceur incrémental d'un planificateur par lots, et c'est aussi ce qui rend l'état du graphe difficile à prédire à la lecture d'un seul instantané.

Mise en route : ce que le dépôt donne réellement

Le README annonce une section Quick Start, mais le matériel fourni s'arrête avant son contenu. Les seules contraintes d'exécution confirmées viennent des badges et de l'introduction : Node.js 25 ou plus récent, TypeScript 5.x, et un runtime Pi SDK. La licence est AGPL-3.0, avec le texte complet référencé sur gnu.org. Aucune commande d'installation, aucun nom de fichier de configuration, aucune variable d'environnement et aucun exemple de clé de configuration ne figurent dans les extraits dont je dispose. Je ne peux donc pas écrire npm install ni décrire un fichier de settings sans inventer. Ce qu'on peut affirmer, c'est que la v2 n'est pas un refactoring en place du runtime Python v1 : le README insiste sur des contrats de configuration, de persistance, de cycle de vie des agents et d'observabilité différents. Toute documentation v1 trouvée en ligne risque donc de ne pas s'appliquer.

Deux limites assumées, et un avertissement sur les chiffres

La première limite est un choix de licence. AGPL-3.0 est une licence copyleft forte avec une clause réseau : si vous exposez une version modifiée du logiciel comme service à des utilisateurs, l'obligation de fournir le code source correspondant peut s'appliquer. Pour un outil de sécurité utilisé en interne, cela se gère ; pour un service hébergé, cela se discute avec un juriste, pas avec un README. La seconde limite est méthodologique, et le projet la documente lui-même : les résultats de benchmark rapportés par la v1 ne sont pas automatiquement attribués à la v2, et les résultats v2 ne seront publiés qu'après des reruns reproductibles sur une release figée. Autrement dit, au moment de la rédaction, il n'existe pas de chiffre v2 publiable. C'est honnête, et c'est aussi une raison de ne pas dimensionner un déploiement sur la réputation de la v1. Un troisième point, plus structurel : un agent qui exécute des actions offensives dans un workspace isolé reste un agent qui exécute des actions offensives. Le README cadre le projet sur la recherche en sécurité autorisée, et rien dans le matériel ne décrit de garde-fou technique limitant la cible.

Face à un agent à boucle unique

L'alternative la plus directe est un agent à boucle unique de type plan-execute-reflect, où un seul modèle conserve l'historique de la mission et enchaîne les appels d'outils. C'est plus simple à écrire, plus simple à déboguer, et cela tient dans un seul prompt système. La différence d'approche est nette : dans un agent à boucle unique, la mémoire du raisonnement est l'historique de conversation du modèle, donc elle disparaît avec la session et n'est pas requêtable. LuaN1aoAgent déplace cette mémoire dans un graphe persistant dont les nœuds confirmés exigent une référence à une preuve. Le prix est une architecture plus lourde : deux modes d'Observer, trois outils de soumission structurée, des artefacts immuables pour les sorties volumineuses, et une projection asynchrone à surveiller. Pour une exploration ponctuelle, la boucle unique gagne. Pour un engagement où quelqu'un devra relire le chemin entre une observation et une conclusion, l'écart se justifie.

Ce qu'il faut vérifier avant de s'engager

Le dépôt est actif, la dernière poussée est datée du 24 août 2026, et deux releases coexistent : v1.0.0 étiquetée Legacy et v2.0.0 du 20 juillet 2026. Cette coexistence signifie que des guides, des scripts et des tickets v1 circulent encore, et que la première source d'erreur sera d'appliquer une configuration v1 à un runtime v2. La page d'accueil du dépôt est vide, donc il n'existe pas de documentation hébergée en dehors du README et du dossier docs/assets, qui ne contient d'après les extraits que des captures et une vidéo de démonstration. Concrètement, la vérification utile porte sur trois éléments absents du matériel fourni : le fichier de configuration attendu par la v2, la commande exacte de démarrage, et la manière dont les artefacts et les événements sont persistés sur disque. Tant que ces trois points ne sont pas lus dans le dépôt lui-même, l'adoption reste une hypothèse de travail.

Conclusion éditoriale

LuaN1aoAgent v2 s'adresse aux équipes qui font déjà du pentest autorisé et veulent un journal de preuves exploitable plutôt qu'un transcript de conversation. À éviter si vous cherchez un scanner prêt à l'emploi ou si vous ne pouvez pas faire tourner Node.js 25+ et un workspace isolé. Avant d'adopter, vérifiez deux points précis : la présence des contrats de configuration et de persistance annoncés comme différents de la v1, et la publication de résultats de benchmark reproductibles sur une release figée, que le README annonce mais ne fournit pas encore.

Sources officielles

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. SanMuzZzZz/LuaN1aoAgent on GitHub