Technische Analyse 020｜ARTEX: Penetrationstest in den Agent-Workflow verlagert, Backup-Repo 721 Stars an einem Tag

Am 8. Oktober tauchte auf GitHub das Repository mhtsec/ARTEX auf, mit einer einzeiligen Selbstvorstellung im About-Bereich: Autonomes KI-Penetrationstest-System, Siegerprojekt des Baidu ‘agent+’ Attack-Defense-Challenge-Wettbewerbs (laut Eigenangabe des Projekts). Einen Tag später, 721 Stars. Es ist nicht einfach noch ein Scanner-Skript, sondern ein vollständiges Multi-Agent-System: Go-Backend mit 327 Quelldateien, das Agent-Paket mit über 10.000 Zeilen, Next.js-Frontend eingebettet in ein einzelnes Binary, in PostgreSQL werden zwei Graphen gespeichert. Noch interessanter ist die Identität des Repos: Der erste Bildschirm des READMEs erklärt direkt, dass es sich um ein ‘Backup des reinen Quellcodes der letzten Version’ handelt, und das Original-Repository ist bereits unzugänglich. Dieser Artikel zerlegt es anhand von sechs Aspekten: Was es ist, Warum jetzt, Kernmechanismen, Zahlen & Grenzen, Wie man es ausführt, und Wertung.

1. Was ist es

Zuerst zur Identität des Repositories: Hier gibt es einen Punkt, der leicht falsch geschrieben wird. mhtsec/ARTEX ist ein Backup-Repository: Das README gibt an: „Dieses Repository ist ein reines Quellcode-Backup der letzten Version von ARTEX“, und merkt an, dass die Docker-Deployment-Quelle ungültig ist und es lokal selbst gebaut werden muss. In den Installationsskripten des Repositories ist die Clone-Adresse weiterhin Autumn-27/ARTEX. Dieses ursprüngliche Repository gibt auf GitHub bereits einen 404-Fehler zurück; ob es gelöscht oder auf privat umgestellt wurde, ist unbekannt. Das heißt, die Entwicklungsgeschichte des Projekts, Issues und Releases verbleiben im ursprünglichen Repository; das jetzige Repository ist lediglich ein eingefrorener Quellcode-Stand. Die 721 Sterne spiegeln die Aufmerksamkeit der Sicherheitscommunity innerhalb eines einzigen Tages für das „Quellcode-Backup des Champion-Projekts“ wider, nicht die über einen langen Zeitraum aufgebaute Reputation des Projekts.

Nun zum System selbst. ARTEX ist ein vollständiges Projekt, das Penetrationstests in einen Agent-Workflow umsetzt: Das Backend basiert auf Go, mit 327 .go-Dateien, davon 10391 Zeilen im Agent-Paket; das Frontend wird nach statischem Export durch Next.js mittels go:embed in eine einzelne Binärdatei eingebettet; die Datenbank ist PostgreSQL. Die Kernabhängigkeiten umfassen nur eine Zeile: die eigene Agent-Framework-Bibliothek des Autors, norma (welche Module wie agentcore, tool, permission und transcript bereitstellt), sowie einige grundlegende Bibliotheken. Die Lizenz ist AGPL-3.0, jedoch fügt das Ende des READMEs eine weitere Schicht von Nutzungsbeschränkungen hinzu, die strenger sind als die Lizenz; darauf wird später eingegangen.

Das Skelett des Systems ist eine Multi-Agenten-Arbeitsteilung: planner (Planer) ist für die Planung zuständig, worker (Arbeiter) für die Ausführung und mainagent (Hauptagent) übernimmt den Dialog im Human-in-the-Loop. Der Träger dieser Arbeitsteilung sind zwei Graphen: der Asset-Graph (Vermögensgraph) und der Explorations-Graph (Erkundungsgraph); der Mechanismus wird im dritten Abschnitt erläutert.

II. Warum es sich jetzt lohnt anzusehen

Drei Gründe.

Erstens, Penetrationstests mit LLM (Large Language Models) sind aktuell eine Trendrichtung bei Sicherheitswettbewerben; Angriffs- und Verteidigungsherausforderungen wie „agent+“ haben sie zu einer offiziellen Disziplin gemacht. ARTEX präsentiert sich (laut eigener Aussage) als Champion-Projekt und erscheint genau jetzt; das ist an sich schon ein Trendindikator: Die Wettbewerbe zwingen die Teams, das Agent-Engineering bis zur Einsatzreife zu bringen. Wie die Champion-Lösung aussieht, ist einen Blick wert.

