Re-Evaluating EVMBench: Are AI Agents Ready for Smart Contract Security?

Questo studio ricalibra le aspettative sull'auditing automatizzato dei contratti intelligenti, dimostrando che gli agenti AI, sebbene capaci di rilevare vulnerabilità note, mancano di stabilità e non riescono a sfruttare completamente le falle in scenari reali, evidenziando la necessità di un approccio ibrido uomo-macchina piuttosto che una soluzione completamente autonoma.

L'essenziale

🕵️‍♂️ Il Grande Esame: Gli Agenti AI sono pronti a fare gli "Investigatori di Sicurezza"?

Immagina che il mondo delle criptovalute e dei contratti intelligenti (Smart Contract) sia come una città digitale dove le persone lasciano milioni di dollari in casseforti pubbliche. Per proteggere queste casseforti, ci sono degli ispettori umani molto esperti che controllano se ci sono serrature rotte o finestre aperte.

Recentemente, un gruppo di ricercatori (OpenAI, Paradigm, OtterSec) ha lanciato un nuovo "esaminatore": un Intelligenza Artificiale (AI). Hanno detto: "Guardate! Questa AI è bravissima. Ha trovato il 45% delle serrature rotte e ha saputo rubare (simulando un attacco) il 72% dei soldi dalle casseforti più facili. Siamo quasi pronti a sostituire gli ispettori umani con i robot!"

Questo studio, scritto da ricercatori di Zhejiang University e BlockSec, dice: "Fermiamoci un attimo. Rivediamo l'esame."

Hanno scoperto che l'esame precedente era un po' "truccato" e che la realtà è molto più complessa. Ecco cosa hanno scoperto, usando delle metafore semplici.

---

1. L'Esame era troppo facile (e "inquinato") 📚

L'esame originale (chiamato EVMbench) usava domande prese da vecchi compiti in classe.

• Il problema: Molti di questi compiti erano stati scritti prima che l'AI venisse "addestrata". È come se un professore desse a uno studente un compito che lo studente ha già visto e memorizzato durante l'estate. L'AI ha preso un bel voto non perché è geniale, ma perché ha imparato a memoria le risposte.
• La soluzione: I nuovi ricercatori hanno creato un nuovo esame con 22 casi reali che sono accaduti dopo che l'AI è stata addestrata. Nessuno aveva mai visto queste domande prima.
• Il risultato: Quando hanno dato queste "domande nuove" all'AI, i voti sono crollati. L'AI ha trovato alcune serrature rotte, ma non è riuscita a "rubare" i soldi da nessuna delle 22 casseforti reali.

2. L'AI cambia personalità a seconda degli occhiali che indossa 👓

Nel primo esame, ogni modello di AI (come GPT o Claude) usava il suo "kit di strumenti" ufficiale (come se GPT usasse solo gli occhiali di OpenAI).

• La scoperta: I ricercatori hanno fatto indossare agli stessi modelli di AI occhiali diversi (strumenti creati da altri o open-source).
• L'analogia: È come se un calciatore giocasse meglio con le scarpe di un altro brand rispetto a quelle del suo sponsor. Hanno scoperto che cambiando gli "occhiali" (i software che aiutano l'AI a lavorare), le prestazioni cambiavano drasticamente. A volte un modello era il migliore, e con altri occhiali diventava l'ultimo della classe.
• Conclusione: Non possiamo dire che "l'AI è brava" in assoluto; dipende da come la facciamo lavorare.

3. Trovare il bug è facile, sfruttarlo è un'arte 🧩

L'esame originale diceva: "Trovare il buco è la parte difficile. Una volta trovato, rubare i soldi è facile."

• La realtà: I nuovi ricercatori hanno scoperto che è vero il contrario. L'AI è abbastanza brava a vedere che una porta è aperta (trovare il bug), ma è terribile nel capire come entrare, aggirare le guardie e scappare con i soldi (sfruttare il bug).
• L'analogia: È come se un detective dicesse: "Ho visto che la finestra è aperta!" (Ottimo lavoro!). Ma poi, quando deve entrare, sbaglia la scala, si impantana nel fango e non riesce a prendere il vaso di fiori.
• Risultato: Su 22 casi reali, nessuna AI è riuscita a completare l'attacco end-to-end. Zero su 110 tentativi.

