LuaN1aoAgent v2: ein Pentest-Agent, der seine Schlussfolgerungen an Ereignisse bindet
LuaN1aoAgent is a fully autonomous AI-driven penetration testing agent powered by graph-based cognitive reasoning.
Auf einen Blick
- Was ist das?
- LuaN1aoAgent v2 ist eine TypeScript-Neuimplementierung eines autonomen Pentest-Agenten mit Planner, Executor und Observer. Der interessanteste Teil ist nicht die Autonomie, sondern die Herkunftspflicht: bestätigte Schwachstellen und erfolgreiche Exploits lassen sich laut README nicht ohne Evidenzverweise schreiben.
- Für wen ist es gedacht?
- Wer autorisierte Sicherheitsforschung mit nachvollziehbaren Belegen dokumentieren muss und Node.js 25 sowie die Pi-SDK-Laufzeit bereitstellen kann, findet in v2 ein Rollenmodell, das Evidenz strukturell erzwingt statt sie nur zu protokollieren.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem die Rollentrennung adressiert
Autonome Agenten, die mehrere Werkzeuge hintereinander aufrufen, haben ein bekanntes Gedächtnisproblem. Alles landet in einem gemeinsamen Verlauf, und am Ende steht ein Ergebnis, von dem niemand mehr sagen kann, welcher Werkzeugaufruf es gestützt hat. Das README von LuaN1aoAgent v2 nennt genau diesen Punkt als Motiv für den Umbau: v2 ersetzt die Schleife aus Planen, Ausführen und Reflektieren mit gemeinsamem Verlauf durch explizite Laufzeitgrenzen. Adressaten sind Sicherheitsteams, die autorisierte Tests durchführen und dabei nicht nur ein Ergebnis, sondern eine Kette aus Ereignissen, Artefakten und Graphknoten vorlegen müssen. Das ist ein Dokumentationsproblem, kein Ausnutzungsproblem, und die Architektur ist entsprechend geschnitten.
Drei Rollen, zwei davon mit eigenen Pi-Sessions
Der Planner liest kompakte Ansichten des Task-, Reasoning- und Operation-Graphen und erzeugt oder verändert Aufgaben auf Zielebene. Er legt Abhängigkeiten, Priorität, Scope und Aufgabenbudgets fest und schreibt seine Entscheidungen über das strukturierte Werkzeug planner_submit. Der Executor bekommt ein begrenztes TaskEnvelope und wählt seine Werkzeugstrategie selbst. Er protokolliert Absicht, Eingabe, Ausgabe, Fehler und Ergebnis und legt große Ausgaben als unveränderliche Artefakte ab, statt den Kontext aufzublähen. Innerhalb einer Aufgabe teilen Epochen dieselbe persistierte Pi-Session und denselben Arbeitsbereich, verschiedene Aufgaben bleiben getrennt. Ergebnisse laufen über task_result_submit.
Der Observer zerfällt in zwei Modi. Der Supervisor sieht sich die letzten Executor-Aktionen an und entscheidet, ob es weitergeht, ein Checkpoint gesetzt, abgebrochen oder die Kontrolle an den Planner zurückgegeben wird. Der Projector wandelt normalisierte Beobachtungen asynchron in Graph-Deltas um. Beide starten laut README für jeden Aufruf eine frische Pi-Session ohne geteilten versteckten Modellverlauf, und beide melden über control_submit beziehungsweise graph_delta_submit. Bemerkenswert ist die Asymmetrie: Der Supervisor sitzt im heißen Pfad, der Projector nicht. Genau diese Trennung erlaubt es, den Executor weiterlaufen zu lassen, während die Graphpflege nachzieht.
Evidenzpflicht im Reasoning-Graph
Der Reasoning-Graph kennt vier Knotenarten: Evidence, Hypothesis, Vulnerability und Exploit, dazu WebEndpoint und Service im Operation-Graph. Kanten drücken unterstützt, widerspricht, bestätigt und ausgenutzt durch aus. Der entscheidende Punkt steht im README als Regel: Bestätigte Vulnerability-Knoten und erfolgreiche Exploit-Knoten können nicht ohne Evidenzverweise geschrieben werden. Hypothesen bleiben von bestätigten Schwachstellen getrennt, und die Projektion erfolgt asynchron, damit sie die Executor-Schleife nicht blockiert.
Das ist eine Designentscheidung mit Kosten. Ein Agent, der eine offensichtliche Schwachstelle sieht, sie aber nicht auf ein persistiertes Ereignis zurückführen kann, darf sie nicht als bestätigt eintragen. Das Modell muss also entweder den passenden Beleg erneut erzeugen oder den Knoten als Hypothese führen. Wer erwartet, dass ein Agent einfach Ergebnisse ausgibt, wird hier gebremst. Wer Ergebnisse später verteidigen muss, gewinnt genau dadurch.
Aufgabenplanung als Graph, nicht als Checkliste
Der Planner hält einen wachsenden Task-Graph statt einer neu erzeugten linearen Liste. Das README zeigt die Struktur als Ablauf von einem Goal zu Recon- und Auth-Aufgaben, die beide in einen Validation-Aufgabenknoten münden, mit einem Service Profile als Zwischenmeilenstein und einem Blocker, der die Validierung sperrt. Die Graphoperationen heißen create_tasks, patch_task, replace_dependencies und set_task_status. Nach Graphänderungen und Aufgabenübergaben gleicht der Planner bereite Aufgaben gegen freie Kapazität ab, ohne auf das Ende einer gesamten parallelen Welle zu warten.
Das ist der praktisch relevante Unterschied zu einem starren Plan. Eine Recon-Aufgabe kann einen Meilenstein liefern, der eine Validierungsaufgabe freischaltet, während eine zweite Aufgabe noch läuft. Ob das in der Praxis schneller ist als ein wellenweiser Ablauf, lässt sich aus dem Material nicht belegen. Das README beschreibt die Mechanik, nicht das Ergebnis.
Inbetriebnahme: Node 25, Pi SDK, strukturierte Werkzeuge
Die Abhängigkeiten sind im README über Badges benannt: Node.js 25 oder neuer, TypeScript 5.x, Laufzeit Pi SDK. Die Architektur trägt die Bezeichnung P-E-O. Ein Installationsabschnitt ist im vorliegenden Material nicht enthalten, konkrete npm-Befehle lassen sich daraus also nicht ableiten. Was sich ableiten lässt, sind die Schnittstellen, an denen eine Einbindung ansetzt: planner_submit, task_result_submit, control_submit und graph_delta_submit sind die strukturierten terminierenden Werkzeuge der drei Rollen, create_tasks, patch_task, replace_dependencies und set_task_status die Graphoperationen des Planners. Wer die Konfiguration plant, muss außerdem die Budget- und Scope-Steuerung des Planners abbilden, denn das README nennt Scope und Aufgabenbudgets ausdrücklich als seine Zuständigkeit. Ein Konfigurationsbeispiel mit Schlüsselnamen liefert das README nicht, das ist eine echte Lücke für die Bewertung.
Wo v2 die falsche Wahl ist
Die wichtigste Einschränkung steht in einer Warnung des README selbst: v2 ist kein In-Place-Refactoring der Python-Laufzeit von v1, sondern eine neue Implementierung mit anderen Verträgen für Konfiguration, Persistenz, Agent-Lebenszyklus und Observability. Wer v1 produktiv betreibt, hat damit keine Upgrade-Pfad-Zusage. Dazu kommt ein zweiter Hinweis: Benchmark-Ergebnisse, die für v1 berichtet wurden, gelten nicht automatisch für v2, und v2-Ergebnisse sollen erst nach reproduzierbaren Läufen auf einem eingefrorenen Release veröffentlicht werden. Für eine Adoption heißt das, dass es derzeit keine belastbare Leistungsgrundlage gibt, weder positiv noch negativ.
Ein weiterer Punkt ist der Zuschnitt. Wer einen einmaligen, kurzen Scan gegen ein bekanntes Ziel fahren will, bezahlt hier für Graphpflege, Artefaktpersistenz und drei Agentenrollen, von denen zwei eigene Sessions starten. Der Aufwand lohnt sich, wenn Belegbarkeit das Ziel ist. Für einen schnellen Lauf ist er Ballast.
Was v1 anders macht und warum das den Vergleich prägt
v1 ist im Repository als Legacy-Release geführt und in Python geschrieben. Laut README arbeitete es mit einer Schleife aus Planen, Ausführen und Reflektieren auf einem gemeinsamen Verlauf, ohne die expliziten Laufzeitgrenzen und ohne die Evidenzpflicht des Reasoning-Graph. Der Unterschied liegt damit nicht in der Modellwahl, sondern in der Frage, wo der Zustand lebt. Bei v1 im Verlauf der Sitzung, bei v2 in persistierten Ereignissen, Artefakten und Graphknoten.
Daraus folgt die eigentliche Abwägung. v1 ist der leichtere Einstieg, wenn Python im Haus ist und niemand die Herkunft einer einzelnen Feststellung nachweisen muss. v2 verlangt Node.js 25 und eine andere Persistenzschicht, liefert dafür aber eine Struktur, in der eine bestätigte Schwachstelle ohne Beleg gar nicht erst entstehen kann. Wer aus einem v1-Benchmark eine Erwartung an v2 ableitet, überträgt Ergebnisse zwischen zwei nicht vergleichbaren Laufzeiten.
Lizenz und laufender Aufwand
LuaN1aoAgent steht unter AGPL-3.0. Das ist eine Copyleft-Lizenz mit Netzwerkwirkung: Wer eine veränderte Fassung als Dienst über ein Netzwerk bereitstellt, muss nach den Bedingungen der Lizenz den Quellcode dieser Fassung herausgeben. Für interne, nicht öffentlich erreichbare Nutzung ist die praktische Wirkung eine andere als für ein gehostetes Angebot. Das ist eine Einordnung, keine Rechtsberatung; die konkrete Bewertung gehört zu einer Rechtsabteilung, die den eigenen Betriebsmodus kennt.
Zum Wartungsaufwand lässt sich aus dem Material nur eines sicher sagen: Das Projekt verlangt Node.js 25 oder neuer, also eine Hauptversion, die nicht in jedem Unternehmen freigegeben ist. Dazu kommt die Pi-SDK-Laufzeit als zusätzliche Abhängigkeit. Die beiden Releases v1.0.0 und v2.0.0 tragen dasselbe Datum, v2.0.0 wurde am 20. Juli 2026 veröffentlicht, der letzte Push liegt auf dem 24. August 2026. Über Release-Kadenz oder Support-Zusagen sagt das nichts. Ob v1 weiter gepflegt wird, geht aus dem vorliegenden Material nicht hervor.
Redaktionelles Fazit
Wer autorisierte Sicherheitsforschung mit nachvollziehbaren Belegen dokumentieren muss und Node.js 25 sowie die Pi-SDK-Laufzeit bereitstellen kann, findet in v2 ein Rollenmodell, das Evidenz strukturell erzwingt statt sie nur zu protokollieren. Wer eine bestehende v1-Installation produktiv betreibt, sollte nicht auf v2 migrieren: Das README bezeichnet v2 ausdrücklich als Neuimplementierung mit anderen Konfigurations-, Persistenz- und Observability-Verträgen, nicht als In-Place-Refactoring. Zuerst zu prüfen ist, ob die eigene Node-Version die geforderte 25+ erfüllt und ob die im Repository dokumentierten Konfigurationsschlüssel für Planner-Budgets und Scope-Grenzen den eigenen Autorisierungsumfang abbilden. Ein Benchmark-Vergleich mit v1 ist derzeit nicht möglich, da v2-Ergebnisse laut README erst nach reproduzierbaren Läufen auf einem eingefrorenen Release veröffentlicht werden.
Community-Notizen