Il triage è il prodotto: eseguire agenti IA sul codice del protocollo di Ethereum

Note del team di Protocol Security della Fondazione Ethereum sull'esecuzione di agenti IA coordinati su codice di protocollo reale, incluso come organizziamo il lavoro, cosa resiste a un'analisi approfondita e cosa possono trarne i team dei client e i ricercatori di sicurezza. Questo articolo è a sé stante; i post successivi approfondiranno i singoli client.

Cosa abbiamo eseguito e cosa ci ha sorpreso

Nel team di Protocol Security della Fondazione Ethereum, abbiamo eseguito agenti IA coordinati sui tipi di sistemi da cui dipende la rete, come software di sistema, codice crittografico e contratti che devono essere corretti. Gli agenti hanno trovato bug reali. Uno è ora pubblico: un panic attivabile da remoto nel gossipsub di libp2p, una parte fondamentale del livello peer-to-peer su cui vengono eseguiti i client di consenso di Ethereum, risolto e divulgato come CVE-2026-34219 con i crediti al team.

Che gli agenti trovassero bug non è stata una sorpresa. La sorpresa è stata quanto poco lavoro sia servito per trovarli e quanto ne sia servito per distinguere i bug reali da quelli che sembravano solo tali.

Questo post è rivolto ai team dei client e ai ricercatori di sicurezza che vogliono fare la stessa cosa. Tratta di come organizziamo gli agenti, dei requisiti che un candidato deve soddisfare prima di essere considerato una scoperta e delle abitudini che mantengono affidabili i risultati.

Altri team stanno convergendo sulla stessa ricetta. Il Frontier Red Team di Anthropic ha creato un agente che scrive test basati sulle proprietà e ha trovato bug reali in tutto l'ecosistema Python. Cloudflare ha eseguito un modello di frontiera attraverso un'infrastruttura di ricerca sulla sicurezza contro i propri sistemi. Tutti arrivano allo stesso ciclo: puntare un modello capace su una base di codice, lasciarlo cercare e fare il triage di ciò che restituisce. Quindi la vera domanda è come farlo senza annegare in un rumore che suona sicuro di sé.

Un avvertimento preliminare: gli strumenti per gli audit guidati da agenti si evolvono rapidamente e qualsiasi configurazione specifica diventa obsoleta in poche settimane. Quindi questo post riguarda deliberatamente i metodi, che sono persistenti, piuttosto che gli strumenti. La divulgazione è un argomento a sé stante e probabilmente avrà un post dedicato.

Un agente è uno strumento di ricerca, non un oracolo

