Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
autonomous-offensive-llm-handbook — Ein deterministischer Rahmen und Leitfaden für autonome offensive LLM-Agenten, der Autorisierungs-, Scope- und Evidenz-Gates durchsetzt, um reproduzierbare und ehrliche Penetrationstests zu gewährleisten. | Kitploit
Tools/GitHubGitHub/mouteee/autonomous-offensive-llm-handbook
SchwachstellenanalysePenetrationstestsPapers & ForschungLernen & BildungRed TeamingKuratierte RessourcenKI-Sicherheit
GitHubmouteee/autonomous-offensive-llm-handbook

autonomous-offensive-llm-handbook

Ein deterministischer Rahmen und Leitfaden für autonome offensive LLM-Agenten, der Autorisierungs-, Scope- und Evidenz-Gates durchsetzt, um reproduzierbare und ehrliche Penetrationstests zu gewährleisten.

Repository anzeigen
4vor 10h 19mNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Das Modell schlägt vor, der Code verfügt

Eine deterministische Testumgebung für autonome offensive Agenten. Das Modell bleibt probabilistisch. Die Host-Anwendung besitzt Autorisierung, erlaubte Aktionen, Evidenzaufzeichnungen und Akzeptanz. Das Abspielen eingefrorener Eingaben und Richtlinien kann diese Kontrollentscheidungen reproduzieren; es macht weder ein Live-Ziel noch eine Modellantwort wiederholbar.

Hier beginnen

  • Führen Sie das Offline-Harness-Labor aus: der empfohlene Lehrpfad, mit ausführbaren Steuerungen und einem vollständigen Bericht.
  • Prüfen Sie das Port-Manifest: gemessene und unbekannte Felder, Werkzeuganforderungen, Regeln, Evidenz-Fixtures und exakt autorisierte Ursprünge.
  • Lesen Sie die Implementierung und ihre adversarischen Tests.
  • Lesen Sie das historische Bauhandbuch und das Fehlermuseum, um zu sehen, warum jede Steuerung existiert.
root@kitploit:~
python3 -m pip install -r requirements.txt
python3 -m harness.demo --out /tmp/harness-report.json
diff -u harness/report.json /tmp/harness-report.json
python3 -m pytest tests/test_harness.py

Dieses Release ist auf CPython 3.14 verifiziert. Frühere Python-Versionen sind nicht Teil der Release-Evidenz; wenn Sie eine verwenden, führen Sie die vollständige Gate-Sequenz unten aus, bevor Sie sich auf das Ergebnis verlassen.

In Phasen aufbauen: Begrenzen Sie die Nebenwirkungsgrenze und die Phasenreihenfolge; Beschreiben Sie das Ziel durch gemessene Fakten und Kataloge; Beweisen Sie Behauptungen durch Erfassungen und unabhängige Richtlinienprädikate; Kontrollieren und abrechnen Sie Autorisierung, Gates, Abschluss und ausgelassene Arbeit. Die Entwicklungsreihenfolge ist nicht die Laufzeitreihenfolge: Autorisierung und Gate gehen dem Dispatch voraus.

Das öffentliche Labor stellt keine Netzwerkanfrage und ruft kein Modell auf. Sein Beweisprädikat ist synthetisch, sein Host und seine Adapter sind vertrauenswürdig, und jeder Befund ist als menschliche Überprüfung erfordernd markiert. Das Labor implementiert keine Akzeptanz- oder Berichtsunterzeichnungsworkflow einer Person. Ein wörtliches Zitat etabliert Zitatintegrität, nicht Ausnutzbarkeit. Weniger Modellaufrufe und weniger Nacharbeit sind Designziele, keine vom Korpus gemessenen Einsparungen.

Historische Fallstudie

Die Kapitel unten beschreiben die frühere core/- und walkthrough/-Implementierung und ihre veröffentlichten Defekte. Ihr fehlender modellaufrufender Verifizierer bleibt auf diesem historischen Pfad abwesend. Das neue harness/-Paket ist eine separate Offline-Kontrollreferenz; es repariert weder den Korpus noch die historischen Module rückwirkend. Lesen Sie Kapitel 07s Grenze und Korrekturen, bevor Sie eine historische Komponente kopieren.