4. Cosa significa per noi? (Il futuro non è "Robot contro Umani") 🤖 + 🧑‍💼

Alla fine, il paper non dice che l'AI è inutile. Dice che non è ancora pronta a lavorare da sola.

• Per chi sviluppa app: Puoi usare l'AI come un controllore di sicurezza veloce prima di lanciare il tuo prodotto. È bravissima a trovare errori banali (come una porta lasciata aperta di proposito), ma non fidarti ciecamente: potrebbe saltare i problemi complessi.
• Per le aziende di sicurezza: L'AI non sostituirà l'ispettore umano, ma sarà il suo assistente perfetto.
  • L'AI fa il lavoro sporco: Scansiona migliaia di pagine di codice per trovare i problemi comuni e ovvi.
  • L'Umano fa il lavoro difficile: Prende i risultati dell'AI, capisce il contesto specifico, pensa come un criminale e decide se è davvero un pericolo o un falso allarme.

🎯 La Morale della Favola

L'Intelligenza Artificiale è come un brillante tirocinante in un'agenzia di investigazione.

• È veloce, legge tutto, e trova i crimini più evidenti.
• Ma non ha ancora l'esperienza, l'intuito e la capacità di pensare fuori dagli schemi per risolvere i casi più complessi.

Il futuro della sicurezza non è "L'AI contro l'Uomo", ma "L'AI + l'Umano". Se le aziende usano l'AI per fare la prima passata e lasciano agli umani il compito di pensare, la sicurezza delle nostre casseforti digitali sarà molto più forte.

In sintesi: L'AI è pronta a darci una mano, ma non è ancora pronta a prendere il comando. Non lasciate le chiavi di casa al robot... ancora per un po'! 🔑🤖

Sommario tecnico

Ecco una sintesi tecnica dettagliata del paper "Re-Evaluating EVMBench: Are AI Agents Ready for Smart Contract Security?" in italiano.

1. Il Problema

Il benchmark EVMbench, rilasciato da OpenAI, Paradigm e OtterSec, è stato il primo tentativo su larga scala di valutare le capacità degli agenti AI nella sicurezza degli smart contract. I suoi risultati iniziali hanno generato un'ottimismo eccessivo, suggerendo che l'audit automatizzato completo fosse imminente: gli agenti avrebbero rilevato fino al 45,6% delle vulnerabilità e sfruttato il 72,2% di un sottoinsieme curato.

Tuttavia, gli autori identificano due limitazioni critiche nel design sperimentale di EVMbench che invalidano le sue conclusioni definitive:

1. Ambito di valutazione ristretto e confuso: EVMbench testa solo 14 configurazioni di agenti, accoppiando quasi sempre ogni modello con il suo "scaffold" (ambiente di lavoro) nativo del fornitore (es. Claude con Claude Code). Questo rende impossibile distinguere se le prestazioni siano dovute al modello o agli strumenti/scelte di workflow.
2. Contaminazione dei dati: Le 120 vulnerabilità testate provengono da concorsi di audit (Code4rena) pubblicati prima del rilascio della maggior parte dei modelli valutati. È probabile che i modelli abbiano visto questi dati durante l'addestramento, gonfiando i punteggi grazie alla memorizzazione piuttosto che alla capacità reale di rilevamento.

2. Metodologia

Per affrontare queste lacune, gli autori (Peng, Wu, Zhou) hanno condotto una rivalutazione estesa con il seguente approccio:

• Ampliamento delle Configurazioni: Hanno testato 26 configurazioni di agenti, coprendo quattro famiglie di modelli (Claude, GPT, Gemini, GLM) e tre scaffold diversi (Claude Code, Codex CLI, e uno open-source chiamato OpenCode). Questo permette di isolare l'impatto dello scaffold rispetto all'identità del modello.
• Dataset "Incidents" Contaminazione-Free: Hanno creato un nuovo dataset composto da 22 incidenti di sicurezza reali verificati sulla catena (on-chain). Tutti questi incidenti sono avvenuti dopo la data di rilascio di tutti i modelli valutati (metà febbraio 2026), garantendo che i modelli non avessero mai visto questi dati durante l'addestramento.
• Ambiente di Valutazione: Hanno mantenuto l'infrastruttura di EVMbench (container Docker isolati) ma hanno esteso la pipeline di verifica per l'exploit, richiedendo agli agenti di recuperare lo stato della catena, preparare i token di attacco ed eseguire transazioni profittevoli senza alcun suggerimento (hint).
• Task Valutati: Si sono concentrati su Detect (rilevamento) e Exploit (sfruttamento), escludendo il task "Patch" poiché la difficoltà di riparazione è strettamente correlata a quella del rilevamento.