Un agente puntato su una base di codice è uno strumento di ricerca, molto simile a un fuzzer. La differenza è ciò che restituisce. Un fuzzer ti consegna un crash e una stack trace. Un agente ti consegna molto di più, inclusa una relazione (catena di chiamate, affermazione sull'impatto, gravità suggerita) e gli artefatti a supporto, come una proof-of-concept che puoi eseguire sul codice reale.

Tutto ciò rende il risultato facile da leggere e di cui fidarsi, soprattutto la proof-of-concept funzionante. Quindi non contate quanti candidati produce un agente. Contate quanti si rivelano reali.

Come è organizzato il lavoro

Eseguiamo molti agenti in parallelo contro un singolo bersaglio. Si coordinano attraverso il repository stesso, con uno stato condiviso nel controllo di versione e nessun processo centrale che distribuisce il lavoro. Un agente annota un'ipotesi dove gli altri possono vederla, esegue il lavoro e fa il commit.

Abbiamo preso questo approccio dall'articolo di Anthropic sulla creazione di un compilatore C con una flotta di agenti, che si coordina allo stesso modo. Non c'è un coordinatore centrale da costruire o mantenere, e ci sono meno cose che possono andare storte.

I ruoli sono generati dal lavoro che viene scoperto:

• La ricognizione (Recon) trasforma una superficie di attacco in ipotesi concrete e testabili. Non "fai l'audit del decoder" ma "questo campo è considerato attendibile oltre questo punto; ecco la proprietà che dovrebbe mantenere, il modo in cui potrebbe rompersi e la prova che lo confermerebbe."
• La caccia (Hunting) prende un'ipotesi, traccia il percorso del codice e cerca di costruire un riproduttore.
• Il riempimento delle lacune (Gap-filling) esamina ciò che è stato accettato e ciò che è stato rifiutato, scrive il lotto successivo di ipotesi e traccia la copertura in modo che gli agenti non continuino a ripassare sullo stesso terreno.
• La convalida (Validation) ricontrolla ogni candidato in modo indipendente, rimuove i duplicati e decide.

Non abbiamo inventato noi questa pipeline. Cloudflare descrive le stesse fasi: ricognizione, caccia parallela, convalida indipendente, deduplicazione, reportistica, e il loro articolo ha contribuito a plasmare il nostro.

Ecco come si presenta un candidato prima di essere considerato una scoperta:

bersaglio:      componente e punto di ingresso che un utente malintenzionato può effettivamente raggiungere
invariante:     la proprietà che deve essere mantenuta
meccanismo:     il modo specifico in cui potrebbe essere fatto rompere
successo:       prova osservabile: un panic, uno stallo, un input non valido accettato
riproduttore:   un artefatto autonomo che viene eseguito sul codice reale
dedup:          una chiave, in modo che due agenti non inseguano la stessa cosa

Lo schema è lì per un motivo. Forza un'affermazione specifica e testabile e una chiara definizione di completamento. Un agente che deve annotare una prova osservabile non può ripiegare su "questo sembra rischioso".

Riproducibile o non è successo

Una regola conta più di ogni altra. Un candidato non è una scoperta finché non c'è un artefatto autonomo che riproduce il fallimento sul codice reale e che funziona per qualcuno che non lo ha scritto.

Il riproduttore non legge la relazione e non gli importa quanto il modello sembrasse sicuro di sé. O funziona o non funziona.

La maggior parte del suo valore risiede nei falsi positivi che intercetta. Tre di questi si presentano ripetutamente, e ognuno di essi rappresenta l'agente che ottiene un'approvazione per il motivo sbagliato:

• Un panic che si verifica solo in una build di debug. Compilandolo ed eseguendolo nel modo in cui il software viene effettivamente distribuito, il valore semplicemente riparte da zero (wrap around). Non va in crash nulla. Sembra un crash, ma non lo è.
• Un riproduttore che costruisce a mano un valore interno, uno che nessun input reale potrebbe mai produrre, perché ogni percorso controllato da un utente malintenzionato lo rifiuta prima. Il bug si "riproduce" solo contro una funzione che nulla di raggiungibile chiama in quel modo.
• Nel lavoro di verifica formale, una prova che va a buon fine ma non significa ciò che volevi. L'affermazione è banalmente vera indipendentemente da ciò che fa il codice, oppure è più debole della proprietà che intendevi catturare. Il verificatore è soddisfatto, ma il teorema non vincola il comportamento che ti interessava davvero.

Niente di tutto questo è nuovo. È la stessa cosa di un test che passa perché in realtà non controlla nulla. Ciò che è nuovo è il volume. Un agente scrive la versione inutile alla stessa velocità di quella reale, e con la stessa sicurezza. Quindi il controllo deve essere automatico. Non puoi contare sul fatto che l'agente si corregga da solo.

Il rapporto segnale-rumore è la maggior parte del lavoro

La maggior parte dei candidati è sbagliata, duplicata o fuori ambito. Questo non è un problema del metodo; è così che funziona. L'obiettivo è rifiutare rapidamente quelli sbagliati e supportare quelli reali con prove difficili da contestare.

Ogni candidato che sopravvive viene sottoposto a due controlli indipendenti. Un utente malintenzionato reale può effettivamente raggiungerlo in una configurazione normale? E quanto costa all'utente malintenzionato portarlo a termine, rispetto a quanto costa alla rete se funziona? Un bug che qualsiasi singolo peer può innescare è molto diverso da uno che richiede un accesso speciale o un'enorme quantità di risorse.

Tutto viene controllato rispetto a un elenco aggiornato di ciò che è già noto, risolto o rifiutato. Senza di esso, gli agenti continuano a riscoprire lo stesso problema chiuso e a segnalarlo ancora e ancora.

I tassi di accettazione variano molto da bersaglio a bersaglio, e questa variazione è utile di per sé. Eseguilo su codice maturo e pesantemente controllato e non sopravvive quasi nulla, il che vale comunque la pena di essere saputo. "Abbiamo cercato a fondo e non abbiamo trovato nulla" è un risultato reale. Eseguilo su codice meno esplorato, o su codice verificato formalmente, dove una prova controllata dalla macchina copre un modello e si presume solo che il bytecode distribuito vi corrisponda, e ne passa di più.

Non siamo gli unici ad aver scoperto che il triage è la parte difficile. La conclusione principale di Cloudflare è stata che un ambito ristretto batte una scansione ampia. L'agente di test basato sulle proprietà di Anthropic ha generato qualcosa come mille report candidati, per poi utilizzare il posizionamento e la revisione di esperti per scendere a un livello superiore che ha retto circa l'86% delle volte. La generazione è stata la parte facile. Non pubblicherò i nostri numeri qui; legati a un bersaglio specifico, direbbero di più sul bersaglio che sul metodo.

In cosa sono bravi gli agenti e dove fuorviano

C'è clamore in entrambe le direzioni, quindi ecco un semplice elenco di ciò che gli agenti fanno bene e dove fuorviano.

La divisione non è nemmeno costante da un'attività all'altra. Stanislav Fort, testando una gamma di modelli su vulnerabilità reali, la definisce una frontiera frastagliata, ovvero un modello che recupera un'intera catena di exploit su una base di codice può fallire il tracciamento di base del flusso di dati su un'altra. Non si può presumere che un buon risultato significhi che il successivo reggerà, il che è un altro motivo per cui ogni candidato viene controllato singolarmente.

L'ultima riga è quella importante. Una singola sessione di un agente è brava nel ragionamento immediato (one-shot) e pessima nei bug che si estendono su una sequenza di passaggi, dove ogni passaggio è valido e solo l'ordine è sbagliato. Per quelli, l'agente non è lo strumento di ricerca. Il suo compito è suggerire quali sequenze vale la pena eseguire attraverso un'infrastruttura di test con stato (stateful). Usato in questo modo, funziona bene. Usato come sostituto dell'infrastruttura, si perde i bug più costosi che ci siano, quelli che si manifestano solo attraverso una sequenza.

Mantenerlo onesto

Poche abitudini fanno la maggior parte del lavoro per rendere affidabili le scoperte degli agenti, e nessuna di esse è complicata.

• Provenienza su ogni artefatto: cosa lo ha prodotto, con quale contesto, contro quale revisione. Una scoperta dovrebbe essere qualcosa che puoi rieseguire mesi dopo.
• Determinismo dove conta: un ambiente, un modo per compilare ed eseguire, in modo che "si riproduce" significhi la stessa cosa su ogni macchina, non solo su quella in cui è stato trovato.
• Norme, non script: dire agli agenti cosa conta, gli invarianti e il livello per una scoperta reale, invece di una procedura numerata. Gli agenti con troppi script si rompono nello stesso modo in cui lo fanno i test troppo specificati: continuano a seguire i passaggi dopo che i passaggi smettono di avere senso. Uno studio sui file di contesto dei repository ha scoperto la stessa cosa: i requisiti aggiuntivi hanno abbassato il successo delle attività e aumentato i costi di oltre il 20%, e gli autori raccomandano di mantenere il contesto ai requisiti minimi.
• Una persona prende la decisione finale: gli agenti suggeriscono. Non decidono cosa è reale, cosa è un duplicato di un problema noto o cosa viene divulgato e quando.

Il collo di bottiglia si è spostato

L'IA non ha sostituito il ricercatore di sicurezza. Ha spostato il lavoro. Il tempo che prima veniva impiegato per elaborare e inseguire ipotesi ora viene impiegato per giudicarle su larga scala, inclusa la costruzione dell'oracolo, l'esecuzione del triage, il mantenimento dell'elenco dei problemi noti e la gestione della divulgazione.

Il collo di bottiglia non è scomparso. Si è spostato dalla ricerca dei bug alla fiducia nei risultati, che è un posto migliore, perché è lì che il giudizio umano conta davvero. Ma è pur sempre un collo di bottiglia, e ignorarlo è il modo in cui si finisce per rilasciare un errato "va tutto bene".

Le pratiche che fanno funzionare tutto questo non sono nuove. Fallimenti riproducibili, oracoli reali e un triage attento sono le stesse pratiche che hanno trasformato il fuzzing da un argomento di ricerca a una pratica standard negli ultimi quindici anni. Gli strumenti sono nuovi. Le pratiche no.

Quanto velocemente gli strumenti continuino a cambiare è una questione aperta. Nicholas Carlini, attento e un tempo lui stesso scettico, sostiene che il caso esponenziale merita di essere preso sul serio, anche se mantiene ampi margini di errore al riguardo. Se il lato della generazione sale così in fretta, il lato del giudizio deve salire con esso, altrimenti il divario tra ciò che viene prodotto e ciò che viene effettivamente verificato non farà che allargarsi.

Per i sistemi da cui dipende Ethereum, questa è la parte che conta. Gli agenti ci permettono di coprire molto più terreno di quanto potremmo fare a mano. In cambio, richiedono un giudizio più attento, su una pila molto più grande di affermazioni che suonano sicure di sé. È uno scambio che vale la pena fare, a patto di ricordare che il giudizio è il vero prodotto.