Siapa yang bisa mengubah atau mematikan AI Agent ini?

"Matikan saja" sebenarnya empat hal berbeda

Berhenti menerima tugas, berhenti menandatangani, mengubah logika, dan berhenti memakai aset Anda adalah empat kekuasaan terpisah. Satu pihak bisa memegang beberapa sekaligus, jadi pengendali tiap kekuasaan perlu dicek sendiri-sendiri.

Di banyak diskusi, keempatnya dilebur jadi satu kalimat: "tim bisa menghentikan Agent kapan saja." Akibatnya penilaian jadi meleset. Ada yang merasa aman setelah mencabut izin, padahal logika kontraknya masih bisa diganti. Ada juga yang tenang melihat kontrak tidak bisa di-upgrade, tanpa sadar bahwa perilaku Agent sebenarnya diatur oleh file konfigurasi di luar chain. Pisahkan dulu keempatnya supaya setiap bagian di bawah punya objek pemeriksaan yang jelas.

Baris keempat adalah yang paling layak Anda pastikan lebih dulu bisa dijalankan sendiri, tetapi bukan jaminan tanpa syarat. Kalau private key sudah bocor, aset sudah tersimpan di protokol, atau penarikan sedang di-pause, mencabut allowance saja tidak cukup. Kalau Anda sudah menyambungkan sebuah Agent ke wallet sendiri, cara menghitung jalur pencabutan dan kerugian maksimum sudah dibahas lengkap di Izin wallet untuk AI Agent: batas kerugian dan kontrol, jadi tidak diulang di sini.

Isi tiap baris tabel dengan alamat kontrak, alamat multisig, atau peran di tim. Baris yang pengendalinya belum jelas cukup ditandai "pengendali belum ditemukan" dulu, lalu dilengkapi lewat pemeriksaan di bagian berikutnya.

Apakah kontrak ini bisa diganti? Baca dulu proxy dan hak upgrade-nya

Mulailah dari alamat yang benar-benar dipakai pengguna, lalu telusuri ke bawah: proxy, implementasi, dan peran yang berwenang. Menyalin satu alamat owner saja belum cukup untuk memastikan siapa yang bisa melakukan upgrade.

Pola proxy menyimpan state di alamat proxy, sementara logika eksekusinya ada di kontrak implementasi terpisah. ERC-1967 menetapkan slot penyimpanan untuk implementation, beacon, dan admin (opsional) agar block explorer bisa mengenali proxy yang mengikuti standar ini. Standar itu tidak mengatur satu model hak upgrade yang sama untuk semua proxy. Tab Read as Proxy hanyalah pintu untuk membaca antarmuka implementasi; bisa atau tidaknya kontrak di-upgrade tetap harus dicek di kodenya.

1. Buka tab Contract untuk alamat yang benar-benar Anda gunakan di block explorer. Kalau ada Read as Proxy, catat alamat proxy dan implementasinya. Kalau tab itu tidak muncul, jangan langsung menyimpulkan kontraknya tidak bisa di-upgrade. Di bawah ini ada tangkapan layar halaman publik standarnya, yang menjelaskan bagaimana explorer mengenali proxy.
2. Kenali jenis proxy-nya. Pada pola Transparent, telusuri ProxyAdmin dan siapa yang mengendalikannya. Pada UUPS, telusuri fungsi upgrade yang dijalankan lewat proxy dan izin di _authorizeUpgrade. Pada pola Beacon, telusuri juga siapa yang bisa meng-upgrade beacon. Kalau izinnya diatur lewat peran atau kontrak lain, kejar terus sampai ke alamat yang benar-benar bisa mengeksekusi; jangan berhenti hanya karena admin terlihat nol.
3. Cari event seperti Upgraded, AdminChanged, atau BeaconUpgraded, lalu cocokkan dengan jalur upgrade di kode sumber dan pengumuman sebelumnya. Catat nomor blok dan tanggal pemeriksaan, serta hash transaksi historis yang Anda temukan. Sekadar membaca sebuah field tidak menghasilkan hash transaksi.

