Catatan dari tim Keamanan Protokol Yayasan Ethereum tentang menjalankan agen AI yang terkoordinasi terhadap kode protokol nyata, termasuk bagaimana kami mengatur pekerjaan tersebut, apa yang bertahan di bawah pengawasan, dan apa yang dapat dipelajari oleh tim klien dan peneliti keamanan dari hal ini. Tulisan ini berdiri sendiri; tulisan-tulisan berikutnya akan membahas lebih dalam mengenai masing-masing klien.
Apa yang telah kami jalankan, dan apa yang mengejutkan kami
Di tim Keamanan Protokol Yayasan Ethereum, kami telah menjalankan agen AI yang terkoordinasi terhadap jenis sistem yang menjadi sandaran jaringan, seperti perangkat lunak sistem, kode kriptografi, dan kontrak yang harus dipastikan kebenarannya. Agen-agen tersebut menemukan bug nyata. Salah satunya kini telah dipublikasikan: kepanikan (panic) yang dapat dipicu dari jarak jauh pada gossipsub libp2p, bagian inti dari lapisan peer-to-peer tempat klien konsensus Ethereum berjalan, yang telah diperbaiki dan diungkapkan sebagai CVE-2026-34219 dengan kredit diberikan kepada tim.
Agen yang menemukan bug bukanlah hal yang mengejutkan. Kejutan sebenarnya adalah betapa sedikitnya pekerjaan yang dihabiskan untuk menemukannya, dan betapa banyaknya pekerjaan yang dihabiskan untuk membedakan bug yang nyata dari yang hanya terlihat nyata.
Tulisan ini ditujukan bagi tim klien dan peneliti keamanan yang ingin melakukan hal yang sama. Tulisan ini mencakup bagaimana kami mengatur agen-agen tersebut, standar yang harus dipenuhi oleh sebuah kandidat sebelum dihitung sebagai temuan, dan kebiasaan yang menjaga agar hasilnya tetap dapat dipercaya.
Tim-tim di tempat lain juga menggunakan resep yang sama. Frontier Red Team dari Anthropic membangun sebuah agen yang menulis pengujian berbasis properti dan menemukan bug nyata di seluruh ekosistem Python. Cloudflare menjalankan model frontier melalui harness penelitian keamanan terhadap sistem mereka sendiri. Semuanya bermuara pada siklus yang sama: arahkan model yang mumpuni ke sebuah basis kode, biarkan model tersebut mencari, dan lakukan triase terhadap apa yang dikembalikannya. Jadi, pertanyaan sebenarnya adalah bagaimana melakukan ini tanpa tenggelam dalam kebisingan yang terdengar meyakinkan.
Satu peringatan di awal: perkakas untuk audit yang digerakkan oleh agen bergerak cepat, dan pengaturan spesifik apa pun akan menjadi usang dalam beberapa minggu. Jadi, tulisan ini sengaja membahas tentang metode, yang sifatnya persisten, daripada perkakasnya. Pengungkapan adalah topik tersendiri dan mungkin akan menjadi tulisan tersendiri.
Agen adalah alat pencarian, bukan orakel
Sebuah agen yang diarahkan ke basis kode adalah alat pencarian, sangat mirip dengan fuzzer. Perbedaannya terletak pada apa yang dikembalikannya. Sebuah fuzzer memberi Anda crash dan stack trace. Sebuah agen memberi Anda lebih banyak hal, termasuk laporan tertulis (rantai panggilan, klaim dampak, saran tingkat keparahan) dan artefak untuk mendukungnya, seperti proof-of-concept yang dapat Anda jalankan terhadap kode nyata.
Semua itu membuat hasilnya mudah dibaca dan mudah dipercaya, terutama proof-of-concept yang berjalan. Jadi, jangan hitung berapa banyak kandidat yang dihasilkan oleh sebuah agen. Hitunglah berapa banyak yang ternyata nyata.
Bagaimana pekerjaan ini diatur
Kami menjalankan banyak agen secara paralel terhadap satu target. Mereka berkoordinasi melalui repositori itu sendiri, dengan state yang dibagikan dalam kontrol versi dan tidak ada proses terpusat yang membagikan pekerjaan. Sebuah agen menuliskan klaim di mana agen lain dapat melihatnya, melakukan pekerjaan tersebut, dan melakukan commit.
Kami mendapatkan pendekatan ini dari tulisan Anthropic tentang membangun kompilator C dengan armada agen, yang berkoordinasi dengan cara yang sama. Tidak ada koordinator terpusat yang perlu dibangun atau dipelihara, dan lebih sedikit hal yang bisa salah.
Peran-peran dihasilkan oleh pekerjaan yang ditemukan:
- Pengintaian (Recon) mengubah permukaan serangan menjadi hipotesis yang konkret dan dapat diuji. Bukan "audit dekoder" melainkan "bidang ini dipercaya melewati titik ini; ini adalah properti yang harus dipertahankannya, cara properti itu mungkin rusak, dan bukti yang akan menyelesaikannya."
- Perburuan (Hunting) mengambil satu hipotesis, melacak jalur kode, dan mencoba membangun sebuah pereproduksi.
- Pengisian celah (Gap-filling) melihat apa yang diterima dan apa yang ditolak, menulis kumpulan hipotesis berikutnya, dan melacak cakupan sehingga agen tidak terus-menerus memeriksa area yang sama.
- Validasi (Validation) memeriksa ulang setiap kandidat secara independen, menghapus duplikat, dan mengambil keputusan.
Kami tidak menciptakan alur kerja ini. Cloudflare mendeskripsikan tahapan yang sama, pengintaian, perburuan paralel, validasi independen, deduplikasi, pelaporan, dan tulisan mereka membantu membentuk alur kerja kami.
Berikut adalah tampilan sebuah kandidat sebelum dihitung sebagai temuan:
target: komponen dan titik masuk yang benar-benar dapat dijangkau oleh penyerang invarian: properti yang harus dipertahankan mekanisme: cara spesifik yang mungkin membuatnya rusak keberhasilan: bukti yang dapat diamati: kepanikan, kemacetan, input tidak valid yang diterima pereproduksi: artefak mandiri yang berjalan terhadap kode nyata dedup: sebuah kunci, agar dua agen tidak mengejar hal yang sama
Skema tersebut ada karena suatu alasan. Skema ini memaksa adanya klaim yang spesifik dan dapat diuji serta definisi selesai yang jelas. Sebuah agen yang harus menuliskan bukti yang dapat diamati tidak bisa hanya mengandalkan alasan "ini terlihat berisiko."
Dapat direproduksi atau itu tidak terjadi
Ada satu aturan yang lebih penting dari apa pun. Sebuah kandidat bukanlah temuan sampai ada artefak mandiri yang mereproduksi kegagalan tersebut terhadap kode nyata, dan yang dapat dijalankan oleh seseorang yang tidak menulisnya.
Pereproduksi tidak membaca laporan tertulis, dan tidak peduli seberapa meyakinkan model tersebut terdengar. Pereproduksi itu hanya bisa berjalan atau tidak.
Sebagian besar nilainya terletak pada positif palsu yang ditangkapnya. Tiga di antaranya muncul berulang kali, dan masing-masing adalah agen yang lolos karena alasan yang salah:
- Kepanikan yang hanya terjadi pada build debug. Kompilasi dan jalankan dengan cara perangkat lunak tersebut benar-benar dirilis, dan nilainya hanya akan berputar kembali. Tidak ada yang crash. Itu terlihat seperti crash, tetapi sebenarnya bukan.
- Pereproduksi yang membangun beberapa nilai internal secara manual, yang tidak akan pernah bisa dihasilkan oleh input nyata mana pun, karena setiap jalur yang dikendalikan penyerang menolaknya lebih awal. Bug tersebut hanya "mereproduksi" terhadap fungsi yang tidak ada panggilan yang dapat dijangkau dengan cara seperti itu.
- Dalam pekerjaan verifikasi formal, sebuah bukti yang berhasil lolos tetapi tidak berarti seperti yang Anda inginkan. Pernyataan tersebut secara trivial benar terlepas dari apa yang dilakukan kode, atau lebih lemah dari properti yang ingin Anda tangkap. Pemverifikasi merasa puas, tetapi teorema tersebut tidak membatasi perilaku yang sebenarnya Anda pedulikan.
Semua ini bukanlah hal baru. Ini sama halnya dengan pengujian yang lulus karena sebenarnya tidak memeriksa apa pun. Yang baru adalah volumenya. Sebuah agen menulis versi yang tidak berguna secepat versi yang nyata, dan dengan tingkat keyakinan yang sama. Jadi, pemeriksaannya harus otomatis. Anda tidak bisa mengandalkan agen untuk menangkap kesalahannya sendiri.
Rasio sinyal-ke-kebisingan adalah sebagian besar dari pekerjaan
Sebagian besar kandidat salah, duplikat, atau di luar cakupan. Itu bukan masalah pada metodenya; memang begitulah cara kerjanya. Tujuannya adalah untuk menolak yang salah dengan cepat dan mendukung yang nyata dengan bukti yang sulit dibantah.
Setiap kandidat yang bertahan akan mendapatkan dua pemeriksaan independen. Bisakah penyerang nyata benar-benar menjangkaunya dalam konfigurasi normal? Dan berapa biaya yang harus dikeluarkan penyerang untuk melakukannya, dibandingkan dengan kerugian jaringan jika serangan itu berhasil? Sebuah bug yang dapat dipicu oleh satu peer mana pun sangat berbeda dengan bug yang membutuhkan akses khusus atau sumber daya dalam jumlah besar.
Semuanya diperiksa terhadap daftar berjalan dari apa yang sudah diketahui, diperbaiki, atau ditolak. Tanpa itu, agen akan terus menemukan kembali masalah tertutup yang sama dan melaporkannya berulang kali.
Tingkat penerimaan sangat bervariasi dari satu target ke target lainnya, dan variasi tersebut berguna dengan sendirinya. Jalankan ini terhadap kode yang sudah matang dan sangat sering diaudit, dan hampir tidak ada yang bertahan, yang mana hal ini tetap layak untuk diketahui. "Kami mencari dengan keras dan tidak menemukan apa pun" adalah hasil yang nyata. Jalankan terhadap kode yang kurang dieksplorasi, atau terhadap kode yang diverifikasi secara formal, di mana bukti yang diperiksa mesin mencakup sebuah model dan kode bita yang diterapkan hanya diasumsikan cocok dengannya, dan akan ada lebih banyak yang lolos.
Kami bukan satu-satunya yang menemukan bahwa triase adalah bagian yang sulit. Kesimpulan utama Cloudflare adalah bahwa cakupan yang sempit mengalahkan pemindaian yang luas. Agen pengujian berbasis properti milik Anthropic menghasilkan sekitar seribu laporan kandidat, kemudian menggunakan pemeringkatan dan tinjauan ahli untuk menyaringnya menjadi tingkat teratas yang bertahan sekitar 86 persen dari waktu. Pembuatannya adalah bagian yang mudah. Saya tidak akan mempublikasikan angka kami sendiri di sini; karena terikat pada target tertentu, angka tersebut akan lebih banyak berbicara tentang targetnya daripada tentang metodenya.
Keunggulan agen, dan di mana mereka menyesatkan
Ada sensasi di kedua arah, jadi berikut adalah daftar sederhana tentang apa yang dilakukan agen dengan baik dan di mana mereka menyesatkan.
| Keunggulan | Menyesatkan pada |
|---|---|
| Membaca spesifikasi dan kode secara bersamaan | Rantai panggilan yang terlihat dapat dijangkau tetapi sebenarnya tidak |
| Menyatakan dan memeriksa invarian yang nyata | Mengakali pemeriksaan keberhasilan (lulus karena alasan yang salah). |
| Menyusun draf pereproduksi dari ide satu baris | Melebih-lebihkan tingkat keparahan agar sesuai dengan seberapa dramatis laporan tertulisnya terdengar |
| Menyarankan akar penyebab sebelum Anda melihatnya | Bug yang mencakup serangkaian langkah yang valid |
Pembagian ini bahkan tidak stabil dari satu tugas ke tugas berikutnya. Stanislav Fort, yang menguji berbagai model pada kerentanan nyata, menyebut ini sebagai batas yang tidak rata, atau sebuah model yang memulihkan rantai eksploitasi penuh pada satu basis kode dapat gagal dalam pelacakan aliran data dasar pada basis kode lainnya. Anda tidak dapat berasumsi bahwa satu hasil yang baik berarti hasil berikutnya akan bertahan, yang merupakan alasan lain mengapa setiap kandidat diperiksa secara mandiri.
Baris terakhir adalah yang paling penting. Sesi agen tunggal bagus dalam penalaran satu kali dan buruk pada bug yang mencakup serangkaian langkah, di mana setiap langkah valid dan hanya urutannya yang salah. Untuk hal tersebut, agen bukanlah alat pencarian. Tugasnya adalah menyarankan urutan mana yang layak dijalankan melalui harness pengujian stateful. Digunakan dengan cara seperti itu, agen bekerja dengan baik. Digunakan sebagai pengganti harness, agen akan melewatkan bug paling mahal yang ada, yaitu bug yang hanya muncul di seluruh urutan.
Menjaganya tetap jujur
Beberapa kebiasaan melakukan sebagian besar pekerjaan untuk membuat temuan agen dapat dipercaya, dan tidak ada satu pun yang rumit.
- Asal-usul pada setiap artefak: apa yang menghasilkannya, dengan konteks apa, terhadap revisi yang mana. Sebuah temuan haruslah sesuatu yang dapat Anda jalankan kembali berbulan-bulan kemudian.
- Determinisme di tempat yang penting: satu lingkungan, satu cara untuk membangun dan menjalankan, sehingga "mereproduksi" memiliki arti yang sama di setiap mesin, bukan hanya di mesin tempat ia ditemukan.
- Norma, bukan skrip: beri tahu agen apa yang penting, invarian, dan standar untuk temuan nyata, alih-alih prosedur bernomor. Agen yang terlalu banyak diberi skrip akan rusak dengan cara yang sama seperti pengujian yang terlalu spesifik, mereka terus mengikuti langkah-langkah setelah langkah-langkah tersebut tidak lagi masuk akal. Sebuah studi tentang file konteks repositori menemukan hal yang sama: persyaratan tambahan menurunkan keberhasilan tugas dan meningkatkan biaya lebih dari 20%, dan para penulis merekomendasikan untuk menjaga konteks pada persyaratan minimal.
- Manusia yang mengambil keputusan akhir: agen hanya menyarankan. Mereka tidak memutuskan apa yang nyata, apa yang merupakan duplikat dari masalah yang diketahui, atau apa yang diungkapkan dan kapan.
Leher botol (bottleneck) telah berpindah
AI tidak menggantikan peneliti keamanan. AI memindahkan pekerjaannya. Waktu yang dulunya dihabiskan untuk memikirkan dan mengejar hipotesis kini dihabiskan untuk menilainya dalam skala besar, termasuk membangun orakel, menjalankan triase, menyimpan daftar masalah yang diketahui, dan menangani pengungkapan.
Leher botol tersebut tidak hilang. Ia berpindah dari menemukan bug menjadi mempercayai hasilnya, yang mana merupakan tempat yang lebih baik untuknya, karena di situlah penilaian manusia benar-benar penting. Namun, itu tetaplah sebuah leher botol, dan mengabaikannya adalah cara Anda pada akhirnya merilis sesuatu yang salah dengan anggapan "ini baik-baik saja."
Praktik-praktik yang membuat ini berhasil bukanlah hal baru. Kegagalan yang dapat direproduksi, orakel nyata, dan triase yang cermat adalah praktik yang sama yang mengubah fuzzing dari topik penelitian menjadi praktik standar selama lima belas tahun terakhir. Alat-alatnya baru. Praktik-praktiknya tidak.
Seberapa cepat alat-alat tersebut terus berubah adalah pertanyaan terbuka. Nicholas Carlini, yang berhati-hati dan dulunya seorang skeptis, berpendapat bahwa kasus eksponensial layak ditanggapi dengan serius, bahkan ketika ia tetap memberikan margin kesalahan yang lebar pada hal tersebut. Jika sisi pembuatan meningkat secepat itu, sisi penilaian harus meningkat bersamanya, atau kesenjangan antara apa yang diproduksi dan apa yang benar-benar diverifikasi hanya akan semakin melebar.
Untuk sistem yang menjadi sandaran Ethereum, itulah bagian yang penting. Agen memungkinkan kita mencakup area yang jauh lebih luas daripada yang bisa kita lakukan secara manual. Sebagai gantinya, mereka meminta penilaian yang lebih cermat, di seluruh tumpukan klaim yang terdengar meyakinkan yang jauh lebih besar. Itu adalah pertukaran yang layak dilakukan, selama Anda ingat bahwa penilaian tersebut adalah produk yang sebenarnya.