EF Blog

ETH top background starting image
ETH bottom background ending image
Skip to content

This post is available in 25 languages:

Čeština

Třídění je produkt: spouštění AI agentů proti kódu protokolu Etherea

Posted by Nikos Baxevanis on 9. července 2026

Třídění je produkt: spouštění AI agentů proti kódu protokolu Etherea

Poznámky od týmu pro bezpečnost protokolu Nadace Ethereum o spouštění koordinovaných AI agentů proti skutečnému kódu protokolu, včetně toho, jak práci organizujeme, co obstojí při zkoumání a co si z toho mohou odnést klientské týmy a bezpečnostní výzkumníci. Tento příspěvek funguje samostatně; pozdější příspěvky půjdou více do hloubky u jednotlivých klientů.

Co jsme spouštěli a co nás překvapilo

V týmu pro bezpečnost protokolu Nadace Ethereum jsme spouštěli koordinované AI agenty proti typům systémů, na kterých síť závisí, jako je systémový software, kryptografický kód a kontrakty, které musí být bezchybné. Agenti našli skutečné chyby. Jedna z nich je nyní veřejná: na dálku spustitelná panika (panic) v gossipsub knihovny libp2p, což je klíčová část peer-to-peer vrstvy, na které běží klienti konsensu Etherea. Byla opravena a zveřejněna jako CVE-2026-34219 s poděkováním týmu.

To, že agenti našli chyby, nebylo překvapením. Překvapením bylo, jak málo práce dalo jejich nalezení a kolik úsilí stálo odlišit skutečné chyby od těch, které tak jen vypadaly.

Tento příspěvek je určen pro klientské týmy a bezpečnostní výzkumníky, kteří chtějí dělat totéž. Pokrývá to, jak agenty organizujeme, jakou laťku musí kandidát překonat, než je považován za nález, a návyky, které udržují výsledky důvěryhodné.

Týmy jinde se sbíhají u stejného receptu. Tým Frontier Red Team společnosti Anthropic vytvořil agenta, který píše testy založené na vlastnostech (property-based tests) a našel skutečné chyby napříč ekosystémem jazyka Python. Cloudflare prohnal frontier model přes testovací prostředí pro bezpečnostní výzkum proti svým vlastním systémům. Všichni končí u stejné smyčky: nasměrovat schopný model na kódovou základnu, nechat ho hledat a třídit to, co se vrátí. Skutečnou otázkou tedy je, jak to udělat, aniž byste se utopili v sebevědomě znějícím šumu.

Jedno upozornění předem: nástroje pro audity řízené agenty se vyvíjejí rychle a jakékoli konkrétní nastavení je za pár týdnů zastaralé. Tento příspěvek je tedy záměrně o metodách, které jsou trvalé, spíše než o nástrojích. Zveřejňování zranitelností (disclosure) je samostatné téma a pravděpodobně mu bude věnován vlastní příspěvek.

Agent je vyhledávací nástroj, ne orákulum

Agent nasměrovaný na kódovou základnu je vyhledávací nástroj, velmi podobný fuzzeru. Rozdíl je v tom, co se vrátí. Fuzzer vám předá pád a výpis zásobníku (stack trace). Agent vám předá mnohem více, včetně zprávy (řetězec volání, tvrzení o dopadu, navrhovaná závažnost) a artefaktů, které to dokládají, jako je proof-of-concept, který můžete spustit proti skutečnému kódu.

Díky tomu všemu je výsledek snadno čitelný a snadno se mu věří, ze všeho nejvíce pak fungujícímu proof-of-conceptu. Nepočítejte tedy, kolik kandidátů agent vyprodukuje. Počítejte, kolik z nich se ukáže jako skutečných.

Jak je práce organizována

Spouštíme mnoho agentů paralelně proti jednomu cíli. Koordinují se prostřednictvím samotného repozitáře, se sdíleným stavem ve správě verzí a bez centrálního procesu, který by rozděloval práci. Agent zapíše tvrzení tam, kde ho ostatní vidí, odvede práci a provede commit.

Tento přístup jsme převzali z článku společnosti Anthropic o vytváření překladače jazyka C pomocí flotily agentů, který se koordinuje stejným způsobem. Neexistuje žádný centrální koordinátor, kterého by bylo nutné budovat nebo udržovat, a je tu méně věcí, které se mohou pokazit.

Role jsou generovány objevenou prací:

  • Průzkum (Recon) mění útočnou plochu na konkrétní, testovatelné hypotézy. Ne „proveďte audit dekodéru“, ale „tomuto poli se za tímto bodem důvěřuje; zde je vlastnost, kterou by si mělo zachovat, způsob, jakým by se mohlo rozbít, a důkaz, který by to vyřešil.“
  • Lov (Hunting) vezme jednu hypotézu, sleduje cestu kódem a pokusí se vytvořit reproduktor (reproducer).
  • Vyplňování mezer (Gap-filling) se dívá na to, co bylo přijato a co odmítnuto, píše další várku hypotéz a sleduje pokrytí, aby agenti neprocházeli stále stejnou oblast.
  • Validace (Validation) nezávisle znovu kontroluje každého kandidáta, odstraňuje duplicity a rozhoduje.