Ada dua salah baca yang sering muncul di sini. Pertama, label "kode sumber terverifikasi" tidak berarti kontrak tidak bisa di-upgrade; verifikasi hanya membuktikan kode yang dipublikasikan cocok dengan bytecode di chain. Kedua, owner bernilai nol saat dibaca langsung di alamat implementasi tidak berarti state yang dipakai proxy juga begitu. Di UUPS, owner atau peran tertentu bisa langsung mengendalikan upgrade, jadi cek sesuai pola yang dipakai, jangan dipukul rata bahwa keduanya tidak berhubungan.

Catatan pemeriksaan minimal harus bisa ditelusuri ulang lewat jalur ini: alamat proxy → implementation atau beacon → fungsi upgrade → peran yang berwenang. Sertakan blok dan tanggal pemeriksaan, serta transaksi upgrade kalau ada. Bagian mana pun yang tidak terbaca, hentikan kesimpulan Anda di bagian itu.

Berapa kunci yang dibutuhkan, dan siapa pemegangnya

Ambang "sekian dari sekian" hanya bentuknya. Yang menentukan adalah apakah para penanda tangan itu benar-benar independen satu sama lain.

Ambil contoh rekaan: sembilan penanda tangan, lima tanda tangan sudah cukup. Ambang ini membatasi satu kunci, tetapi tidak membuktikan lima tanda tangan itu dikendalikan lima orang berbeda. Alamat yang dibuat di hari yang sama atau didanai dari sumber yang sama hanyalah petunjuk untuk ditelusuri, bukan bukti bahwa semua kunci milik satu orang. Saya memisahkan catatan aktivitas alamat dari pengungkapan identitas, lalu memeriksa apakah perangkat, penyimpanan, dan organisasinya independen. Kalau bahannya tidak cukup, kesimpulannya tetap "independensi belum terbukti".

Nilai timelock juga bergantung pada detail implementasinya. Timelock yang efektif memasukkan upgrade ke antrean dan baru bisa dieksekusi setelah jeda minimum. Jeda itu mungkin memberi waktu bereaksi, tetapi potong dulu dengan waktu untuk menyadari kejadiannya, mengirim transaksi, dan menunggu konfirmasi. Kalau penarikan di-pause atau ada masa kunci, tetap tidak ada jaminan Anda sempat keluar. Yang perlu dicek: berapa jeda minimum yang disetel, apakah event penjadwalan bisa dipantau publik, dan apakah masih ada jalur darurat yang melewati jeda. Selama jalur darurat itu ada, angka jeda di pengumuman bukanlah skenario terburuk.

Untuk multisig, simpan ambang m/n, petunjuk aktivitas tiap alamat, dan bukti identitas. Misalnya pada Safe, cek juga apakah ada module aktif yang bisa mengeksekusi transaksi lewat jalur otorisasi lain. Catatan soal jeda dibuat terpisah: jeda minimum dalam detik, peran yang mungkin bisa melewati jeda, dan langkah keluar yang benar-benar Anda butuhkan. Dua catatan ini menjawab pertanyaan berbeda, jadi jangan dilebur menjadi satu skor "tingkat desentralisasi".

Tombol pause melindungi siapa?

Pause biasanya dipakai agar protokol tidak terus bocor saat insiden. Itu tidak otomatis melindungi hak Anda untuk menarik dana.

Ambil contoh OpenZeppelin Pausable: fungsi yang diberi modifier whenNotPaused akan tertahan saat kontrak di-pause, sedangkan whenPaused justru hanya bisa dipanggil setelah pause. Sekadar mewarisi modul ini tidak membuat semua fungsi otomatis ikut berhenti. Anda perlu menemukan pengecekan yang sebenarnya di fungsi penarikan dan keluar darurat. Kalau penarikan biasa ikut tertahan, cek apakah masih ada cara keluar lain. Desain seperti ini bisa masuk akal saat insiden, tetapi Anda harus tahu sebelumnya, bukan baru sadar ketika dana sudah tertahan.

Sebelum menaruh dana, ada tiga pertanyaan yang layak diajukan: fungsi apa yang masih bisa dipanggil setelah pause, siapa yang berhak melakukan pause dan membukanya lagi, dan apakah ada batas waktu pause dibuka otomatis. Ketiganya harus dijawab dengan kontrak dan dokumentasi, bukan janji lisan tim. Proyek tanpa mekanisme pause juga tidak otomatis mendapat nilai plus. Cek apakah ada penanganan lain seperti pencabutan izin, batas nilai, atau mematikan fitur tertentu; "tidak ada pause" tidak sama dengan "tidak ada rencana insiden".