3. Contributi Chiave

1. Rivelazione dell'instabilità delle classifiche: Dimostrano che le classifiche dei modelli non sono stabili; cambiano drasticamente in base al dataset, al task e allo scaffold utilizzato.
2. Sfida alla narrativa dell'automazione totale: Smentiscono la conclusione di EVMbench secondo cui il "rilevamento" è l'unico collo di bottiglia. Mostrano che, anche quando le vulnerabilità vengono rilevate, gli agenti falliscono sistematicamente nello sfruttamento end-to-end su dati reali.
3. Impatto dello Scaffold: Evidenziano che la scelta dello scaffold (ambiente di lavoro) ha un impatto materiale sui risultati, con scaffold open-source che superano talvolta quelli proprietari, un fattore ignorato da EVMbench.
4. Proposta di un Workflow Ibrido: Definiscono il ruolo reale degli agenti come filtri di primo livello all'interno di un processo "human-in-the-loop", piuttosto che come sostituti completi degli auditor umani.

4. Risultati Principali

A. Instabilità delle Prestazioni

• Le classifiche dei modelli sono altamente volatili. Ad esempio, Gemini 3.1 Pro si classifica 2° su EVMbench (37,5%) ma scende all'ultimo posto sul dataset Incidents (30,0%).
• La scelta dello scaffold altera significativamente i punteggi: OpenCode (open-source) ha superato gli scaffold proprietari in 5 casi su 6, con guadagni fino a 5 punti percentuali.

B. Il Divario tra Dati Curati e Reali (Incidents Dataset)

• Rilevamento: Sui dati reali, il miglior agente (Claude Opus 4.6) ha rilevato il 65% delle vulnerabilità. Sebbene sia un buon risultato, lascia scoperto oltre un terzo delle falle.
• Sfruttamento (Exploit): Questo è il risultato più critico. Mentre EVMbench riportava un tasso di successo nell'exploit del 72,2%, sul dataset Incidents nessun agente è riuscito a completare uno sfruttamento end-to-end su nessuna delle 22 incidenti reali (0 su 110 coppie agente-incidente).
• Gli agenti riescono a trovare vulnerabilità note (es. mancanza di controlli di accesso, overflow aritmetici), ma falliscono nel costruire transazioni complesse per sfruttarle in ambienti di produzione reali che richiedono interazioni multi-step e conoscenza specifica del protocollo.

C. Effetto del "Reasoning Effort"

• Aumentare il livello di ragionamento (token di pensiero) non garantisce sempre migliori prestazioni. In alcuni casi (es. GPT-5.2), un ragionamento eccessivo ha addirittura peggiorato i risultati nell'exploit, suggerendo che i modelli possono "sovrappensare" (overthink) percorsi di attacco semplici.

5. Significato e Implicazioni

Il paper conclude che l'idea di un audit automatizzato completamente autonomo è prematura e potenzialmente pericolosa se basata su metriche non controllate.

• Per gli Sviluppatori: Gli scan degli agenti possono essere utili come controllo pre-deploy per pattern noti, ma non devono essere l'unica linea di difesa. Un tasso di rilevamento del 47-65% significa che la metà delle vulnerabilità rimane invisibile.
• Per le Aziende di Audit: Il modello più efficace è il workflow "human-in-the-loop". Gli agenti dovrebbero agire come filtri di primo passaggio per gestire la "larghezza" (scansionare grandi codebase per pattern comuni), liberando gli auditor umani per concentrarsi sulla "profondità" (conoscenza specifica del protocollo, ragionamento avversario e filtraggio dei falsi positivi).
• Metodologia di Valutazione: Le future valutazioni devono considerare lo scaffold e il livello di ragionamento come variabili controllate e devono utilizzare dataset privi di contaminazione temporale per misurare la vera capacità di generalizzazione.

In sintesi, gli agenti AI hanno capacità reali ma limitate: sono eccellenti nel riconoscere pattern noti e rispondono bene al contesto fornito dall'uomo, ma non possono ancora sostituire il giudizio umano nella sicurezza degli smart contract.