Richten Sie ein fähiges Modell auf einen Host, geben Sie ihm einen Werkzeugkasten und sagen Sie ihm, es solle einen Penetrationstest ausführen, und es wird etwas Vernünftiges tun. Führen Sie es morgen erneut aus und es wird etwas anderes Vernünftiges tun, und keiner der Läufe kann Ihnen sagen, warum es übersprungen hat, was der andere erfasst hat. Dieses Handbuch argumentiert für eine kleinere Aufgabe für das Modell: Geben Sie jede Entscheidung der billigsten Schicht, die sie korrekt treffen kann, und geben Sie Modellkapazität nur dort aus, wo die Antwort wirklich nicht aus dem ableitbar ist, was Sie bereits haben. Diese Reihenfolge, von den Entscheidungen, die eine Tabelle treffen kann, bis zu den wenigen, die ein Modell benötigen, ist der Gradient im Titel von Kapitel 00. Die Kapitel folgen einem arbeitenden offensiven Sicherheitsagenten und den Steuerungen, die seine Fehler forderten.

Das historische System hat zwei Orchestrierungspfade. Auf dem servergesteuerten Pfad führt ein Orchestrator seine eigene Phasenliste und bietet dem Modell nur die Werkzeuge an, die diese Phase erlaubt. Auf dem agentengesteuerten Pfad plant ein orchestrierendes Modell den Lauf und ruft die Werkzeuge selbst auf, wobei die darunterliegenden Schichten konstruiert, aber nicht immer konsultiert werden. Ein gemeinsamer Schreibpfad macht aufgezeichnete Aktionen und Befunde überprüfbar, aber eine verfügbare Shell kann ihn umgehen. Ein erfundener Endpunkt verdient eine erfasste Antwort, kein automatisches Schwachstellenurteil. Der Schweregrad-Governor kann nicht anheben; das historische Anhebungs-Gate des separaten Verifizierers prüft ein Zitat, etabliert aber keine Ausnutzbarkeit. Autorisierung wird an der Werkzeuggrenze angefragt, nicht bei jeder ausgehenden Anfrage. Die Berichtskapitel unterscheiden einen Scan, der nichts fand, von einem Scan, der an der Tür verweigert wurde. Diese Unterschiede zwischen Absicht und Durchsetzung sind Teil der Fallstudie, keine Eigenschaften, die in ein neues Harness zu kopieren sind.

Jedes Kapitel nach dem ersten endet damit, zuzugeben, was seine Steuerung immer noch falsch macht, und die Ehrlichkeitsabschnitte tragen die Messungen, die es zeigen. Lesen Sie die Ehrlichkeitsabschnitte zuerst, wenn Sie entscheiden, ob Sie dem Rest vertrauen: Der Korpus ist die Betriebsgeschichte eines Systems, der eine ausgewählte öffentliche Ziellauf ist eine vom Autor aufgezeichnete Aggregation mit zwei ausgeschlossenen Läufen, die daneben veröffentlicht sind, und die Ablationsstudie, die zeigen würde, wie viel die deterministischen Schichten tatsächlich beitragen, wurde nicht ausgeführt. Das Repository enthält nicht die Rohbefunde, die Grundwahrheit oder den Matcher des ausgewählten Laufs, sodass die aufgezeichnete Präzision hier nicht unabhängig reproduzierbar ist. Das Designargument wird argumentiert, nicht gemessen, und Kapitel 05 sagt das in diesen Worten.

Die fünf Gesetze

