Notizen des Protocol-Security-Teams der Ethereum Foundation über den Einsatz koordinierter KI-Agenten gegen echten Protokoll-Code, einschließlich der Art und Weise, wie wir die Arbeit organisieren, was einer genauen Prüfung standhält und was Client-Teams und Sicherheitsforscher daraus mitnehmen können. Dieser Beitrag steht für sich allein; spätere Beiträge werden tiefer auf einzelne Clients eingehen.
Was wir ausgeführt haben und was uns überrascht hat
Im Protocol-Security-Team der Ethereum Foundation haben wir koordinierte KI-Agenten gegen die Arten von Systemen eingesetzt, von denen das Netzwerk abhängt, wie Systemsoftware, kryptografischer Code und Verträge, die fehlerfrei sein müssen. Die Agenten haben echte Fehler gefunden. Einer ist jetzt öffentlich: eine aus der Ferne auslösbare Panik in gossipsub von libp2p, einem Kernbestandteil der Peer-to-Peer-Schicht, auf der Ethereum-Konsens-Clients laufen. Dieser wurde behoben und als CVE-2026-34219 unter Nennung des Teams offengelegt.
Dass Agenten Fehler finden, war nicht die Überraschung. Die Überraschung war, wie wenig Arbeit in das Finden floss und wie viel Arbeit darin bestand, die echten Fehler von denen zu unterscheiden, die nur echt aussahen.
Dieser Beitrag richtet sich an Client-Teams und Sicherheitsforscher, die dasselbe tun möchten. Er behandelt, wie wir die Agenten organisieren, die Hürde, die ein Kandidat nehmen muss, bevor er als Fund zählt, und die Gewohnheiten, die die Ergebnisse vertrauenswürdig halten.
Andere Teams nähern sich demselben Rezept an. Das Frontier Red Team von Anthropic hat einen Agenten entwickelt, der eigenschaftsbasierte Tests schreibt und echte Fehler im gesamten Python-Ökosystem gefunden hat. Cloudflare ließ ein Frontier-Modell durch eine Sicherheitsforschungs-Testumgebung gegen die eigenen Systeme laufen. Alle landen bei derselben Schleife: Man richtet ein fähiges Modell auf eine Codebasis, lässt es suchen und triagiert, was zurückkommt. Die eigentliche Frage ist also, wie man das macht, ohne in selbstbewusst klingendem Rauschen zu ertrinken.
Ein Vorbehalt vorweg: Die Werkzeuge für agentengesteuerte Audits entwickeln sich schnell weiter, und jedes spezifische Setup ist in wenigen Wochen veraltet. Daher geht es in diesem Beitrag bewusst um die Methoden, die beständig sind, und nicht um die Werkzeuge. Die Offenlegung ist ein eigenes Thema und wird wahrscheinlich einen eigenen Beitrag erhalten.
Ein Agent ist ein Suchwerkzeug, kein Orakel
Ein Agent, der auf eine Codebasis gerichtet ist, ist ein Suchwerkzeug, ähnlich wie ein Fuzzer. Der Unterschied liegt darin, was zurückkommt. Ein Fuzzer liefert einen Absturz und einen Stacktrace. Ein Agent liefert viel mehr, einschließlich eines Berichts (Aufrufkette, Behauptung über die Auswirkungen, vorgeschlagener Schweregrad) und der Artefakte, die dies belegen, wie ein Proof-of-Concept, den man gegen den echten Code ausführen kann.
All das macht das Ergebnis leicht lesbar und vertrauenswürdig, allen voran der lauffähige Proof-of-Concept. Zählen Sie also nicht, wie viele Kandidaten ein Agent produziert. Zählen Sie, wie viele sich als echt herausstellen.
Wie die Arbeit organisiert ist
Wir lassen viele Agenten parallel gegen ein Ziel laufen. Sie koordinieren sich über das Repository selbst, mit einem gemeinsamen Zustand in der Versionskontrolle und ohne einen zentralen Prozess, der die Arbeit verteilt. Ein Agent meldet einen Anspruch dort an, wo die anderen ihn sehen können, erledigt die Arbeit und committet.
Wir haben diesen Ansatz aus Anthropics Bericht über die Entwicklung eines C-Compilers mit einer Flotte von Agenten übernommen, der auf dieselbe Weise koordiniert wird. Es gibt keinen zentralen Koordinator, der aufgebaut oder gewartet werden muss, und es kann weniger schiefgehen.
Die Rollen ergeben sich aus der entdeckten Arbeit:
- Recon (Aufklärung) verwandelt eine Angriffsfläche in konkrete, testbare Hypothesen. Nicht „Überprüfe den Decoder“, sondern „Diesem Feld wird ab diesem Punkt vertraut; hier ist die Eigenschaft, die es beibehalten sollte, die Art und Weise, wie es brechen könnte, und der Beweis, der dies klären würde.“
- Hunting (Jagd) nimmt eine Hypothese, verfolgt den Codepfad und versucht, einen Reproducer zu erstellen.
- Gap-filling (Lückenfüllung) schaut sich an, was akzeptiert und was abgelehnt wurde, schreibt den nächsten Schwung an Hypothesen und verfolgt die Abdeckung, damit die Agenten nicht immer wieder denselben Bereich abgrasen.
- Validation (Validierung) überprüft jeden Kandidaten unabhängig, entfernt Duplikate und trifft eine Entscheidung.
Wir haben diese Pipeline nicht erfunden. Cloudflare beschreibt dieselben Phasen: Aufklärung, parallele Jagd, unabhängige Validierung, Deduplizierung, Berichterstattung, und ihr Bericht hat unseren mitgeprägt.
So sieht ein Kandidat aus, bevor er als Fund zählt:
Ziel: Komponente und Einstiegspunkt, den ein Angreifer tatsächlich erreichen kann Invariante: die Eigenschaft, die gelten muss Mechanismus: die spezifische Art und Weise, wie sie gebrochen werden könnte Erfolg: beobachtbarer Beweis: eine Panik, ein Stillstand, eine akzeptierte ungültige Eingabe Reproducer: ein eigenständiges Artefakt, das gegen den echten Code läuft Dedup: ein Schlüssel, damit nicht zwei Agenten derselben Sache nachjagen
Das Schema gibt es aus einem bestimmten Grund. Es erzwingt eine spezifische, testbare Behauptung und eine klare Definition of Done. Ein Agent, der einen beobachtbaren Beweis aufschreiben muss, kann sich nicht auf „das sieht riskant aus“ zurückziehen.
Reproduzierbar oder es ist nicht passiert
Eine Regel ist wichtiger als alle anderen. Ein Kandidat ist erst dann ein Fund, wenn es ein eigenständiges Artefakt gibt, das den Fehler im echten Code reproduziert und das auch bei jemandem läuft, der es nicht geschrieben hat.
Der Reproducer liest den Bericht nicht, und es ist ihm egal, wie selbstbewusst das Modell klang. Er läuft entweder oder er läuft nicht.
Sein größter Wert liegt in den falsch-positiven Ergebnissen, die er abfängt. Drei davon tauchen immer wieder auf, und bei jedem kommt der Agent aus dem falschen Grund durch:
- Eine Panik, die nur in einem Debug-Build auftritt. Kompiliert man es und führt es so aus, wie die Software tatsächlich ausgeliefert wird, bricht der Wert einfach um. Nichts stürzt ab. Es sieht aus wie ein Absturz, ist aber keiner.
- Ein Reproducer, der einen internen Wert von Hand erstellt, den keine echte Eingabe jemals erzeugen könnte, weil jeder Pfad, den ein Angreifer kontrolliert, ihn schon vorher ablehnt. Der Fehler lässt sich nur bei einer Funktion „reproduzieren“, die von nichts Erreichbarem auf diese Weise aufgerufen wird.
- Bei der formalen Verifizierung ein Beweis, der zwar durchgeht, aber nicht das bedeutet, was man wollte. Die Aussage ist trivialerweise wahr, unabhängig davon, was der Code tut, oder sie ist schwächer als die Eigenschaft, die man erfassen wollte. Der Verifizierer ist zufrieden, aber das Theorem schränkt das Verhalten, um das es eigentlich ging, nicht ein.
Nichts davon ist neu. Es ist dasselbe wie ein Test, der besteht, weil er eigentlich gar nichts prüft. Neu ist die Menge. Ein Agent schreibt die nutzlose Version genauso schnell wie die echte und mit demselben Selbstbewusstsein. Die Überprüfung muss also automatisch erfolgen. Man kann sich nicht darauf verlassen, dass der Agent sich selbst korrigiert.
Das Signal-Rausch-Verhältnis macht die meiste Arbeit aus
Die meisten Kandidaten sind falsch, Duplikate oder liegen außerhalb des Gültigkeitsbereichs. Das ist kein Problem der Methode; so funktioniert sie nun mal. Das Ziel ist es, die falschen schnell abzulehnen und die echten mit Beweisen zu untermauern, gegen die man kaum argumentieren kann.
Jeder Kandidat, der überlebt, durchläuft zwei unabhängige Prüfungen. Kann ein echter Angreifer ihn in einer normalen Konfiguration tatsächlich erreichen? Und was kostet es den Angreifer, ihn durchzuziehen, im Vergleich zu dem, was es das Netzwerk kostet, wenn er funktioniert? Ein Fehler, den jeder einzelne Peer auslösen kann, unterscheidet sich stark von einem, der speziellen Zugang oder enorme Ressourcen erfordert.
Alles wird gegen eine fortlaufende Liste dessen geprüft, was bereits bekannt, behoben oder abgelehnt ist. Ohne diese Liste entdecken die Agenten immer wieder dasselbe geschlossene Problem und melden es wieder und wieder.
Die Akzeptanzraten variieren von Ziel zu Ziel stark, und diese Variation ist an sich schon nützlich. Lässt man dies gegen ausgereiften, stark überprüften Code laufen, überlebt fast nichts, was dennoch gut zu wissen ist. „Wir haben intensiv gesucht und nichts gefunden“ ist ein echtes Ergebnis. Lässt man es gegen weniger erforschten Code laufen oder gegen formal verifizierten Code, bei dem ein maschinell geprüfter Beweis ein Modell abdeckt und nur angenommen wird, dass der bereitgestellte Bytecode damit übereinstimmt, kommt mehr durch.
Wir sind nicht die Einzigen, die festgestellt haben, dass die Triage der schwierige Teil ist. Die wichtigste Erkenntnis von Cloudflare war, dass ein enger Fokus besser ist als breites Scannen. Der Agent für eigenschaftsbasiertes Testen von Anthropic generierte etwa tausend Kandidatenberichte und nutzte dann Ranking und Expertenprüfungen, um auf eine Spitzengruppe zu kommen, die in etwa 86 Prozent der Fälle standhielt. Die Generierung war der einfache Teil. Ich werde unsere eigenen Zahlen hier nicht veröffentlichen; da sie an ein spezifisches Ziel gebunden sind, würden sie mehr über das Ziel aussagen als über die Methode.
Worin die Agenten gut sind und wo sie in die Irre führen
Es gibt Hype in beide Richtungen, daher hier eine einfache Liste dessen, was die Agenten gut machen und wo sie in die Irre führen.
| Worin sie gut sind | Wo sie in die Irre führen |
|---|---|
| Die Spezifikation und den Code zusammen lesen | Aufrufketten, die erreichbar aussehen, es aber nicht sind |
| Eine echte Invariante aufstellen und prüfen | Die Erfolgsprüfung austricksen (ein Bestehen aus dem falschen Grund) |
| Einen Reproducer aus einer einzeiligen Idee entwerfen | Den Schweregrad aufblähen, damit er so dramatisch klingt wie der Bericht |
| Eine Fehlerursache vorschlagen, bevor man selbst nachgesehen hat | Fehler, die sich über eine Abfolge gültiger Schritte erstrecken |
Die Aufteilung ist nicht einmal von einer Aufgabe zur nächsten konstant. Stanislav Fort, der eine Reihe von Modellen an echten Schwachstellen testete, nennt dies eine zerklüftete Grenze (Jagged Frontier): Ein Modell, das eine vollständige Exploit-Kette in einer Codebasis wiederherstellt, kann bei der grundlegenden Datenflussverfolgung in einer anderen versagen. Man kann nicht davon ausgehen, dass ein gutes Ergebnis bedeutet, dass das nächste ebenfalls standhält, was ein weiterer Grund dafür ist, dass jeder Kandidat für sich allein geprüft wird.
Die letzte Zeile ist die wichtigste. Eine einzelne Agentensitzung ist gut im One-Shot-Reasoning und schlecht bei Fehlern, die sich über eine Abfolge von Schritten erstrecken, bei denen jeder Schritt gültig ist und nur die Reihenfolge falsch ist. Für diese ist der Agent nicht das Suchwerkzeug. Seine Aufgabe ist es vorzuschlagen, welche Sequenzen es wert sind, durch eine zustandsbehaftete Testumgebung zu laufen. So eingesetzt, funktioniert er gut. Wird er als Ersatz für die Testumgebung verwendet, übersieht er die teuersten Fehler, die es gibt – diejenigen, die nur über eine Sequenz hinweg auftreten.
Für Verlässlichkeit sorgen
Ein paar Gewohnheiten leisten die meiste Arbeit, um die Funde der Agenten vertrauenswürdig zu machen, und keine davon ist kompliziert.
- Provenienz bei jedem Artefakt: Was hat es produziert, in welchem Kontext, gegen welche Revision. Ein Fund sollte etwas sein, das man Monate später erneut ausführen kann.
- Determinismus, wo es darauf ankommt: eine Umgebung, ein Weg zum Kompilieren und Ausführen, sodass „reproduziert“ auf jeder Maschine dasselbe bedeutet, nicht nur auf der, auf der es gefunden wurde.
- Normen, keine Skripte: Sagen Sie den Agenten, worauf es ankommt, die Invarianten und die Messlatte für einen echten Fund, anstatt eines nummerierten Verfahrens. Zu stark geskriptete Agenten brechen auf dieselbe Weise wie zu stark spezifizierte Tests: Sie folgen den Schritten weiter, auch wenn die Schritte keinen Sinn mehr ergeben. Eine Studie über Repository-Kontextdateien kam zum selben Ergebnis: Die zusätzlichen Anforderungen senkten den Aufgabenerfolg und erhöhten die Kosten um über 20 %, und die Autoren empfehlen, den Kontext auf die minimalen Anforderungen zu beschränken.
- Eine Person trifft die endgültige Entscheidung: Agenten schlagen vor. Sie entscheiden nicht, was echt ist, was ein Duplikat eines bekannten Problems ist oder was wann offengelegt wird.
Der Flaschenhals hat sich verschoben
KI hat den Sicherheitsforscher nicht ersetzt. Sie hat die Arbeit verlagert. Die Zeit, die früher in das Aufstellen und Verfolgen von Hypothesen floss, fließt nun in deren massenhafte Beurteilung, einschließlich des Aufbaus des Orakels, der Durchführung der Triage, der Pflege der Liste bekannter Probleme und der Abwicklung der Offenlegung.
Der Flaschenhals ist nicht verschwunden. Er hat sich vom Finden von Fehlern hin zum Vertrauen in die Ergebnisse verschoben, was ein besserer Ort dafür ist, denn genau dort ist menschliches Urteilsvermögen tatsächlich wichtig. Aber es ist immer noch ein Flaschenhals, und wenn man das ignoriert, liefert man am Ende ein falsches „Alles in Ordnung“ aus.
Die Praktiken, die dies ermöglichen, sind nicht neu. Reproduzierbare Fehler, echte Orakel und sorgfältige Triage sind dieselben Praktiken, die Fuzzing in den letzten fünfzehn Jahren von einem Forschungsthema zu einer Standardpraxis gemacht haben. Die Werkzeuge sind neu. Die Praktiken sind es nicht.
Wie schnell sich die Werkzeuge weiter verändern, ist eine offene Frage. Nicholas Carlini, vorsichtig und einst selbst ein Skeptiker, argumentiert, dass der exponentielle Fall es wert ist, ernst genommen zu werden, auch wenn er große Fehlertoleranzen dafür ansetzt. Wenn die Generierungsseite so schnell ansteigt, muss die Beurteilungsseite mit ihr ansteigen, sonst wird die Lücke zwischen dem, was produziert wird, und dem, was tatsächlich verifiziert wird, nur noch größer.
Für die Systeme, von denen Ethereum abhängt, ist das der Teil, auf den es ankommt. Agenten ermöglichen es uns, viel mehr Boden abzudecken, als wir es von Hand könnten. Im Gegenzug verlangen sie ein sorgfältigeres Urteilsvermögen über einen viel größeren Berg selbstbewusst klingender Behauptungen hinweg. Das ist ein lohnender Tausch, solange man sich daran erinnert, dass das Urteilsvermögen das eigentliche Produkt ist.