Zweitens, die generischen Komponenten des Agent-Engineering sind bereits ausgereift. Ereignisgesteuertes Scheduling, sitzungsübergreifender Shared Storage, Tool-Genehmigungsgates und Audit-Trails – diese Komponenten wurden in Szenarien wie Programmierassistenten und automatisiertem IT-Betrieb über ein Jahr lang optimiert. ARTEX integriert sie in einer vertikalen Domäne. Zu sehen, wie es zusammengesetzt wird und was im Sicherheitsszenario modifiziert wurde, ist wertvoller als zehn Konzept-Papiere zu lesen.

Drittens, es bildet genau den richtigen Abschluss. Zum Thema KI-Sicherheit haben wir zuvor bereits über die Angriffsseite (Vergiften des Modells) und die Verteidigungsseite (komplettes Entwenden der Gewichte) gesprochen; diese Ausgabe fügt den Teil dazwischen hinzu: Der Angriffs- und Verteidigungs-Workflow selbst wird von Agenten neu geschrieben. Verbindet man die drei Teile – Angriff, Verteidigung, Workflow –, ist das Gesamtbild dieser Richtung vollständig.

3. Kerntechnische Mechanismen

Vierer-Set: ereignisgesteuerter Planner, Dual-Graph plus Blackboard, Intercept-Approval, Evidenzkette. Wir betrachten sie einzeln.

Ereignisgesteuerter Planner. Die Kommentare in agent/planner.go beschreiben die Positionierung: „Planner is the event-driven LLM planner“. Er führt kein Polling durch, sondern wird geweckt, sobald sich der Asset-Graph oder der Explorations-Graph ändert (mit Entprellung/Debouncing, um Ketten-Dispatching durch Graph-Fluktuationen zu vermeiden). Nach dem Aufwachen liest er die aktuelle Situation, beurteilt, ob das Ziel erreicht ist, und weist dann 0 bis N Explorationsintentionen der Warteschlange (frontier) zu. Zwei Design-Aspekte sind erwähnenswert: Erstens ist er der „einzige Intention-Generator“ im gesamten System; Worker empfangen nur Intentionen und generieren keine, die Planungsbefugnis wird nicht verteilt. Zweitens weisen die meisten Aufweckungen 0 Intentionen zu: Wenn es keine neue Richtung gibt, ist er stumm und sucht nicht krampfhaft nach Arbeit. Zusätzlich gibt es die zwei Callbacks killWork und steerWork, mit denen laufende Arbeiten midway abgebrochen oder umgelenkt werden können; kalte Knoten (Cold Nodes) verfügen über einen Komprimierungsmechanismus, der die Kontextlänge von Langzeitaufgaben kontrolliert.

Geteilte todolist. Jedes Aufwecken des Planners ist eine neue Session, er ist selbst zustandslos. Der tatsächliche Nutzungsprozess ist jedoch oft eine mehrstufige Sequenz mit Vorwärtsabhängigkeiten, bei der der Output eines Schritts der Input des nächsten ist; eine einmalige parallele Zuweisung würde nur Chaos verursachen. Die Lösung ist eine nach Aufgabe aufbewahrte, über Aufweckungen hinweg geteilte Todolist: Der Planner zeichnet eine serielle Nutzungskette einmal auf und weist danach in jeder Runde nur für den nächsten Schritt, dessen „vorheriger Schritt abgeschlossen ist“, eine Intention zu. Mit dem sukzessiven Zurückschreiben von Fakten werden die folgenden Schritte schrittweise freigeschaltet. In einer Umgebung aus Ereignissteuerung und zustandslosen Sessions können so mehrstufige Sequenzen stabil voranschreiten, ohne Wiederholungen oder falsche Reihenfolgen. Dies ist ein Schlüsselschritt, damit das System lange Prozesse autonom durchlaufen kann.