Kanonisch in Kapitel 00, hier kopiert. Jedes ist Designabsicht, und das Kapitel, das am Ende eines Gesetzes genannt wird, ist, wo dieses System dagegen gehalten wird: welche Teile durch Konstruktion gelten, welche nur auf einem der beiden Orchestrierungspfade gelten, welche vom guten Verhalten des Orchestrators abhängen und welche noch nicht gelten.

  1. Das Modell schlägt vor; deterministischer Code verfügt. Geben Sie dem Modell eine Vorschlagsschnittstelle, keinen direkten Zugriff auf das Ziel, rohen Speicher oder das letzte Wort über den Schweregrad. Deterministischer Code validiert, führt aus und zeichnet zugelassene Arbeit auf. Das historische System erzwingt diese Grenze nicht überall: Beide Orchestratoren können eine Shell erreichen, und sein Schreibpfad trägt einen Unterbefehl, der einen Befund ohne Ausführung speichert. Ein erfundener Endpunkt könnte 404, eine Anmeldeseite oder eine Anwendungsshell zurückgeben; zeichnen Sie die Antwort auf und beurteilen Sie die Behauptung separat. Ein gemeinsamer Schreiber ist keine Sandbox. Kapitel 01 und 02.

  2. Behauptungen über die Vergangenheit müssen zitieren. Vorschläge über die Zukunft müssen ausführen. Dies sind verschiedene Arten von Aussagen und sie benötigen verschiedene Gates. Eine Behauptung über etwas bereits Beobachtetes muss ihre eigene Erfassung zitieren; ein passendes Zitat etabliert Zitatintegrität, nicht dass die Schlussfolgerung wahr ist. Das historische Gate leckt: Es behält ein Element pro Stapel, selbst wenn keines besteht, und auf einem Orchestrierungspfad kann eine vom Aufrufer gelieferte Konfidenz für die Prüfung einspringen. Ein vorgeschlagener Test kann nicht validiert werden, indem eine Beobachtung zitiert wird, die er nicht gemacht hat. Er darf nur nach Autorisierungs-, Umfangs-, Gate- und Budgetprüfungen ausgeführt werden, und sein Ergebnis benötigt immer noch Interpretation. Das Gesetz ist keine Erlaubnis, jeden Vorschlag auszuführen. Kapitel 02.

  3. Schweregrad fällt standardmäßig und steigt nur gegen Beweis. Der deterministische Governor kann einen Schweregrad senken oder einen Befund als falsch-positiv markieren und kann keinen anheben. Das begrenzt seine Autorität; es macht seine Schlussfolgerungen nicht korrekt. Unterberichterstattung kann eine echte Schwachstelle verbergen, daher benötigt jede Senkungsregel passende und Gegenbeispieltests sowie einen überprüfbaren Grund. Der historische Anhebungsendpunkt prüft ein wörtliches Zitat, erzwingt aber nicht den verfassten Score, den sein Vertrag anfordert. Ein Zitat allein ist kein Ausnutzbarkeitsbeweis. Binden Sie die Erfassung an den Befund, wenden Sie eine überprüfte Domänenbeweisrichtlinie an und behalten Sie einen separaten menschlichen Überprüfungs- und Unterzeichnungsprozess bei. Kapitel 03.

  4. Umfang ist eine Funktion, kein Satz. Autorisierung, die in einen Prompt geschrieben ist, konkurriert mit jeder anderen Anweisung im Kontextfenster. Kodieren Sie die Erlaubnis des Betreibers als überprüfbare Richtlinie und erzwingen Sie sie vor jeder ausgehenden Aktion, mit einer Aufzeichnung von Verweigerungen. Die historische Wache bleibt zurück: Sie wird an der Werkzeuggrenze angefragt, nicht bei jeder Anfrage, erweitert einige Hostgrenzen und schlägt unter einem Kill-Switch oder wenn ohne Ziel konstruiert offen fehl. Das Labor lehnt nicht gelistete Ursprünge vor seinem vertrauenswürdigen Callback ab, aber Transporteindämmung gehört immer noch in den Adapter. Eine Richtlinienentscheidung ist nur so korrekt wie die Autorisierung und das Ziel, das sie bewertet. Kapitel 04.

  5. Berichten Sie, was Sie nicht getan haben. Ein Scan, der nichts fand, und ein Scan, der nichts erreichen konnte, sind verschiedene Scans, und ein Bericht, der sie identisch darstellt, lügt durch Auslassung. Abdeckung, Gate-Status und ein Hauptbuch jedes übersprungenen Hosts mit seinem Grund gehören in das Ergebnis, neben den Befunden. Das ist eine Anforderung, die der historische Bericht nicht erfüllte: Nur Abdeckung kam an, berechnet gegen seinen schwächsten Nenner und unter einem Label, das einen anderen nennt. Das Labor rechnet für geplante Werkzeug-und-URL-Aktionen, ausgeführte Arbeit, Fehler und Überspringungen ab; dieser Nenner misst keine Schwachstellenabdeckung. Kapitel 05.