Tuto pipeline jsme nevymysleli my. Cloudflare popisuje stejné fáze: průzkum, paralelní lov, nezávislou validaci, deduplikaci, reportování, a jejich článek pomohl formovat ten náš.

Zde je ukázka toho, jak vypadá kandidát, než je považován za nález:

cíl:         komponenta a vstupní bod, na který může útočník skutečně dosáhnout
invariant:   vlastnost, která musí platit
mechanismus: konkrétní způsob, jakým by mohlo dojít k jejímu porušení
úspěch:      pozorovatelný důkaz: panika, zásek, přijatý neplatný vstup
reproduktor: samostatný artefakt, který běží proti skutečnému kódu
dedup:       klíč, aby dva agenti nehonili stejnou věc

Toto schéma tu je z nějakého důvodu. Vynucuje si konkrétní, testovatelné tvrzení a jasnou definici hotové práce (definition of done). Agent, který musí zapsat pozorovatelný důkaz, se nemůže uchýlit k „tohle vypadá riskantně.“

Reprodukovatelné, nebo se to nestalo

Jedno pravidlo je důležitější než jakékoli jiné. Kandidát není nálezem, dokud neexistuje samostatný artefakt, který reprodukuje selhání proti skutečnému kódu a který funguje i někomu, kdo jej nenapsal.

Reproduktor nečte zprávu a nezajímá ho, jak sebevědomě model zněl. Buď funguje, nebo ne.

Většina jeho hodnoty spočívá ve falešně pozitivních výsledcích, které zachytí. Tři z nich se objevují stále dokola a každý z nich znamená, že agent projde ze špatného důvodu:

  • Panika, ke které dochází pouze v debug sestavení. Zkompilujte a spusťte to tak, jak se software skutečně dodává, a hodnota se prostě přetočí (wraps around). Nic nespadne. Vypadá to jako pád, ale není.
  • Reproduktor, který ručně sestaví nějakou vnitřní hodnotu, kterou by žádný skutečný vstup nikdy nemohl vyprodukovat, protože každá cesta, kterou útočník ovládá, ji odmítne dříve. Chyba se „reprodukuje“ pouze proti funkci, kterou nic dosažitelného tímto způsobem nevolá.
  • Při formální verifikaci jde o důkaz, který projde, ale neznamená to, co jste chtěli. Tvrzení je triviálně pravdivé bez ohledu na to, co kód dělá, nebo je slabší než vlastnost, kterou jste chtěli zachytit. Ověřovatel je spokojen, ale teorém neomezuje chování, na kterém vám skutečně záleželo.

Nic z toho není nové. Je to stejné jako test, který projde, protože ve skutečnosti nic nekontroluje. Nový je ten objem. Agent napíše zbytečnou verzi stejně rychle jako tu skutečnou a se stejným sebevědomím. Kontrola tedy musí být automatická. Nemůžete spoléhat na to, že se agent přistihne sám.

Poměr signálu k šumu je většina práce

Většina kandidátů je chybná, duplicitní nebo mimo rozsah. To není problém metody; tak to prostě funguje. Cílem je rychle odmítnout ty špatné a podpořit ty skutečné důkazem, se kterým se těžko polemizuje.

Každý kandidát, který přežije, projde dvěma nezávislými kontrolami. Může na něj skutečný útočník v normální konfiguraci reálně dosáhnout? A co to útočníka stojí provést, v porovnání s tím, co to stojí síť, pokud to vyjde? Chyba, kterou může spustit jakýkoli jednotlivý peer, se velmi liší od chyby, která vyžaduje speciální přístup nebo obrovské množství zdrojů.

Vše se kontroluje proti průběžnému seznamu toho, co je již známo, opraveno nebo odmítnuto. Bez toho agenti neustále znovu objevují stejný uzavřený problém a hlásí ho znovu a znovu.

Míra přijetí se u jednotlivých cílů velmi liší a tato variabilita je užitečná sama o sobě. Spusťte to proti vyspělému, silně auditovanému kódu a nepřežije téměř nic, což je stále dobré vědět. „Hledali jsme důkladně a nic jsme nenašli“ je skutečný výsledek. Spusťte to proti méně prozkoumanému kódu nebo proti formálně verifikovanému kódu, kde strojově kontrolovaný důkaz pokrývá model a u nasazeného bajtkódu se pouze předpokládá, že mu odpovídá, a projde toho více.

Nejsme jediní, kdo zjistil, že třídění je ta těžká část. Hlavním poznatkem Cloudflare bylo, že úzký rozsah je lepší než široké skenování. Agent společnosti Anthropic pro testování založené na vlastnostech vygeneroval zhruba tisíc kandidátských reportů, poté použil hodnocení a expertní posouzení, aby se dostal na nejvyšší úroveň, která obstála zhruba v 86 procentech případů. Generování byla ta snadná část. Naše vlastní čísla zde zveřejňovat nebudu; vázána na konkrétní cíl by vypovídala více o cíli než o metodě.

V čem jsou agenti dobří a kde klamou