Dual-Graph und Blackboard. „Was ist das Ziel“ und „Inwieweit wurde es getestet“ werden in zwei Graphen aufgeteilt. Der Asset-Graph ist global geteilt; die Knoten reichen von Root-Domain, Subdomain bis IP, Service, Endpunkt. Eltern-Kind-Beziehungen und Deduplizierungsschlüssel werden vollständig vom Programm berechnet, der Agent reicht nur Rohinformationen ein und ist nicht für die Erkennung von Duplikaten zuständig. Der Explorations-Graph ist pro Aufgabe unabhängig; die Knoten sind Ziele, Intentionen, Fakten, Schwachstellen (Vulnerabilities), Hinweise, die durch Kanten wie Ableitung (Derivation), Output (Produktion), Beweis (Proof) zu einer Abstammung verbunden sind. Welche Richtung von welchen Fakten abgeleitet wurde und was produziert wurde, ist im Graphen nachvollziehbar. Die beiden Graphen sind über Ankerpunkte verbunden, sodass man sowohl in Explorationsrichtung sehen kann, welche Assets berührt wurden, als auch rückverfolgen kann, von welchen Intentionen ein bestimmtes Asset getestet wurde. Zwischen den Aufgaben wird der Zustand über ein Blackboard übergeben: Nachfolgende Aufgaben sehen eine Read-Only-Ansicht der aktiven Daten der vorherigen Aufgaben; die geerbten Schwachstellen-Evidenzen sind schreibgeschützt und können nicht geändert werden. Zustände können vererbt werden, aber Kontamination (Pollution) wird blockiert.

Intercept-Approval. Das System hat für Tool-Aufrufe eine Freigabeschranke (Approval Gate) eingerichtet. Eingebaute Regeln blockieren zuerst eindeutig destruktive Operationen: Neben der HTTP DELETE Methode wurde noch eine Regel für „Delete-ähnliche API-Pfade“ hinzugefügt, die Requests abdeckt, deren Pfade /delete, /del, /remove, /unlink, /erase, /destroy enthalten. Dabei wird gefordert, dass auf das Verb ein Trennzeichen folgen muss, sodass /delivery, /details etc. nicht fälschlicherweise abgefangen werden. Das Motiv für diese Ergänzungsregel ist im Changelog dokumentiert: Bei den meisten Anwendungen können Delete-Interfaces bereits mit GET oder POST ausgelöst werden; sich nur auf die DELETE-Methode zu verlassen, reicht zur Blockierung nicht aus. Der Teil außerhalb der Regeln wird an eine „Modell-Fallback-Approval“ übergeben, bei der das LLM über die Freigabe entscheidet; der Token-Verbrauch dieses Bereichs wird separat erfasst, und die Benutzeroberfläche bietet eine Verbrauchskarte (Usage Card) sowie ein tägliches Balkendiagramm für die letzten 30 Tage. Die Freigabe selbst kostet Modell-Geld, und wie viel es kostet, wird offen vor Ihnen ausgewiesen.

Evidenzkette. Dies ist das Element, das die meiste Engineering-Leistung erfordert. Die Bindung zwischen Schwachstellen und Traffic ist Many-to-Many; jede Bindung wird mit einem von vier Verwendungszwecken markiert: baseline (normale Kontrolle), proof (Schwachstellen-Beweis), verification (ergänzende Verifikation), supporting (unterstützende Evidenz). Bei der Bindung wird der entsprechende Traffic nach SHA-256-Hash als Evidenzdatei abgelegt; mehrere Schwachstellen können sich dieselbe Evidenzdatei teilen. In der Dokumentation wird eine Designphilosophie explizit genannt: Das System rät Bindungen nicht anhand von Domainnamen, Zeit oder Browserverlauf: Um Fehlzuschreibungen zu vermeiden, wird man lieber eine explizite Auswahl treffen lassen, als für Sie zu raten. Berichte werden in einem zweistufigen Prozess von einem unabhängigen Berichts-Agent generiert: Nach dem Eintragen der Entdeckung in die Datenbank wird dieser automatisch ausgelöst, verifiziert und bindet den Traffic, um den Bericht basierend auf der neuesten Evidenzversion zu schreiben; das Schreiben erfolgt mit einem evidence_version Optimistic Lock. Wenn sich die Evidenz während der Generierung ändert, wird das Überschreiben durch eine alte Version abgelehnt; bei Versionskonflikten wird 409 zurückgegeben, und beim Versuch, auf geerbte Evidenz zu schreiben, wird 403 zurückgegeben.

Ein ergänzender Satz zum Code-Qualitätsprofil: Im Changelog der Version 0.3.15 (7. Oktober) findet sich die Aufzeichnung einer vollständigen Sicherheitsaudit-Runde, unter den mehr als zehn Fixes befindet sich eine als „kritisch“ eingestufte Konfigurations-Merge-Schwachstelle (Credential-Masking kann durch eine bestimmte Commit-Methode umgangen werden), jede wurde zunächst reproduziert, dann behoben und mit einem Regressionstest ergänzt; im agent-Paket gibt es für nahezu jede Kerndatei eine zugehörige Testdatei. Backup-Repo, aber kein nachlässiges Repo.

