Eine KI-Pipeline in der Sandbox betreiben, die Sicherheitslücken findet und behebt

## Reine Lesearbeit an Analyse-Skills geben, Codeausführung an die Sandbox Ein System dieser Art hat zwei klar getrennte Ebenen; leite Anfragen an die jeweils passende weiter. - Interaktive Analyse-Skills lesen und schreiben Dateien im Repository und laufen in der aktuellen Sitzung. Sie führen den Zielcode niemals aus. Nutze sie für Scoping, Bedrohungsmodellierung, statische Schwachstellenprüfung, die Sichtung eines bestehenden Fundhaufens, das Entwerfen von Patch-Kandidaten und das Portieren der Pipeline auf einen anderen Technologie-Stack. Leite hierhin für Fragen und jede rein lesende Arbeit. - Die autonome Pipeline führt das Ziel tatsächlich aus, um Abstürze zu finden und zu verifizieren. Da sie nicht vertrauenswürdigen, vom Angreifer beeinflussten Code ausführt, muss sie innerhalb einer Sandbox gegen einen instrumentierten Build laufen. Leite hierhin nur, wenn echte, ausführungsverifizierte Funde gewünscht sind statt einer rein statischen Einschätzung. Halte die beiden strikt auseinander: Die Lese-/Schreibebene denkt über Code nach, die Ausführungsebene führt ihn aus. Die eine informiert, die andere beweist. Die Ausgabe der Ausführungsseite ist eine reproduzierende Eingabedatei, kein Fließtext. ## Mit einem kleinen Testlauf beginnen und den vollen Lauf im Hintergrund starten Betreibe die Pipeline wie ein Live-Dashboard, nicht wie einen Stapelverarbeitungslauf zum Vergessen. - Führe die Nutzerin oder den Nutzer zunächst interaktiv durch die Aufklärungsphase: zeige die entdeckten Schwerpunktbereiche und lass die Aufteilung anpassen, bevor irgendetwas startet. - Starte bei einem ersten Lauf gegen ein neues Ziel eine kleine Welle (wenige parallele Läufe, eine niedrige Zuggrenze), damit ein Gefühl für den Tokenverbrauch und die Prompt-Kalibrierung entsteht, bevor hochskaliert wird. Sieh dir bei Auffälligkeiten gemeinsam ein Transkript an. - Starte den größeren Lauf danach im Hintergrund, sodass Logs mitverfolgt, Funde beim Eintreffen beobachtet und Fragen beantwortet werden können, ohne zu blockieren. Sobald ein Fund verifiziert ist, zeige ihn mit einer kurzen Zusammenfassung, statt auf den ganzen Stapel zu warten. Der erste verifizierte Fund liegt typischerweise nach Minuten vor, nicht nach Stunden; ein langsamer Nachzügler verlangsamt nur sich selbst, nicht den gesamten Stapel. ## Jedes Transkript sofort auf die Festplatte schreiben, damit ein Abbruch nichts kostet Statte jeden Lauf mit zwei dauerhaft aktiven Beobachtungsebenen aus. - Ein Herzschlag, der alle paar Züge ausgegeben wird, belegt während langer stiller Phasen, dass der Prozess noch lebt. - Eine Fortschrittszeile pro Aktion zeigt, was jeder Agent gerade tut, eine Zeile pro Werkzeugaufruf oder Textblock. Streame jedes Agenten-Transkript auf die Festplatte, sobald Nachrichten eintreffen, dauerhaft geschrieben. Nichts Wichtiges liegt nur im Arbeitsspeicher, sodass ein Abbruch mitten im Lauf trotzdem vollständige, lesbare Transkripte zur nachträglichen Prüfung hinterlässt. Wenn nach dem Status gefragt wird, antworte anhand der Artefakte auf der Festplatte: zähle die noch offenen Funde, die bereits bewerteten und die geschriebenen Berichte, und zeige dann den neuesten. Jedes Ergebnis wird in dem Moment geschrieben, in dem sein eigener Lauf endet, sodass Nachzügler die anderen nie am Eintreffen hindern. ## Agenten nach Ratenbegrenzungen fortsetzen, statt den Lauf zu verlieren Vorübergehende Kapazitätsfehler dürfen einen Lauf nicht abbrechen; baue die Wiederherstellungsleiter so, dass lange Aufträge Lastspitzen durchstehen. - Jeder Agent ist eine einzige, lang laufende Sitzung. Ein Ratenlimit- oder Serverfehler mitten im Lauf wird zunächst im eigenen Client des Agenten erneut versucht. - Gibt dieser auf, fährt der Orchestrator zurück (exponentiell, mit einer Obergrenze) und startet den Agenten aus seiner Sitzung heraus neu, sodass der vollständige Gesprächskontext wiederhergestellt wird und genau bei dem Zug weitergemacht wird, bei dem es scheiterte. - Begrenze die Anzahl der Neustarts pro Agent, damit ein wirklich feststeckender Agent irgendwann stoppt. Sage der Nutzerin oder dem Nutzer, dass nahe an der vorgesehenen Kapazität gearbeitet werden kann und die Rückfahrlogik Lastspitzen abfängt; eine Selbstdrosselung zur Vermeidung von Datenverlust ist nicht nötig. Eine Ausnahme: Ein Fehler wegen aufgebrauchter Züge ist endgültig und wird bewusst nicht neu gestartet, weil ein Neustart die Zuggrenze vervielfachen würde — stattdessen die Grenze anheben und neu starten. Jeder Fund, den der Agent vor Erreichen eines Limits bereits eingereicht hat, wird trotzdem gerettet und bewertet, statt mit dem Lauf verworfen zu werden. ## Berichte für neue Fehler automatisch erstellen und vor Netzwerkzugriffen fragen Im Streaming-Betrieb erfolgt die Berichterstellung automatisch. Sobald ein Absturz die Bewertung besteht, entscheidet ein Richter-Agent, ob es sich um einen neuen Fehler, eine sauberere Ausprägung eines bekannten Fehlers oder ein zu überspringendes Duplikat handelt; ein neuer Fehler löst sofort einen Bericht-Agenten aus, ohne auf den Stapel zu warten. Ein eigenständiger Stapelbericht-Pfad bleibt für die Wiederherstellung verfügbar, ebenso für Ergebnisse, die ohne Streaming entstanden sind. Jeder Bericht ist eine strukturierte Ausnutzbarkeitsanalyse — wie sich die Primitive verhält, ob sie von der realen Angriffsfläche aus erreichbar ist, der Eskalationspfad und die Einschränkungen — plus ein vom Agenten eingeschätzter Schweregrad. Ein separater Bewertungs-Agent bewertet den Bericht anhand einer semantischen Rubrik, nicht anhand eines Schlagwort-Scans. Bevor ein Schritt aktiviert wird, der auf ein externes Netzwerk zugreift — etwa eine Neuheitsprüfung, die das Upstream-Repository des Ziels klont, um festzustellen, ob ein Fehler bereits behoben ist —, frage vorher nach. Lass diese Option standardmäßig deaktiviert: In abgeschotteten oder im Datenverkehr eingeschränkten Umgebungen soll die Pipeline nicht nach außen greifen. Nur der Orchestrator-Host greift überhaupt auf das Netzwerk zu; die Agenten-Container bleiben in jedem Fall auf den Modell-Endpunkt beschränkt. ## Prüfen, ob der Absturz weg ist, und die Übernahme des Patches Menschen überlassen Die Patch-Phase kann nach der Berichterstellung oder eigenständig laufen. Für jeden eindeutigen Absturz schreibt ein Patch-Agent in einem frischen, isolierten Container einen Fix und gibt einen Diff aus; ein separater Bewertungs-Container durchläuft eine Verifizierungsleiter. - Den Diff anwenden und neu bauen. - Bestätigen, dass die ursprüngliche reproduzierende Eingabe nicht mehr abstürzt. - Bestätigen, dass die eigene Testsuite des Ziels weiterhin besteht. - Die gepatchte Binärdatei mit einem frischen, zeitlich begrenzten Find-Agenten erneut angreifen. Scheitert eine Stufe, wird der Befund zurückgespielt, und der Patch-Agent iteriert eine begrenzte Anzahl von Malen; als letzte Stufe kann optional eine beratende Überprüfung ergänzt werden. Sei gegenüber der Nutzerin oder dem Nutzer klar darüber, was das beweist. Die Leiter verifiziert, dass der Absturz verschwunden ist; sie verifiziert nicht, dass der Diff sicher hochgestuft werden kann. Lege den Diff zur menschlichen Prüfung vor und verweise auf die Prüfungsrichtlinie. Biete nicht an, den Diff außerhalb der eigenen Container der Pipeline anzuwenden — erzeugte Fixes sind Vorschläge zur Annahme durch einen Menschen, keine automatisch einzuspielenden Änderungen. ## Agenten doppelte Abstürze nach der Ursache beurteilen lassen, nicht nach dem Text Dedupliziere Abstürze durch Agentenurteil auf zwei Ebenen, nicht durch Textabgleich. - Bei der Einreichung muss ein Find-Agent seine eigene Begründung beifügen, warum sich ein Absturz von dem unterscheidet, was bereits in der gemeinsamen Fundedatei erfasst ist. Die Pipeline weist jede Einreichung ohne diese Begründung zurück. Der Agent trifft die Entscheidung, weil er die Grundursache kennt; die Pipeline erzwingt nur, dass die Beurteilung stattgefunden hat. Vergleiche semantisch gegen rohe Sanitizer-Auszüge, nicht per exaktem Textabgleich. - Am Berichtstor liest ein Richter-Agent jeden bewerteten Absturz gegen das laufende Berichtsverzeichnis und entscheidet: neu, sauberes Duplikat oder überspringen. Dieselbe Grundursache, die an anderen Zeilen oder in anderen Frames auftaucht, wird weiterhin dedupliziert; ein sauberes Duplikat löst eine erneute Berichterstellung aus, und ein Vergleichsschritt wählt anschließend das kanonische Exemplar. Beim Erfassen eines bekannten Fehlers als Schlüssel den Funktionsnamen verwenden, nicht die Zeilennummer: Derselbe Fehler stürzt je nach Eingabe an benachbarten Zeilen oder mit unterschiedlichen Sanitizer-Typen ab. ## Finden und Bewerten in getrennten, abgeschotteten Containern ausführen Das Isolationsmodell macht ausführungsverifizierte Ergebnisse erst vertrauenswürdig; behandle es als nicht verhandelbar. - Find- und Bewertungslauf laufen in getrennten Containern, die aus demselben Image gebaut sind. Nur die Proof-of-Concept-Bytes wandern zwischen ihnen. Die Find-Seite berührt die Bewertungsseite nie, was Reward-Hacking durch vorab platzierten Zustand verhindert. - Jeder Agent läuft in seinem eigenen Container mit gehärteter Laufzeitumgebung und einem auf eine konfigurierte Positivliste begrenzten Datenverkehr nach außen — in der Sandbox, nicht auf dem Host. Seine Datei- und Shell-Werkzeuge sind auf diesen Container beschränkt. - Befehle, die Agenten starten, verweigern den Start außerhalb der Sandbox, sofern nicht ausdrücklich eine gefährliche Override-Option übergeben wird. - Der Werkzeugsatz der Agenten ist fest und minimal: ausführende Agenten erhalten nur Lesen, Schreiben und Shell; Richter- und Vergleichs-Agenten erhalten überhaupt keine Werkzeuge und erledigen alles in einem einzigen prompt-basierten Aufruf. Keine Plugin-Werkzeuge, kein Web-Zugriff. ## Einstellungen meiden, die den Start verhindern, und Ziele ohne Codeänderung ergänzen Ein paar Betriebsdetails brechen leicht und sollten vorab genannt werden. - Manche Umgebungseinstellungen sind tragend: Eine deaktiviert die Schutzsperre für verschachtelte Sitzungen des containerinternen Werkzeugs, eine andere erlaubt ihm, innerhalb der Sandbox einen Berechtigungs-Umgehungsmodus zu akzeptieren. Entfernt man eine der beiden, bricht der Agentenstart. - Unterscheide „den verfügbaren Werkzeugsatz einschränken" von „Berechtigungs-Positivliste" — eine CLI kann beide Flags akzeptieren, aber sie bedeuten Verschiedenes; verwende diejenige, die tatsächlich einschränkt, welche Werkzeuge existieren, nicht nur, welche erlaubt sind. - Die Modellwahl ist ein Laufzeitargument, keine statische Konfiguration, sodass dieselbe Zieldefinition mit jedem beliebigen Modell betrieben werden kann. - Ein mit Sanitizer instrumentierter Parser braucht unter Umständen ein No-Inline-Attribut, damit Compiler-Inlining die Absturzsignatur nicht verändert. Ein Ziel hinzuzufügen bedeutet ein fertiges Verzeichnis mit Build-Definition und Sanitizer-Konfiguration; keine Änderungen am Pipeline-Code. Decke die beweglichen Teile mit Unit-Tests ab — Tag- und Ausgabeparsing, Artefakt-Serialisierung, Signaturextraktion, Deduplizierung und die Patch-Bewertungsleiter — und behalte ein schnelles Test-Zielobjekt als End-to-End-Rauchtest. ## Spuren eines Angreifers in Logs suchen, ohne dass der Suchende die Lösungen sieht Ein Geschwisterprozess für die Zeit nach einer Kompromittierung dreht das Problem um: Der Angreifer steckt bereits in den Protokollen, und die Aufgabe besteht darin, seine Kampagne zu finden, statt eine Binärdatei zum Absturz zu bringen. - Der Protokollbestand muss erzeugt werden, bevor irgendetwas läuft. Er ist groß und pro Seed deterministisch, sodass derselbe Seed auf derselben Maschine dieselben Belege reproduziert. - Ein Jagd-Agent erhält den Anwendungsquellcode und schreibgeschützte Protokolle und reicht seine Vorfallfunde ein. Konstruktionsbedingt existiert innerhalb seines Containers kein Lösungsschlüssel. - Ein Bewertungs-Agent in einem frischen Container bewertet die Einreichung und feuert jeden bestätigten Proof of Concept unabhängig erneut ab. Nur die Einreichung überquert die Grenze. Schütze die Integrität der Auswertung: Ground-Truth-Dateien, der Bewerter und der Quellcode des Protokollgenerators sind Spoiler. Sie dürfen auf der Jagdseite niemals eingebunden oder gelesen werden. Dieselbe Abfolge aus interaktiv und dann autonom wie bei der Absturzpipeline gilt auch hier.