Anmerkungen des Protokollsicherheitsteams der Ethereum Foundation zum Einsatz koordinierter KI-Agenten gegen echten Protokollcode, einschließlich der Art und Weise, wie wir die Arbeit organisieren, was bei der Prüfung Bestand hat und was Kundenteams und Sicherheitsforscher daraus ziehen können. Dieser Beitrag steht für sich; Spätere Beiträge werden detaillierter auf einzelne Kunden eingehen.
Was wir gelaufen sind und was uns überrascht hat
Im Protokollsicherheitsteam der Ethereum Foundation haben wir koordinierte KI-Agenten gegen die Arten von Systemen eingesetzt, von denen das Netzwerk abhängt, wie Systemsoftware, kryptografischen Code und Verträge, die stimmen müssen. Die Agenten fanden echte Fehler. Eines ist jetzt öffentlich: eine aus der Ferne auslösbare Panik im GossipSub von libp2p, einem Kernbestandteil der Peer-to-Peer-Schicht, auf der Ethereum-Konsens-Clients laufen, behoben und offengelegt CVE-2026-34219 Mit Dank an das Team.
Dass Agenten Fehler fanden, war keine Überraschung. Die Überraschung war, wie wenig Arbeit darin steckte, sie zu finden, und wie viel Arbeit darin steckte, die echten Käfer von denen zu unterscheiden, die einfach echt aussahen.
Dieser Beitrag richtet sich an Kundenteams und Sicherheitsforscher, die dasselbe tun möchten. Es geht darum, wie wir die Agenten organisieren, welche Hürden ein Kandidat überwinden muss, bevor es als Ergebnis gilt, und die Gewohnheiten, die dafür sorgen, dass die Ergebnisse vertrauenswürdig sind.
Teams an anderen Orten arbeiten nach dem gleichen Rezept. Das Frontier Red Team von Anthropic hat einen Agenten entwickelt schreibt eigenschaftsbasierte Tests und hat echte Fehler im gesamten Python-Ökosystem gefunden. Wolkenflare ließ ein Grenzmodell durch ein Sicherheitsforschungssystem laufen gegen ihre eigenen Systeme. Alle landen in der gleichen Schleife: Richten Sie ein leistungsfähiges Modell auf eine Codebasis, lassen Sie es suchen und selektieren, was zurückkommt. Die eigentliche Frage ist also, wie man das schafft, ohne in selbstbewusst klingendem Lärm zu ertrinken.
Ein Vorbehalt vorweg: Tools für agentengesteuerte Audits entwickeln sich schnell und jedes spezifische Setup ist in ein paar Wochen veraltet. In diesem Beitrag geht es also bewusst um die Methoden, die dauerhaft sind, und nicht um die Werkzeuge. Offenlegung ist ein eigenes Thema und wird wahrscheinlich ein eigener Beitrag sein.
Ein auf eine Codebasis gerichteter Agent ist ein Suchwerkzeug, ähnlich einem Fuzzer. Der Unterschied ist, was zurückkommt. Ein Fuzzer gibt Ihnen einen Absturz und einen Stack-Trace. Ein Agent gibt Ihnen noch viel mehr, einschließlich einer Beschreibung (Anrufkette, Schadensbehauptung, vorgeschlagener Schweregrad) und der dazugehörigen Artefakte, wie zum Beispiel einen Proof-of-Concept, den Sie anhand des echten Codes durchführen können.
All das macht das Ergebnis leicht lesbar und vertrauenswürdig, vor allem den laufenden Proof-of-Concept. Zählen Sie also nicht, wie viele Kandidaten ein Agent hervorbringt. Zählen Sie, wie viele sich als echt herausstellen.
Wie die Arbeit organisiert ist
Wir führen viele Agenten parallel gegen ein Ziel aus. Sie koordinieren über das Repository selbst, mit gemeinsamem Status in der Versionskontrolle und keinem zentralen Prozess, der die Arbeit verteilt. Ein Agent schreibt einen Anspruch nieder, wo die anderen ihn sehen können, erledigt die Arbeit und verpflichtet sich.
Wir haben diesen Ansatz aus dem Artikel von Anthropic übernommen Aufbau eines C-Compilers mit einer Flotte von Agentenwas auf die gleiche Weise koordiniert. Es gibt keinen zentralen Koordinator, der erstellt oder gewartet werden muss, und es gibt weniger Dinge, die schief gehen können.
Die Rollen werden durch die entdeckte Arbeit generiert:
- Recon verwandelt eine Angriffsfläche in konkrete, überprüfbare Hypothesen. Nicht „den Decoder prüfen“, sondern „dieses Feld ist über diesen Punkt hinaus vertrauenswürdig; hier ist die Eigenschaft, die es behalten sollte, die Art und Weise, wie es kaputt gehen könnte, und der Beweis, der es klären würde.“
- Hunting geht von einer Hypothese aus, verfolgt den Codepfad und versucht, einen Reproduzierer zu erstellen.
- Beim Lückenfüllen wird geprüft, was akzeptiert und was abgelehnt wurde, es werden die nächsten Hypothesen erstellt und die Berichterstattung nachverfolgt, damit die Agenten nicht immer wieder den gleichen Standpunkt vertreten.
- Bei der Validierung wird jeder Kandidat einzeln erneut überprüft, Duplikate entfernt und eine Entscheidung getroffen.
Wir haben diese Pipeline nicht erfunden. Cloudflare beschreibt die gleichen Phasen: Aufklärung, paralleles Hunting, unabhängige Validierung, Deduplizierung, Berichterstellung, und ihre Beschreibung hat unsere Phase mitgeprägt.
So sieht ein Kandidat aus, bevor er als Ergebnis gilt:
target: component and entry point an attacker can actually reach invariant: the property that must hold mechanism: the specific way it might be made to break success: observable proof: a panic, a stall, an accepted-invalid input reproducer: a self-contained artifact that runs against the real code dedup: a key, so two agents don't chase the same thing
Das Schema gibt es aus einem bestimmten Grund. Es erzwingt einen konkreten, überprüfbaren Anspruch und eine klare Definition von erledigt. Ein Agent, der einen beobachtbaren Beweis aufschreiben muss, kann nicht auf die Aussage zurückgreifen: „Das sieht riskant aus.“
Reproduzierbar oder es ist nicht passiert
Eine Regel ist wichtiger als jede andere. Ein Kandidat ist kein Ergebnis, bis es ein eigenständiges Artefakt gibt, das den Fehler anhand des echten Codes reproduziert und für jemanden ausgeführt wird, der ihn nicht geschrieben hat.
Der Reproduzierer liest den Text nicht und es ist ihm egal, wie sicher das Modell klang. Entweder läuft es oder nicht.
Der größte Teil seines Werts liegt in den Fehlalarmen, die es abfängt. Drei von ihnen tauchen immer wieder auf, und bei jedem handelt es sich um den Agenten, der aus dem falschen Grund einen Pass erhält:
- Eine Panik, die nur in einem Debug-Build auftritt. Kompilieren Sie es und führen Sie es so aus, wie die Software tatsächlich geliefert wird, und der Wert ist einfach umwerfend. Nichts stürzt ab. Es sieht nach einem Absturz aus, ist aber keiner.
- Ein Reproduzierer, der von Hand einen internen Wert aufbaut, den keine wirkliche Eingabe jemals erzeugen könnte, weil jeder von einem Angreifer kontrollierte Pfad ihn früher ablehnt. Der Fehler „reproduziert“ sich nur bei einer Funktion, die nichts Erreichbares auf diese Weise aufruft.
- Bei der formalen Verifizierung handelt es sich um einen Beweis, der durchkommt, aber nicht das bedeutet, was Sie wollten. Die Aussage ist trivial wahr, unabhängig davon, was der Code tut, oder sie ist schwächer als die Eigenschaft, die Sie erfassen wollten. Der Verifizierer ist zufrieden, aber das Theorem schränkt das Verhalten, das Sie tatsächlich interessierten, nicht ein.
Nichts davon ist neu. Es ist dasselbe wie ein Test, der bestanden wird, weil er eigentlich nichts prüft. Neu ist die Lautstärke. Ein Agent schreibt die nutzlose Version genauso schnell wie die echte und genauso sicher. Die Prüfung muss also automatisch erfolgen. Sie können sich nicht darauf verlassen, dass der Agent sich selbst fängt.
Signal-Rausch-Verhältnis ist die meiste Arbeit
Die meisten Kandidaten liegen falsch, doppelt oder außerhalb des Geltungsbereichs. Das ist mit der Methode kein Problem; so funktioniert es. Das Ziel besteht darin, die falschen schnell abzulehnen und die echten mit Beweisen zu untermauern, mit denen man nur schwer streiten kann.
Jeder überlebende Kandidat erhält zwei unabhängige Schecks. Kann ein echter Angreifer in einer normalen Konfiguration tatsächlich darauf zugreifen? Und wie hoch sind die Kosten für den Angreifer im Vergleich zu den Kosten für das Netzwerk, wenn es funktioniert? Ein Fehler, den jeder einzelne Peer auslösen kann, unterscheidet sich stark von einem Fehler, der besonderen Zugriff oder eine große Menge an Ressourcen erfordert.
Alles wird anhand einer fortlaufenden Liste dessen überprüft, was bereits bekannt, behoben oder abgelehnt wurde. Andernfalls entdecken die Agenten immer wieder dasselbe geschlossene Problem und melden es immer wieder.
Die Akzeptanzraten variieren stark von Ziel zu Ziel, und diese Variation ist für sich genommen nützlich. Wenn Sie dies mit ausgereiftem, stark geprüftem Code ausführen, bleibt fast nichts übrig, was immer noch wissenswert ist. „Wir haben genau gesucht und nichts gefunden“ ist ein echtes Ergebnis. Führen Sie es gegen weniger erforschten Code oder gegen formal verifizierten Code aus, bei dem ein maschinengeprüfter Beweis ein Modell abdeckt und nur davon ausgegangen wird, dass der bereitgestellte Bytecode damit übereinstimmt, und mehr durchkommt.
Wir sind nicht die Einzigen, die die Triage für den schwierigsten Teil halten. Die wichtigste Erkenntnis von Cloudflare war, dass ein schmaler Bereich besser ist als ein breiter Scan. Anthropics Agent für eigenschaftsbasierte Tests erstellte etwa tausend Kandidatenberichte und gelangte dann mithilfe von Rankings und Expertenbewertungen zu einer Spitzengruppe, die sich in etwa 86 Prozent der Fälle behaupten konnte. Die Generation war der einfache Teil. Ich werde hier nicht unsere eigenen Zahlen veröffentlichen; Wenn sie an ein bestimmtes Ziel gebunden sind, sagen sie mehr über das Ziel als über die Methode aus.
Was die Agenten gut können und wo sie in die Irre führen
Es gibt einen Hype in beide Richtungen, daher finden Sie hier eine übersichtliche Liste dessen, was die Agenten gut machen und wo sie irreführen.
| Gut darin | Irreführend bei |
|---|---|
| Lesen Sie die Spezifikation und den Code zusammen | Anrufketten, die erreichbar erscheinen, es aber nicht sind |
| Angabe und Überprüfung einer echten Invariante | Den Erfolgscheck spielen (ein Bestehen aus dem falschen Grund). |
| Aus einer einzeiligen Idee einen Reproduzierer entwerfen | Den Schweregrad erhöhen, um ihn an die Dramatik des Artikels anzupassen |
| Schlagen Sie eine Grundursache vor, bevor Sie nachgeschaut haben | Fehler, die eine Abfolge gültiger Schritte umfassen |
Die Aufteilung ist nicht einmal gleichmäßig von einer Aufgabe zur nächsten. Stanislav Fort, der eine Reihe von Modellen auf reale Schwachstellen testet, nennt dies einen zerklüftete Grenzeoder ein Modell, das eine vollständige Exploit-Kette auf einer Codebasis wiederherstellt, kann bei der grundlegenden Datenflussverfolgung auf einer anderen fehlschlagen. Man kann nicht davon ausgehen, dass ein gutes Ergebnis gleichbedeutend mit dem nächsten Ergebnis ist. Auch deshalb wird jeder Kandidat einzeln geprüft.
Die letzte Reihe ist die wichtigste. Eine einzelne Agentensitzung eignet sich gut für einmaliges Denken und schlecht für Fehler, 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 besteht darin, vorzuschlagen, welche Sequenzen es wert sind, durchlaufen zu werden Zustandsbehafteter Test-Harness. So eingesetzt funktioniert es gut. Als Ersatz für den Kabelbaum verwendet, übersieht es die teuersten Fehler, die es gibt, nämlich diejenigen, die nur in einer Sequenz auftauchen.
Bleiben wir ehrlich
Ein paar Gewohnheiten machen den größten Teil der Arbeit aus, um Agentenergebnisse vertrauenswürdig zu machen, und keine davon ist kompliziert.
- Herkunft jedes Artefakts: Was hat es hervorgebracht, in welchem Kontext, gegen welche Revision. Ein Ergebnis sollte etwas sein, das Sie Monate später noch einmal überprüfen können.
- Determinismus, wo es darauf ankommt: eine Umgebung, eine Möglichkeit zum Erstellen und Ausführen, daher bedeutet „reproduzieren“ auf jeder Maschine dasselbe, nicht nur auf der Maschine, auf der sie gefunden wurde.
- Normen, keine Skripte: Sagen Sie den Agenten, worauf es ankommt, auf die Invarianten und die Messlatte für einen echten Befund, statt einer nummerierten Prozedur. Agenten mit zu vielen Skripten scheitern auf die gleiche Weise wie zu spezifizierte Tests. Sie folgen den Schritten weiter, auch wenn die Schritte keinen Sinn mehr ergeben. A Untersuchung von Repository-Kontextdateien fanden das Gleiche: Die zusätzlichen Anforderungen verringerten den Aufgabenerfolg und erhöhten die Kosten um über 20 %, und die Autoren empfehlen, den Kontext auf die Mindestanforderungen zu beschränken.
- Eine Person macht den letzten Anruf: Agenten schlagen vor. Sie entscheiden nicht, was real ist, was ein Duplikat eines bekannten Problems ist oder was wann offengelegt wird.
Der Engpass hat sich verschoben
KI hat den Sicherheitsforscher nicht ersetzt. Es hat die Arbeit bewegt. Die Zeit, die früher für die Entwicklung und Verfolgung von Hypothesen aufgewendet wurde, wird jetzt für deren umfassende Beurteilung aufgewendet, einschließlich der Errichtung des Orakels, der Durchführung der Triage, der Führung der Liste bekannter Probleme und der Handhabung der Offenlegung.
Der Engpass verschwand nicht. Es ging von der Suche nach Fehlern hin zum Vertrauen auf die Ergebnisse, was ein besserer Ort dafür ist, denn hier kommt es tatsächlich auf das menschliche Urteilsvermögen an. Aber es ist immer noch ein Engpass, und wenn man das ignoriert, bekommt man am Ende ein falsches „Es ist in Ordnung“ zugeschickt.
Die Praktiken, die dafür sorgen, dass dies funktioniert, sind nicht neu. Reproduzierbare Fehler, echte Orakel und sorgfältige Triage sind die gleichen Praktiken, die Fuzzing in den letzten fünfzehn Jahren von einem Forschungsthema zur Standardpraxis gemacht haben. Die Werkzeuge sind neu. Die Praktiken sind es nicht.
Wie schnell sich die Tools ändern, ist eine offene Frage. Nicholas Carlini, vorsichtig und selbst einmal ein Skeptiker, argumentiert, dass es sich lohnt, den exponentiellen Fall ernst zu nehmenauch wenn er große Fehlerbalken aufweist. Wenn die Generationsseite so schnell voranschreitet, muss auch die Beurteilungsseite mit nach oben klettern, sonst wird die Kluft 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 entscheidende Teil. Mithilfe von Agenten konnten wir viel mehr Gebiete abdecken, als wir mit der Hand könnten. Im Gegenzug fordern sie ein sorgfältigeres Urteil über einen viel größeren Haufen selbstbewusst klingender Behauptungen. Das ist ein lohnenswerter Handel, solange Sie bedenken, dass es sich bei dem Urteil um das tatsächliche Produkt handelt.