IV. Zahlen und Grenzen

Zahlen im Überblick: 721 Stars (Stand: 9. Oktober, an einem Tag); 327 .go-Dateien; agent-Paket 10391 Zeilen; Go-Backend plus Next.js-Frontend plus PostgreSQL; Abhängigkeits-Framework norma v0.4.3; AGPL-3.0; letzte Version 0.3.15, datiert auf den 7. Oktober, Repository öffentlich am 8. Oktober.

Vier Punkte zu den Grenzen.

Erstens: Der Champions-Titel ist eine Eigenaussage. „Champion des Baidu agent+ Angriffs- und Verteidigungswettbewerbs“ erscheint nur in der About-Beschreibung des Repositories; für den Wettbewerb selbst konnten keine unabhängigen Berichte oder öffentliche Ranglisten zur Überprüfung gefunden werden. Dieser Titel sollte als Selbstvorstellung des Projektteams angehört werden, nicht als Zeugnis verwendet werden.

Zweitens: Die Bedeutung der Star-Zahl ist mit Abstrichen zu verstehen. 721 Stars an einem Tag messen lediglich die durch Weiterverbreitung entstandene Aufmerksamkeit der Security-Community, nicht die Akkumulation langfristiger Nutzer; das Original-Repository gibt bereits einen 404-Fehler, die Entwicklungsgeschichte kann nicht abgeglichen werden. Was dieser Quellcode vor der Sicherung durchgemacht hat, ist für die Außenwelt nicht sichtbar.

Drittens: Die Wartbarkeit bei einem einzelnen Autor und einem eingefrorenen Archiv. Die Liste der Mitwirkenden von 0.3.15 enthält nur den Autor selbst; das README stellt ausdrücklich klar, dass dies ein Backup der letzten Version ist. Dieser Quellcode wird höchstwahrscheinlich keine weiteren Commits mehr erhalten; beim Lesen und Verwenden muss man von der Erwartung eines „eingefrorenen Archivs“ ausgehen.

Viertens: Die Haftungsausschlüsse sind strenger als bei üblichen Penetrationswerkzeugen. Der Haftungsausschluss der meisten Penetrationswerkzeuge lautet „nur für autorisierte Tests“, ARTEX schreibt jedoch ausdrücklich vor: Das Starten von Scans, Erkundungen, Ausnutzungen oder Angriffen gegen jede Website, jeden Online-Dienst oder jedes vernetzte System ist strengstens untersagt. In Klammern wird ausdrücklich hinzugefügt: „unabhängig davon, ob eine Autorisierung vorliegt oder ob es sich um eigene Vermögenswerte handelt“. Selbst autorisierte Online-Tests sind verboten; es bleiben nur drei Ausnahmen offen: persönliches Lernen, Code-Forschung und die Verifizierung in einer lokal isolierten Umgebung.

Fünf: Wie man es startet und wer es nutzen kann

Zuerst zum Starten innerhalb der Grenzen: Es hängt von drei Dingen ab: einer PostgreSQL-Instanz, einem LLM-Key (ANTHROPIC oder OPENAI, kann auch im Interface konfiguriert werden) und einer lokal isolierten Umgebung. Für die Bereitstellung gibt es zwei Wege: Das install-Skript führt zur Wahl zwischen vollständigem Docker oder lokaler Kompilierung, wobei letztere mit Go eine einzelne Binärdatei mit eingebettetem Frontend kompiliert. Nach dem Start läuft der Dienst auf dem lokalen Port 8787; beim ersten Aufruf wird das Administratorpasswort festgelegt. Beachten Sie die Besonderheit des Backup-Repositorys: Die im README (Readme) angegebene Docker-Bereitstellungsquelle ist bereits veraltet. Wenn das Image nicht gepullt werden kann, muss es lokal gebaut werden; der Autor empfiehlt sogar: „Lassen Sie die AI (KI) für Sie lokal bauen“. Im Ökosystem kann es Assets mit dem Asset-Mapping-Tool ScopeSentry desselben Autors synchronisieren und nach Projekt- oder Aufgabendimension importieren.