Daftarkan fungsi penarikan biasa, keluar darurat, pause, dan unpause satu per satu, lengkap dengan peran pengendali dan lokasinya di kode sumber. Kalau Anda menemukan event pause di masa lalu, tambahkan waktu mulai dan berakhirnya. Tidak menemukan event bukan bukti bahwa kontrak tidak pernah di-pause.

Titik mati di luar chain: model, RPC, server, dan akun

Kontraknya bisa saja tetap berjalan normal, sementara layanan yang menjalankan Agent justru mati. Saat memeriksa ketergantungan off-chain, pertanyaan pertama saya: kalau satu layanan gagal, apakah Agent berhenti, mengantre lalu mencoba lagi, atau pindah ke model atau node lain?

Agent bisa bergantung pada API model, RPC eksternal, server eksekusi, dan akun media sosial yang dipakai sebagai pintu masuk perintah. Bisa juga semuanya di-host sendiri atau punya cadangan. Apakah kegagalan satu layanan memengaruhi eksekusi tergantung pada mekanisme retry dan failover-nya. Transaksi yang terputus, gagal, atau perilaku yang berubah mungkin meninggalkan jejak di chain, tetapi dari riwayat transaksi saja biasanya tidak bisa dipastikan layanan off-chain mana yang bermasalah.

Cara memeriksa lapisan ini berbeda dari on-chain. Bahan yang bisa dipakai: penjelasan arsitektur dari proyek, halaman status, pengumuman insiden, dan riwayat gangguan. Kalau bahan-bahan itu tidak ada, itu sendiri sudah kesimpulan: lapisan ini tidak bisa Anda nilai. Soal apakah tindakan on-chain Agent benar-benar diputuskan oleh model, itu pertanyaan lain yang dibahas di Cara memverifikasi tindakan on-chain sebuah AI Agent.

Lengkapi daftar ketergantungan ini dengan kemungkinan penggantian, penjelasan cadangan, serta catatan gangguan publik beserta tanggalnya. Penanganan gangguan yang tidak dijelaskan di dokumentasi tandai sebagai tidak bisa dinilai. Transaksi on-chain yang lancar bukan jaminan untuk lapisan ini.

Daftar cek kendali

Empat butir di bawah dipakai setelah data terkumpul, dicentang satu per satu. Tidak ada skor dan bukan saran investasi; tujuannya hanya memaksa Anda mencatat alamat, jeda, dan tanggal sebelum menarik kesimpulan. Kalau ingin menerjemahkan kerugian maksimum menjadi angka konkret, pakai Perencana izin dan kerugian maksimum; semua hitungannya berjalan di browser Anda sendiri.

Catat izin yang Anda temukan

Setelah semua baris terisi, Anda seharusnya bisa menjelaskan siapa yang bisa mengubah apa, paling cepat kapan perubahan itu berlaku, dan apakah langkah keluar Anda masih bisa dijalankan. Setiap keputusan soal dana tetap membawa risiko kerugian dari celah kontrak, likuiditas, dan salah operasi.

Kolom yang saya sarankan: item kendali, jenis pemegang, ambang, jeda berlaku, dampak ke Anda, tautan bukti, tanggal pemeriksaan. Satu baris untuk satu hal saja. Yang tidak ditemukan diisi "belum ditemukan", jangan dikosongkan, karena sel kosong gampang terbaca sebagai "tidak ada risiko" saat Anda membukanya lagi nanti.

Tulis juga kondisi yang bisa mengubah kesimpulan: hak upgrade pindah dari multisig ke satu alamat, jeda timelock diperpendek, cakupan pause meluas sampai ke penarikan, atau daftar penanda tangan berubah. Semua itu adalah event yang bisa dipantau atau dicek ulang secara berkala. Apakah janji tata kelola benar-benar bisa dieksekusi dibahas di berkas lain: Apakah holder menerima nilai nyata dari produk AI?

Simpan tanggal dan versi tabel setiap kali memeriksa. Lain kali, cukup perbarui baris yang terdampak begitu peran pengendali, jeda, atau syarat keluar berubah. Dengan begitu kelihatan kenapa kesimpulan sebelumnya tidak berlaku lagi.

Pertanyaan umum