Hype existuje v obou směrech, takže zde je prostý seznam toho, co agenti dělají dobře a kde klamou.

V čem jsou dobříV čem klamou
Čtení specifikace a kódu dohromadyŘetězce volání, které vypadají dosažitelně, ale nejsou
Stanovení a kontrola skutečného invariantuOklamání kontroly úspěšnosti (projde ze špatného důvodu).
Návrh reproduktoru z jednořádkového nápaduZveličování závažnosti, aby odpovídala tomu, jak dramaticky zpráva zní
Návrh hlavní příčiny (root cause) předtím, než se podíváteChyby, které se táhnou přes sekvenci platných kroků

Toto rozdělení není ani stabilní od jednoho úkolu k druhému. Stanislav Fort, který testoval řadu modelů na skutečných zranitelnostech, to nazývá zubatou hranicí (jagged frontier), neboli model, který obnoví celý řetězec exploitů na jedné kódové základně, může selhat při základním sledování toku dat na jiné. Nemůžete předpokládat, že jeden dobrý výsledek znamená, že obstojí i ten další, což je další důvod, proč se každý kandidát kontroluje samostatně.

Poslední řádek je ten důležitý. Jedna relace agenta je dobrá v jednorázovém uvažování a špatná u chyb, které se táhnou přes sekvenci kroků, kde je každý krok platný a pouze pořadí je špatné. Pro ty není agent vyhledávacím nástrojem. Jeho úkolem je navrhnout, které sekvence stojí za to prohnat přes stavové testovací prostředí (stateful test harness). Při tomto způsobu použití funguje dobře. Pokud se použije jako náhrada za testovací prostředí, mine ty nejdražší chyby, které existují, ty, které se projeví pouze napříč sekvencí.

Udržování poctivosti

Několik návyků odvede většinu práce na tom, aby byla zjištění agentů důvěryhodná, a žádný z nich není složitý.

  • Původ (provenance) u každého artefaktu: co ho vyprodukovalo, s jakým kontextem, proti jaké revizi. Nález by měl být něco, co můžete znovu spustit o měsíce později.
  • Determinismus tam, kde na něm záleží: jedno prostředí, jeden způsob sestavení a spuštění, takže „reprodukuje se“ znamená totéž na každém stroji, nejen na tom, kde to bylo nalezeno.
  • Normy, ne skripty: řekněte agentům, na čem záleží, jaké jsou invarianty a laťka pro skutečný nález, místo očíslovaného postupu. Přeskriptovaní agenti se rozbijí stejným způsobem jako přespecifikované testy, pokračují v dodržování kroků i poté, co kroky přestanou dávat smysl. Studie souborů kontextu repozitáře zjistila totéž: dodatečné požadavky snížily úspěšnost úkolu a zvýšily náklady o více než 20 % a autoři doporučují udržovat kontext na minimálních požadavcích.
  • Konečné slovo má člověk: agenti navrhují. Nerozhodují o tom, co je skutečné, co je duplikát známého problému, nebo co a kdy se zveřejní.

Úzké hrdlo se přesunulo

Umělá inteligence nenahradila bezpečnostního výzkumníka. Přesunula práci. Čas, který se dříve věnoval vymýšlení a prověřování hypotéz, se nyní věnuje jejich posuzování ve velkém měřítku, včetně budování orákula, provádění třídění, udržování seznamu známých problémů a řešení zveřejňování.

Úzké hrdlo nezmizelo. Přesunulo se od hledání chyb k důvěře ve výsledky, což je pro něj lepší místo, protože právě tam skutečně záleží na lidském úsudku. Ale stále je to úzké hrdlo a jeho ignorování je způsob, jak nakonec vydáte chybné „je to v pořádku.“

Postupy, díky kterým to funguje, nejsou nové. Reprodukovatelná selhání, skutečná orákula a pečlivé třídění jsou tytéž postupy, které za posledních patnáct let udělaly z fuzzingu z výzkumného tématu standardní praxi. Nástroje jsou nové. Postupy nikoli.

Jak rychle se nástroje budou nadále měnit, je otevřená otázka. Nicholas Carlini, opatrný a kdysi sám skeptik, tvrdí, že exponenciální scénář stojí za to brát vážně, i když si u něj ponechává široké meze chyb. Pokud strana generování stoupá tak rychle, strana posuzování musí stoupat s ní, jinak se propast mezi tím, co se vyprodukuje, a tím, co se skutečně ověří, bude jen zvětšovat.

Pro systémy, na kterých Ethereum závisí, je to ta část, na které záleží. Agenti nám umožňují pokrýt mnohem více prostoru, než bychom zvládli ručně. Výměnou za to vyžadují pečlivější úsudek napříč mnohem větší hromadou sebevědomě znějících tvrzení. To je obchod, který stojí za to uzavřít, pokud si pamatujete, že tím skutečným produktem je úsudek.

This post has been translated from English. As a result, it may not be entirely accurate or up to date. The original version can be found in English.

Stay Updated

Subscribe to get email notifications about the topics you care about. Choose from research, events, security updates, and more.


Categories