Gehen wir auf drei Benutzergruppen ein. Für Experten im Angriffs- und Verteidigungsengineering: Dual-Graph, Approval-Gate und Evidence-Chain sind Architekturmuster, die direkt übernommen werden können, insbesondere die letzteren beiden – sie gelten auch in anderen Domänen. Für Agent-Entwickler: Ereignisgesteuert plus zustandslose Sitzungen plus geteilte Todolisten sind eine fertige Antwort auf die Frage „Wie mehrstufige Prozesse in einer zustandslosen Umgebung stabil voranschreiten können“; planner.go ist es wert, als Ganzes gelesen zu werden. Für Sicherheitsforscher: Die Evidence-Chain mit Vier-Zweck-Bindung plus optimistischem Locking ist eine Referenzimplementierung für „Wie Agent-Ergebnisse zu auditierbaren Beweisen werden“.

Für diejenigen, die nur zuschauen möchten, ist der Einstieg mit der geringsten Hürde die im README angegebene Online-Demo-Seite. Klicken Sie darauf, um zu sehen, wie die Benutzeroberfläche für Aufgaben, Assets, Erkundungsprozesse und Genehmigungsdatensätze aussieht, bevor Sie entscheiden, ob Sie den Quellcode lesen möchten.

6. Werturteil und Zielgruppe

Stichprobenwert: Hoch. Es verwandelt „KI-gestützte Penetrationstests“ von Wettbewerbssiegen und Demovideos in einen zeilenweise lesbaren Quellcode. Um den tatsächlichen Reifegrad eines Agentensystems zu beurteilen, prüfe ich drei Aspekte: ob die Planungsbefugnis zentralisiert ist, ob die Ausführung protokolliert wird und ob der Output auditierbar ist. ARTEX liefert für alle drei Aspekte technische Antworten: einen einzigen Intent-Generator, einen durchgängig protokollierenden Recording-Agenten und eine Beweiskette mit Hash- und Versionssperre.

Branchenwert: Dies ist eine Neuschreibung des Workflows, nicht bloß ein Werkzeugersatz. Die große Menge an Enumeration, Trial-and-Error, Protokollierung und Sortierung in Penetrationstests ist klassische Knochenarbeit; die von ARTEX gezeigte Arbeitsteilung ist: Agenten übernehmen die Knochenarbeit, Menschen bewachen die Schlüsselentscheidungen, Approval-Gates blockieren destruktive Operationen, und die Beweiskette ermöglicht es, die Schlussfolgerungen des Agenten Punkt für Punkt zu überprüfen. Für das Red Team bedeutet dies eine Produktivitätssteigerung: Repetitive Arbeit wird eliminiert, und Menschen konzentrieren sich auf die Phasen, die wirklich Urteilskraft erfordern; für das Blue Team bedeutet dies eine Eskalation der Konfrontation: Low-Cost-Automatisierung wird die Frequenz von Reconnaissance und Versuchen insgesamt anheben, und die Verteidigungsseite benötigt ebenfalls agentenbasierte Detection und Response. Angriffs- und Verteidigungsseite werden von demselben Quellcode in dieselbe Richtung gedrängt.

Grenzen erneut festnageln: Für die Effektivität liegen keine Drittanbieterdaten vor, der Champion-Status ist eine Eigenaussage, und das Repository ist ein eingefrorenes Backup. Ob es sich lohnt, Zeit darauf zu verwenden, hängt davon ab, was man mitnehmen möchte. Nimmt man die Architektur mit (Approval-Gates, Beweiskette, geteilte To-dos), ist sie überall einsetzbar; möchte man ein sofort einsatzbereites Penetrationswerkzeug mitnehmen, verstößt dies sowohl gegen seine Bestimmungen als auch überschätzt es seine Positionierung.

Urteil in einem Satz: Die Bedeutung von ARTEX liegt nicht im Champion-Titel, sondern darin, dass es „autonome Agenten für Sicherheitstests“ von einem Schlagwort in einen Engineering-Prozess mit Genehmigungen, Beweisen und Nachvollziehbarkeit übersetzt hat. Für die Automatisierung in diese Richtung fehlt es nie an Demonstrationen; was fehlt, ist diese auditierbare Zurückhaltung.

Referenzquellen

• Haupt-Repository: github.com/mhtsec/ARTEX (nach lokalem Klonen elementweiser Vergleich von README, CHANGELOG, docs/vulnerability-traffic-evidence.md, Quellcode des agent-Pakets, go.mod, git log; keine Builds ausgeführt)
• GitHub API (721★, “about”-Beschreibung, Erstellungsdatum 2026-10-08)
• Ursprüngliches Repository Autumn-27/ARTEX, API gibt 404 zurück (gelöscht oder privatisiert, Grund nicht verifiziert)
• Die Sternzahl 721★ entspricht dem Stand vom 2026-10-09 und ändert sich weiterhin