Woran ich baue: ein offener Cybersecurity-Agent

Ich baue einen Cybersecurity-Agenten: ein Modell, das für Security-Arbeit trainiert ist, und das Harness, in dem es läuft. Beides erscheint als Open Source unter Prisma, meiner kleinen Open-Source-Organisation.

Ich schreibe das, bevor es fertig ist — die unbequeme Reihenfolge. Aber ein vorab veröffentlichter Plan ist überprüfbar, ein nachträglich veröffentlichter Plan ist eine Pressemitteilung.

Warum dieses Problem

Security ist eine der wenigen Domänen, in denen die Kernschwäche eines Agenten überlebbar ist — vorausgesetzt, das Harness ist richtig gebaut.

Die Schwäche: Modelle produzieren selbstsichere Ausgaben, die manchmal falsch sind. In den meisten Anwendungen ist das ein stiller Fehler — man bekommt eine plausible Antwort und kein Signal, dass sie schlecht ist. Beim Security-Testing sind viele Behauptungen billig zu prüfen. Entweder die Anfrage hat den Endpoint erreicht oder nicht. Entweder der Parser hat die fehlerhafte Eingabe akzeptiert oder abgelehnt. Entweder der Port ist offen oder zu. Die Grundwahrheit steht direkt in der Antwort.

Das ändert den Entwurf. Das Modell muss nicht recht haben. Es muss oft genug recht haben, damit sich die Rechenzeit lohnt, und das Harness muss jede Behauptung verifizieren, bevor sie als Finding zählt. Ein Security-Agent, der meldet, was er demonstrieren kann, ist nützlich. Einer, der meldet, was er glaubt, ist ein Haftungsgenerator.

Was ich gelernt habe, als ich zuerst die falsche Version baute

Das erste ernsthafte Agentensystem, das ich gebaut habe, sollte unbeaufsichtigt laufen. Es plante, handelte, machte weiter. In einer Demo war es wirklich beeindruckend.

Im echten Einsatz produzierte es eine bestimmte Sorte Müll. Es las ein Zwischenergebnis falsch, trug diese Fehllesung als gesicherte Tatsache weiter und arbeitete noch zehn Schritte lang mit voller Überzeugung damit. Die Ausgabe kam vollständig und sauber strukturiert an und stand auf etwas, das nie wahr war. Nichts warf einen Fehler. Genau das war das Problem — eine Exception hätte mir etwas gesagt.

Ich habe die Orchestrierungsschicht gelöscht und um eine andere Regel neu gebaut: Die Ausgabe eines Schritts gilt erst als Tatsache, wenn etwas außerhalb des Modells sie bestätigt. Das Ergebnis war weniger autonom und drastisch nützlicher. Jede Überzeugung, die ich zu Agenten habe, stammt aus diesem Umbau, nicht aus Meinungen im Netz.

(Hinweis: Dieser Abschnitt ist ein Entwurf aus unserem Gespräch — prüfe vor Veröffentlichung, ob er zu dem passt, was tatsächlich passiert ist.)

Der Entwurf

Belege statt Meinung. Jedes Finding trägt eine Reproduktion: die exakte Anfrage, die exakte Antwort, die Bedingungen. Was das Harness nicht reproduzieren kann, wird nicht gemeldet. Das erledigt die Flut an False Positives, wegen der man die meisten automatisierten Security-Werkzeuge ignorieren kann.

Ein Scope, der erzwungen wird, nicht erbeten. Ziele werden vorab deklariert, und das Harness verweigert alles außerhalb davon auf Netzwerkebene. Scope in einem Prompt ist ein Vorschlag. Scope in der Laufzeit ist eine Grenze.

Kleine Modelle, lokal betrieben. Ich habe lange an lokaler Inferenz mit llama.cpp und eigener Modell- und Provider-Konfiguration gearbeitet. Security-Arbeit berührt Daten, die die Maschine nicht verlassen sollten, und ein Agent, der für jeden Schritt einen API-Aufruf zu Dritten braucht, ist genau dort unbrauchbar, wo er am nötigsten wäre.

Vollständiger Audit-Trail. Jede Aktion protokolliert, jede Entscheidung zuordenbar, der ganze Lauf im Nachhinein rekonstruierbar. Das ist kein Compliance-Häkchen. So debuggt man einen Agenten, und nur so kann jemand einem Report vertrauen, den er nicht selbst erzeugt hat.

Der naheliegende Einwand

Ein offenes Modell, das gut darin ist, Schwachstellen zu finden, hilft auch dabei, sie auszunutzen. Ich habe keine saubere Antwort darauf, und wer behauptet, die Frage sei einfach, meint es nicht ernst.

Meine Position: Die Werkzeuge, die das ersetzt, existieren bereits und sind bereits öffentlich. Die Asymmetrie in der Security ist nicht der Zugang zu Werkzeugen, sondern Aufmerksamkeit — Verteidiger müssen alles abdecken, Angreifer brauchen eine Sache. Billiges, gründliches, automatisiertes Testen der eigenen Systeme verschiebt diese Asymmetrie zum Verteidiger, und am stärksten für die, die heute gar keine Security-Prüfung bekommen, weil sie sich keine leisten können. Die Fähigkeit geschlossen zu halten, entfernt sie nicht. Es konzentriert sie bei denen, die zahlen können.

Deshalb veröffentliche ich sie mit einem Harness, das den Scope erzwingt — und ich streite darüber weiter öffentlich.

Zur Regulierung

Was mich am meisten frustriert, ist nicht die Technologie. Es ist, wie lange es dauert, in Europa irgendetwas damit tun zu dürfen.

Ich argumentiere nicht gegen Regeln für KI. Gerade Security-Werkzeuge sollten Regeln haben. Aber es gibt einen Unterschied zwischen Regeln und Verfahren, und wovon wir viel haben, sind Verfahren: Genehmigungen, die länger dauern als der Entwicklungszyklus, den sie regeln; Anforderungen, geschrieben für eine Technologie von zwei Generationen zuvor; und eine Compliance-Fläche, die nur überquert, wer eine Rechtsabteilung hat. Die Absicht ist, die größten Akteure zu begrenzen. Die Wirkung ist, alle anderen herauszufiltern — womit das Feld genau denen bleibt, für die die Regeln geschrieben wurden.

Die Arbeit muss trotzdem gemacht werden, und sie wird irgendwo gemacht. Mir wäre lieber, dieses Irgendwo ist hier, offen, wo Leute den Code lesen können.

Stand

Modell und Harness sind in Arbeit. Beides erscheint als Open Source, wenn die Evidenz-Pipeline durchgängig vertrauenswürdig ist, nicht vorher. Lieber spät als ein Security-Werkzeug, das selbstsicher Dinge meldet, die es nicht beweisen kann.

Ich schreibe auf, was unterwegs kaputtgeht, auch die Teile, bei denen ich schlecht aussehe. Das sind die nützlichen Texte.