Die Kapitel

KapitelThema
Kapitel 00: Der Determinsmus-Gradient (Quelle)Warum Varianz ein Designproblem und kein Fähigkeitsproblem ist, die vier Schichten und die fünf Gesetze
Kapitel 01: Die feste Prozedur (Quelle)Die Phasenmaschine, deterministische Werkzeugbewertung, Priors als Zähler in einer Datei und das Zugverhältnis, das nicht sagt, was Sie wollen würden
Kapitel 02: Die schmale Taille (Quelle)Ein Schreiber pro Nebenwirkung, Schema-Validierung und die Reparaturschleife, und warum Behauptungen und Vorschläge verschiedene Gates benötigen
Kapitel 03: Asymmetrisches Vertrauen (Quelle)Ein Governor, der nicht eskalieren kann, ein Verifizierer, der nur gegen Beweis anheben kann, und die Angriffsketten, die nicht bewiesen werden können
Kapitel 04: Umfang als Code (Quelle)Autorisierung als Funktion, das Überspringungs-Hauptbuch, der Boden, den keine Funktion entscheiden sollte, und die im ausgewählten Lauf aufgezeichnete Umfangslücke
Kapitel 05: Was der Scan nicht erreichen konnte (Quelle)Erreichbarkeit als aufgezeichneter Wert, Abdeckungsnenner, Konsolidierung, ehrliche Teilberichte und wie Sie Ihr eigenes System bewerten

Die Referenzimplementierung

