Notatki zespołu ds. bezpieczeństwa protokołu Fundacji Ethereum na temat uruchamiania skoordynowanych agentów AI na rzeczywistym kodzie protokołu, w tym o tym, jak organizujemy pracę, co sprawdza się w praktyce i co zespoły klienckie oraz badacze bezpieczeństwa mogą z tego wyciągnąć. Ten post stanowi odrębną całość; późniejsze wpisy będą głębiej analizować poszczególnych klientów.
Co uruchamialiśmy i co nas zaskoczyło
W zespole ds. bezpieczeństwa protokołu Fundacji Ethereum uruchamialiśmy skoordynowanych agentów AI przeciwko rodzajom systemów, od których zależy sieć, takim jak oprogramowanie systemowe, kod kryptograficzny i kontrakty, które muszą być bezbłędne. Agenci znaleźli prawdziwe błędy. Jeden z nich jest już publiczny: zdalnie wywoływana panika w gossipsub biblioteki libp2p, kluczowej części warstwy peer-to-peer, na której działają klienci konsensusu Ethereum, naprawiona i ujawniona jako CVE-2026-34219 z uznaniem dla zespołu.
Znajdowanie błędów przez agentów nie było niespodzianką. Zaskoczeniem było to, jak mało pracy włożono w ich znalezienie, a jak dużo w odróżnienie prawdziwych błędów od tych, które tylko wyglądały na prawdziwe.
Ten post jest przeznaczony dla zespołów klienckich i badaczy bezpieczeństwa, którzy chcą robić to samo. Obejmuje on sposób, w jaki organizujemy agentów, poprzeczkę, którą kandydat musi pokonać, zanim zostanie uznany za znalezisko, oraz nawyki, które sprawiają, że wyniki są wiarygodne.
Inne zespoły skłaniają się ku tej samej recepcie. Zespół Frontier Red Team z Anthropic zbudował agenta, który pisze testy oparte na właściwościach i znalazł prawdziwe błędy w całym ekosystemie języka Python. Cloudflare przepuściło model Frontier przez środowisko testowe do badań nad bezpieczeństwem przeciwko własnym systemom. Wszyscy lądują w tej samej pętli: skieruj zdolny model na bazę kodu, pozwól mu szukać i selekcjonuj to, co wraca. Prawdziwe pytanie brzmi więc, jak to zrobić, nie tonąc w pewnie brzmiącym szumie.
Jedno zastrzeżenie na wstępie: narzędzia do audytów opartych na agentach rozwijają się szybko, a każda konkretna konfiguracja staje się przestarzała w ciągu kilku tygodni. Dlatego ten post celowo dotyczy metod, które są trwałe, a nie narzędzi. Ujawnianie błędów to osobny temat i prawdopodobnie doczeka się własnego wpisu.
Agent to narzędzie wyszukiwania, a nie wyrocznia
Agent skierowany na bazę kodu to narzędzie wyszukiwania, bardzo podobne do fuzzera. Różnica polega na tym, co wraca. Fuzzer daje ci awarię i ślad stosu. Agent daje ci znacznie więcej, w tym opis (łańcuch wywołań, twierdzenie o wpływie, sugerowaną wagę) i artefakty, które to potwierdzają, takie jak proof-of-concept, który możesz uruchomić na prawdziwym kodzie.
Wszystko to sprawia, że wynik jest łatwy do odczytania i łatwy do zaufania, a działający proof-of-concept w szczególności. Nie licz więc, ilu kandydatów produkuje agent. Policz, ilu z nich okazuje się prawdziwych.
Jak zorganizowana jest praca
Uruchamiamy wielu agentów równolegle przeciwko jednemu celowi. Koordynują się oni poprzez samo repozytorium, ze współdzielonym stanem w systemie kontroli wersji i bez centralnego procesu rozdzielającego pracę. Agent zapisuje swoje twierdzenie tam, gdzie inni mogą je zobaczyć, wykonuje pracę i zatwierdza zmiany.
Zaczerpnęliśmy to podejście z artykułu Anthropic o budowaniu kompilatora C za pomocą floty agentów, która koordynuje się w ten sam sposób. Nie ma centralnego koordynatora do zbudowania lub utrzymania, a tym samym mniej rzeczy może pójść nie tak.
Role są generowane przez odkrywaną pracę:
- Rozpoznanie (Recon) zamienia powierzchnię ataku w konkretne, testowalne hipotezy. Nie "przeprowadź audyt dekodera", ale "temu polu ufa się po tym punkcie; oto właściwość, którą powinno zachować, sposób, w jaki może się zepsuć, i dowód, który by to rozstrzygnął".
- Polowanie (Hunting) bierze jedną hipotezę, śledzi ścieżkę kodu i próbuje zbudować reproduktor.
- Wypełnianie luk (Gap-filling) analizuje to, co zostało zaakceptowane i odrzucone, pisze kolejną partię hipotez i śledzi pokrycie, aby agenci nie wracali ciągle do tego samego.
- Walidacja (Validation) ponownie sprawdza każdego kandydata niezależnie, usuwa duplikaty i podejmuje decyzję.
Nie wymyśliliśmy tego potoku. Cloudflare opisuje te same etapy: rozpoznanie, równoległe polowanie, niezależną walidację, deduplikację, raportowanie, a ich artykuł pomógł ukształtować nasz.
Oto jak wygląda kandydat, zanim zostanie uznany za znalezisko:
cel: komponent i punkt wejścia, do którego atakujący może faktycznie dotrzeć niezmiennik: właściwość, która musi zostać zachowana mechanizm: konkretny sposób, w jaki można doprowadzić do jej złamania sukces: obserwowalny dowód: panika, zatrzymanie, zaakceptowane nieprawidłowe wejście reproduktor: samodzielny artefakt, który działa na prawdziwym kodzie dedup: klucz, aby dwóch agentów nie ścigało tego samego
Schemat istnieje nie bez powodu. Wymusza konkretne, testowalne twierdzenie i jasną definicję ukończenia. Agent, który musi zapisać obserwowalny dowód, nie może uciec się do stwierdzenia "to wygląda ryzykownie".
Odtwarzalne albo się nie wydarzyło
Jedna zasada ma większe znaczenie niż jakakolwiek inna. Kandydat nie jest znaleziskiem, dopóki nie ma samodzielnego artefaktu, który odtwarza błąd na prawdziwym kodzie i który działa u kogoś, kto go nie napisał.
Reproduktor nie czyta opisu i nie obchodzi go, jak pewnie brzmiał model. Albo działa, albo nie.
Większość jego wartości tkwi w fałszywie pozytywnych wynikach, które wyłapuje. Trzy z nich pojawiają się w kółko, a każdy z nich to sytuacja, w której agent zostaje przepuszczony z niewłaściwego powodu:
- Panika, która występuje tylko w kompilacji debugowania. Skompiluj i uruchom to w sposób, w jaki oprogramowanie jest faktycznie dostarczane, a wartość po prostu się zawija. Nic nie ulega awarii. Wygląda jak awaria, ale nią nie jest.
- Reproduktor, który ręcznie buduje pewną wewnętrzną wartość, taką, której żadne prawdziwe wejście nie mogłoby nigdy wyprodukować, ponieważ każda ścieżka kontrolowana przez atakującego odrzuca ją wcześniej. Błąd "odtwarza się" tylko w funkcji, której nic osiągalnego nie wywołuje w ten sposób.
- W pracy nad weryfikacją formalną, dowód, który przechodzi, ale nie oznacza tego, co chciałeś. Twierdzenie jest trywialnie prawdziwe niezależnie od tego, co robi kod, lub jest słabsze niż właściwość, którą chciałeś uchwycić. Weryfikator jest usatysfakcjonowany, ale twierdzenie nie ogranicza zachowania, na którym ci faktycznie zależało.
Nic z tego nie jest nowe. To to samo, co test, który przechodzi, ponieważ w rzeczywistości niczego nie sprawdza. Nowością jest skala. Agent pisze bezużyteczną wersję równie szybko jak prawdziwą i równie pewnie. Dlatego sprawdzanie musi być automatyczne. Nie możesz liczyć na to, że agent sam się złapie.
Stosunek sygnału do szumu to większość pracy
Większość kandydatów jest błędna, zduplikowana lub poza zakresem. To nie jest problem z metodą; tak to po prostu działa. Celem jest szybkie odrzucenie tych błędnych i poparcie prawdziwych dowodem, z którym trudno dyskutować.
Każdy kandydat, który przetrwa, przechodzi dwa niezależne sprawdzenia. Czy prawdziwy atakujący może faktycznie do niego dotrzeć w normalnej konfiguracji? I ile kosztuje atakującego jego przeprowadzenie w porównaniu z tym, ile kosztuje to sieć, jeśli się powiedzie? Błąd, który może wywołać dowolny pojedynczy węzeł równorzędny, bardzo różni się od takiego, który wymaga specjalnego dostępu lub ogromnej ilości zasobów.
Wszystko jest sprawdzane z bieżącą listą tego, co jest już znane, naprawione lub odrzucone. Bez tego agenci wciąż na nowo odkrywają ten sam zamknięty problem i zgłaszają go raz za razem.
Wskaźniki akceptacji bardzo się różnią w zależności od celu, a ta zmienność sama w sobie jest użyteczna. Uruchom to na dojrzałym, poddanym rygorystycznym audytom kodzie, a prawie nic nie przetrwa, co i tak warto wiedzieć. "Szukaliśmy uważnie i nic nie znaleźliśmy" to prawdziwy wynik. Uruchom to na mniej zbadanym kodzie lub na kodzie zweryfikowanym formalnie, gdzie sprawdzony maszynowo dowód obejmuje model, a wdrożony kod bajtowy jest tylko zakładany jako zgodny z nim, a przejdzie więcej.
Nie tylko my odkryliśmy, że selekcja to najtrudniejsza część. Głównym wnioskiem Cloudflare było to, że wąski zakres jest lepszy niż szerokie skanowanie. Agent Anthropic do testowania opartego na właściwościach wygenerował około tysiąca raportów kandydatów, a następnie użył rankingu i przeglądu eksperckiego, aby zejść do najwyższego poziomu, który sprawdzał się w około 86 procentach przypadków. Generowanie było łatwą częścią. Nie zamierzam publikować tutaj naszych własnych liczb; powiązane z konkretnym celem, powiedziałyby więcej o celu niż o metodzie.
W czym agenci są dobrzy, a gdzie wprowadzają w błąd
Szum informacyjny działa w obu kierunkach, więc oto prosta lista tego, co agenci robią dobrze, a gdzie wprowadzają w błąd.
| W czym są dobrzy | Gdzie wprowadzają w błąd |
|---|---|
| Czytanie specyfikacji i kodu jednocześnie | Łańcuchy wywołań, które wyglądają na osiągalne, ale nie są |
| Określanie i sprawdzanie prawdziwego niezmiennika | Oszukiwanie testu sukcesu (zaliczenie z niewłaściwego powodu). |
| Tworzenie szkicu reproduktora z jednozdaniowego pomysłu | Zawyżanie wagi błędu, aby pasowała do tego, jak dramatycznie brzmi opis |
| Sugerowanie przyczyny źródłowej, zanim samemu się sprawdzi | Błędy obejmujące sekwencję prawidłowych kroków |
Podział ten nie jest nawet stały z zadania na zadanie. Stanislav Fort, testując szereg modeli na prawdziwych podatnościach, nazywa to poszarpaną granicą – model, który odzyskuje pełny łańcuch exploitów w jednej bazie kodu, może oblać podstawowe śledzenie przepływu danych w innej. Nie można zakładać, że jeden dobry wynik oznacza, że kolejny też się sprawdzi, co jest kolejnym powodem, dla którego każdy kandydat jest sprawdzany osobno.
Ostatni wiersz jest tym ważnym. Pojedyncza sesja agenta jest dobra w jednorazowym rozumowaniu i słaba w błędach, które obejmują sekwencję kroków, gdzie każdy krok jest prawidłowy, a tylko kolejność jest błędna. W takich przypadkach agent nie jest narzędziem wyszukiwania. Jego zadaniem jest zasugerowanie, które sekwencje warto przepuścić przez stanowe środowisko testowe. Używany w ten sposób, działa dobrze. Używany jako zamiennik dla środowiska testowego, omija najdroższe błędy, jakie istnieją – te, które pojawiają się tylko w całej sekwencji.
Utrzymanie rzetelności
Kilka nawyków wykonuje większość pracy, aby znaleziska agentów były wiarygodne, i żaden z nich nie jest skomplikowany.
- Pochodzenie każdego artefaktu: co go wyprodukowało, w jakim kontekście, w stosunku do jakiej rewizji. Znalezisko powinno być czymś, co można uruchomić ponownie kilka miesięcy później.
- Determinizm tam, gdzie ma to znaczenie: jedno środowisko, jeden sposób budowania i uruchamiania, więc "odtwarza się" oznacza to samo na każdej maszynie, a nie tylko na tej, na której zostało znalezione.
- Normy, nie skrypty: powiedz agentom, co ma znaczenie, jakie są niezmienniki i poprzeczka dla prawdziwego znaleziska, zamiast podawać ponumerowaną procedurę. Zbyt oskryptowani agenci psują się w ten sam sposób, co zbyt szczegółowe testy – nadal wykonują kroki, nawet gdy przestają one mieć sens. Badanie plików kontekstowych repozytorium wykazało to samo: dodatkowe wymagania obniżyły sukces zadania i podniosły koszty o ponad 20%, a autorzy zalecają ograniczenie kontekstu do minimalnych wymagań.
- Człowiek podejmuje ostateczną decyzję: agenci sugerują. Nie decydują o tym, co jest prawdziwe, co jest duplikatem znanego problemu, ani co i kiedy zostaje ujawnione.
Wąskie gardło się przesunęło
Sztuczna inteligencja nie zastąpiła badacza bezpieczeństwa. Przesunęła pracę. Czas, który kiedyś poświęcano na wymyślanie i ściganie hipotez, teraz idzie na ich ocenę na dużą skalę, w tym budowanie wyroczni, przeprowadzanie selekcji, prowadzenie listy znanych problemów i obsługę ujawniania.
Wąskie gardło nie zniknęło. Przesunęło się ze znajdowania błędów na ufanie wynikom, co jest dla niego lepszym miejscem, ponieważ to tam ludzki osąd ma faktycznie znaczenie. Ale to wciąż wąskie gardło, a ignorowanie tego to sposób, w jaki kończysz, wypuszczając błędne "wszystko jest w porządku".
Praktyki, które sprawiają, że to działa, nie są nowe. Odtwarzalne awarie, prawdziwe wyrocznie i staranna selekcja to te same praktyki, które w ciągu ostatnich piętnastu lat zmieniły fuzzing z tematu badawczego w standardową praktykę. Narzędzia są nowe. Praktyki nie.
To, jak szybko narzędzia będą się zmieniać, pozostaje otwartym pytaniem. Nicholas Carlini, ostrożny i niegdyś sam będący sceptykiem, twierdzi, że scenariusz wykładniczy warto traktować poważnie, nawet jeśli zachowuje przy tym szeroki margines błędu. Jeśli strona generowania wspina się tak szybko, strona oceny musi wspinać się razem z nią, w przeciwnym razie luka między tym, co jest produkowane, a tym, co jest faktycznie weryfikowane, tylko się powiększy.
W przypadku systemów, od których zależy Ethereum, to jest ta część, która ma znaczenie. Agenci pozwalają nam objąć znacznie większy obszar, niż moglibyśmy to zrobić ręcznie. W zamian wymagają ostrożniejszego osądu w odniesieniu do znacznie większej sterty pewnie brzmiących twierdzeń. To wymiana, na którą warto pójść, o ile pamiętasz, że to osąd jest prawdziwym produktem.