Der historische Code unter core/ ist hier, um gelesen, ausgeführt und widersprochen zu werden. Er ist Clean-Room und bewusst nicht funktional als Live-Tester: Die Profilerstellung, die Relevanzbewertung, die Planung und die Werkzeugaufruf-Validierung sind real und ausführbar, und alles, was ein Paket auf die Leitung legen würde, ist zurückgehalten. Führen Sie ls core/*.py aus, um zu sehen, was mitgeliefert wird, anstatt einer hier geschriebenen Zahl zu vertrauen, was die Art von Behauptung ist, die in dem Moment veraltet, in dem ein Modul hinzugefügt wird. Die Steuerungen, auf die sich die späteren Kapitel stützen, sind darunter: Der Schreibpfad ist core/store_protocol.py, der Schweregrad-Governor core/severity_governor.py, die Umfangswache core/scope_guard.py, die Gate-Prüfung core/gate_check.py und die Phasenmaschine walkthrough/run.py. Der historische modellaufrufende Verifizierer ist zurückgehalten. Kapitel 06 spezifiziert ihn; Kapitel 07 liefert eine separate deterministische Evidenzwache, nicht diesen Verifizierer und keinen menschlichen Akzeptanzworkflow. Halten Sie ihre Aufgaben getrennt: Der Grounding-Kritiker prüft Zitateindämmung, der Governor begrenzt den Schweregrad, und ein Anhebungspfad muss eine unabhängig überprüfte Beweisrichtlinie erfüllen. Keiner von ihnen ersetzt menschliche Überprüfung und Unterzeichnung.

walkthrough/ treibt diese Phasenmaschine über festgeschriebene Fixtures und schreibt die Artefakte, auf die sich die Kapitel beziehen, in walkthrough/artifacts/. Regenerieren Sie sie mit python3 -m walkthrough.run, das ein --out-Verzeichnis akzeptiert, wenn Sie die festgeschriebenen Kopien nicht anfassen möchten, und tests/test_walkthrough_is_in_sync.py vergleicht einen frischen In-Memory-Lauf Byte für Byte mit diesen Kopien, sodass ein ohne Neulauf bearbeitetes Fixture rot wird, anstatt ausgeliefert zu werden. Was dieses Gate nicht erfasst, ist ein Artefakt, das an beiden Stellen falsch ist, und sein eigenes Docstring sagt das.

Die Zahlen

Jede Zahl in jedem Kapitel löst sich in einen Schlüssel in data/stats.json auf oder trägt eine Anmerkung, die benennt, was die Zahl ist und warum sie keine von einem Ziel genommene Messung ist. Über Kapitel 00 bis 05 und diese README hinweg benennen dreizehn Anmerkungen eine Konstante oder eine Eigenschaft des Codes, fünfunddreißig decken eine ausgeschriebene Menge ab, die die Ziffernprüfung nicht lesen kann, fünf benennen einen HTTP-Statuscode und eine benennt einen Vergleich zwischen zwei eigenen veröffentlichten Snapshots dieses Repositorys. Die Statistikdatei ist ein eingefrorener Snapshot mit einem veröffentlichten Fenster, keine Live-Abfrage, und Kapitel 05 erklärt, warum ein erneutes Ausführen der Pipeline sie nicht reproduzieren würde.

Kapitel 05 berichtet das F1 des Systems gegen eine öffentliche absichtlich verwundbare Anwendung und stellt es neben einen OWASP-ZAP-Passiv-Scan-Score. Dieses Repository beweist die Arithmetik und hält die vier aggregierten Score-Dateien mit data/stats.json synchron; es enthält nicht die Rohbefunde, Grundwahrheitseinträge, den Matcher, Zielkennungen oder Laufkennungen, die benötigt werden, um zu beweisen, dass die beiden Werkzeuge in einem kontrollierten Kopf-an-Kopf bewertet wurden. Behandeln Sie das Paar als historische, vom Autor aufgezeichnete Datenpunkte, nicht als fairen Benchmark. Die Stichprobengröße, die Streuung, die es daher nicht berichtet, und die davon ausgeschlossenen Läufe mit dem Grund für jeden Ausschluss sind alle in diesem Kapitel.

Eine generierte Kopie der Kapitel, mit jeder Zahl, die an Ort und Stelle zu ihrem Wert aufgelöst ist, und jedem Codezitat, das in einen Link in core/ verwandelt ist, lebt in dem gerenderten Baum zum Lesen auf GitHub; sie wird von scripts/render.py erzeugt und durch tests/test_rendered_is_in_sync.py mit der Quelle in Schritt gehalten.

Wenn Sie das Repository veröffentlichen, folgen Sie PUBLICATION.md. Veröffentlichen Sie einen verlustfreien Snapshot in ein neues öffentliches Repository; ändern Sie nicht die Sichtbarkeit des Entwicklungsrepositorys und nehmen Sie an, dass ein sauberer Arbeitsbaum seine erreichbare Git-Historie gelöscht hat. Das obligatorische Pre-Commit scripts/publication_gate.sh verweigert die Veröffentlichung, es sei denn, die private Denylist wurde tatsächlich zusammengeführt, die öffentliche Git-Autorenidentität dem genehmigten Wert entspricht und das Staging-Repository keine früheren Refs, Objekte oder Reflogs hat.

scripts/audit.sh durchsucht das Repository nach Kennungen, scripts/prose_check.sh und scripts/verify_claims.sh durchsuchen die Prosa, tests/test_gates.sh pflanzt Verstöße gegen sie, um zu beweisen, dass sie immer noch auslösen, und die Testsuite hält die Referenzimplementierung gegen das, was die Kapitel darüber sagen. Ein Kapitel ist nicht fertig, bis jeder dieser Schritte besteht:

root@kitploit:~
python3 -m pip install -r requirements.txt
                                      # pytest, und sonst nichts: jedes Modul unter
                                      #   core/ ist nur Standardbibliothek
export HANDBOOK_ROOT=.
bash scripts/audit.sh .               # immer die veröffentlichten Muster; die Arbeitgeber-, Kunden-
                                      #   und Host-Denylist nur wo sie existiert, und diese
                                      #   Datei ist privat, also trägt kein Klon sie. Welche
                                      #   Hälfte lief, steht in der "sanitization scope:"-Zeile,
                                      #   die dies druckt, und nicht im Exit-Status, also lesen
                                      #   Sie die Zeile
./scripts/prose_check.sh handbook     # mechanische KI-Anzeichen
./scripts/verify_claims.sh handbook   # Zitate, nicht zitierte Zahlen, Querverweise,
                                      #   Behauptungsanker, Quellenattribution
./scripts/prose_check.sh README.md    # beide Gates nehmen ein Ziel und standardmäßig handbook/,
./scripts/verify_claims.sh README.md  #   also muss diese Datei benannt werden, um geprüft zu werden
./tests/test_gates.sh                 # die Gates gegen gepflanzte Verstöße, den
                                      #   Baum, die README und die Kapitelbehauptungen;
                                      #   die eigene Prosa der Kapitel wird von den
                                      #   Prosa- und Behauptungsgates abgedeckt, die auf handbook
                                      #   oben zielen, und nicht von diesem Sweep
python3 -m pytest tests/              # die gesamte Suite, und sie druckt ihre eigene Zählung,
                                      #   anstatt dass eine hier geschrieben ist. Jede Zeile
                                      #   oben führt die Gate-Skripte und die pytest-Dateien aus,
                                      #   die diese verdrahten, die die über dieses Dokument sind;
                                      #   die Tests der Steuerungen, um die es bei den fünf Gesetzen
                                      #   geht -- den Schweregrad-Governor, die Umfangswache, die
                                      #   Gate-Prüfung, den gemeinsamen Schreibpfad, den
                                      #   Grounding-Kritiker -- werden von dieser Zeile erreicht und
                                      #   von nichts oben. Ein Bruch in einem von ihnen
                                      #   macht die Zeilen oben nur rot, wo er auch die
                                      #   festgeschriebenen walkthrough-Artefakte bewegt

tests/test_chapter_claims.py, innerhalb dieser Suite, ist das eine, das es wert ist, gestohlen zu werden. Es hält Assertions gegen die Referenzimplementierung und die veröffentlichten Statistiken, und jede ist am wörtlichen Satz verankert, den sie stützt, sodass eine Bearbeitung, die eine Tatsache ändert, einen Test fehlschlagen lässt, anstatt still auszuliefern.


Theodoros Moutesidis.

Tool herunterladen
Kapitel 06: Bauen Sie Ihr eigenes (Quelle)Das geordnete Handbuch: Jeder Schritt nennt die Invariante, die er schützt, und benennt die erzwingende Datei, einen Test und das festgeschriebene Artefakt, wo immer der öffentliche Baum sie trägt
Kapitel 07: Das Harness-Labor (Quelle)Die empfohlene Offline-Referenz: Erzwingen Sie die Grenze, prüfen Sie einen vollständigen Bericht und testen Sie, was verweigert werden muss
Anhang A: Der Orchestrator-Vertrag (Quelle)Das Instrument, das dem Modell übergeben wird, aus dem privaten Original generisiert
Anhang B: Die Schemas (Quelle)Werkzeugaufruf-, Befund- und Governance-Aufzeichnungsformen, mit dem, was jede garantiert und was nicht
Anhang C: Das Fehlermuseum (Quelle)Echte falsch-positive Ergebnisse mit ihrer Grundursache und der Regel, die jede tötet, und welche davon dieses Repository festnageln kann