Dari Kecerdasan ke Wewenang

Kecerdasan buatan kini berkembang melampaui sekadar menjawab pertanyaan dan menghasilkan konten. Sistem AI semakin mampu menafsirkan instruksi, menyusun rencana, memilih alat, dan menjalankan tugas tanpa arahan manusia secara terus-menerus.

Perbedaan itu penting.

Sistem AI yang merekomendasikan tindakan berbeda dari sistem yang diberi wewenang untuk melaksanakannya. Perbedaannya belum tentu terletak pada kecerdasan atau kecanggihannya, melainkan pada wewenang.

Sistem otonom tidak terbatas pada model bahasa besar mutakhir. Sistem ini mencakup sistem pembelajaran mesin khusus, robotika, kendaraan otonom, agen perangkat lunak, serta gabungan berbagai teknologi yang secara mandiri mengambil keputusan atau melakukan tindakan dalam kondisi operasi yang telah ditentukan.

Potensi manfaatnya sangat besar. Sistem ini dapat mendukung penemuan ilmiah, operasi industri, layanan kesehatan, pengembangan perangkat lunak, dan keamanan siber. Namun, sistem ini juga dapat menimbulkan dampak yang tidak diinginkan, mengungkap informasi sensitif, atau memulai tindakan di luar maksud operatornya.

Dalam Tantangan Keamanan dalam Perancangan Sistem Otonom, Mohammad Hamad dan Sebastian Steinhorst mengkaji tantangan keamanan yang mencakup respons insiden otonom, penilaian risiko, kontrol akses, keterpercayaan data, dan interaksi antarsistem otonom. Penelitian mereka, yang sebagian besar membahas sistem siberfisik, menunjukkan bahwa tantangan mengamankan tindakan mesin yang mandiri melampaui agen LLM saat ini.

Dampak otonomi yang lebih luas perlu dikaji secara serius, termasuk potensi bahaya fisik. Namun, bukti harus ditafsirkan dengan cermat. Misalnya, insiden yang melibatkan kendaraan otomatis tidak serta-merta dapat dikaitkan dengan mekanisme yang sama dengan yang memengaruhi agen keamanan siber otonom. Tingkat otonomi, kondisi operasi, keterlibatan manusia, dan bukti kausalitas merupakan faktor penting.

Demikian pula, bukti bahwa AI otonom dapat menimbulkan bahaya tidak membuktikan bahwa tata kelola pasti tertinggal. Kita juga tidak seharusnya berasumsi bahwa sistem otonom pada dasarnya sulit diamankan.

Pertanyaan utamanya bukan apakah AI mampu melakukan pekerjaan yang kompleks, melainkan apakah kerangka arsitektur, keamanan, dan organisasi yang mengatur sistem otonom dapat menetapkan batas yang tepat bagi wewenang yang didelegasikan serta menyediakan bukti yang dapat diverifikasi bahwa batas tersebut dipatuhi.

Keamanan siber menawarkan sudut pandang yang sangat berguna untuk menjawab pertanyaan ini karena para profesional keamanan telah menghabiskan waktu puluhan tahun menguji asumsi tentang kepercayaan, izin, akses, dan perilaku sistem.

Permainan Kucing-Kucingan dalam Kecepatan Mesin

Keamanan siber sejak lama digambarkan sebagai permainan kucing-kucingan.

Penyerang menemukan kelemahan, pihak bertahan menerapkan perlindungan, dan keduanya beradaptasi. Siklus ini berlanjut seiring perubahan teknologi, taktik, dan lingkungan operasi.

AI otonom belum tentu mengubah aturan mendasar permainan itu. AI otonom mungkin mengubah siapa—atau apa—yang terlibat, seberapa cepat mereka bertindak, dan seberapa banyak pekerjaan yang dapat berlangsung tanpa campur tangan manusia secara terus-menerus.

Sistem keamanan ofensif otonom dapat mengidentifikasi layanan yang terekspos, menyelidiki kerentanan, menyusun kemungkinan jalur serangan, dan menguji apakah jalur tersebut dapat dieksploitasi. Sistem defensif dapat menggunakan kemampuan serupa untuk menyelidiki ancaman, mengidentifikasi kelemahan, dan memvalidasi langkah perbaikan.

Potensi penggunaan ganda ini merupakan hal utama dalam memahami implikasi keamanan AI otonom.

Project Glasswing dari Anthropic merupakan contoh penemuan kerentanan yang dibantu AI. Dalam pembaruan riset Mei 2026, Anthropic melaporkan hasil penemuan kerentanan yang signifikan, seraya menekankan tantangan operasional dalam verifikasi, pengungkapan, dan penambalan.

Perbedaan itu penting. Menemukan kerentanan tidak sama dengan memastikan bahwa kerentanan tersebut dapat dieksploitasi, memperbaikinya, atau membuktikan bahwa sistem yang terdampak aman.

Temuan yang lebih banyak dapat meningkatkan visibilitas, tetapi sekaligus menambah beban bagi orang-orang dan proses yang bertanggung jawab untuk menanganinya.

Hasil akhirnya bagi keamanan bergantung pada apa yang terjadi selanjutnya.

Jika penyerang dan pihak bertahan dapat mengotomatiskan sebagian pekerjaan mereka, pertanyaan yang relevan bukan sekadar pihak mana yang memiliki model paling mumpuni. Yang perlu dipastikan ialah apakah pihak bertahan dapat mengubah temuan menjadi perbaikan yang efektif dan memverifikasi hasilnya secara independen.

Pengujian penetrasi tradisional tidak menjadi usang hanya karena AI mampu melakukan tugas ofensif. Cakupannya perlu diperluas agar mencakup sistem yang menafsirkan instruksi, menggunakan alat, menggabungkan izin, dan mengejar sasaran melalui beberapa tahapan.

Tujuannya tetap sama: menemukan kelemahan, memastikan signifikansinya, memperbaikinya, dan membuktikan bahwa perlindungan yang diterapkan berfungsi.

Celah Arsitektur: Titik Pertemuan Batas-Batas Keamanan

Salah satu risiko yang lebih terselubung dalam sistem otonom muncul ketika komponen-komponen yang masing-masing telah mendapat otorisasi berinteraksi dan menimbulkan dampak yang tidak diinginkan.

Saya menyebut titik-titik interaksi ini sebagai celah arsitektur.

Mari kita lihat contoh yang umum. Sebuah organisasi membatasi akses ke suatu berkas menggunakan izin NTFS. Layanan berbagi di cloud yang terpisah memungkinkan pengguna berwenang membagikan informasi tersebut ke pihak eksternal.

Setiap sistem mungkin beroperasi sesuai aturannya masing-masing. Namun, interaksi keduanya dapat mengakibatkan informasi dibagikan dengan cara yang melanggar batas keamanan yang dimaksudkan organisasi.

Ini adalah ilustrasi tentang kebijakan yang berpotensi saling bertentangan, bukan pernyataan bahwa produk berbagi berkas mana pun rentan.

Masalahnya mungkin bukan terletak pada cacat di salah satu kontrol secara terpisah. Bisa jadi, kebijakan keamanan yang dimaksudkan tidak ditegakkan di seluruh alur kerja.

Kondisi serupa dapat terjadi pada AI otonom saat model, aplikasi, identitas, alat, repositori, dan layanan eksternal saling terhubung.

Sebuah agen mungkin memiliki izin untuk membaca dokumen, membuat repositori, dan mengunggah berkas. Namun, itu tidak serta-merta berarti agen tersebut berwenang menggabungkan operasi-operasi itu dengan cara yang mengekspos informasi rahasia.

Penelitian memberikan alasan praktis untuk mengkaji interaksi-interaksi ini.

Dalam AgentDojo, para peneliti mengevaluasi serangan injeksi prompt terhadap agen AI yang menggunakan alat dalam 97 tugas realistis dan 629 kasus uji keamanan. Temuan mereka menunjukkan bahwa instruksi berbahaya yang disisipkan melalui keluaran alat yang tidak tepercaya dapat mengganggu sejumlah properti keamanan, meskipun serangan maupun agen tidak selalu berhasil.

Penelitian tersebut tidak memastikan seberapa sering serangan ini berhasil di lingkungan produksi. Namun, penelitian itu menunjukkan mengapa evaluasi terhadap respons model saja tidak cukup untuk memahami perilaku sistem yang terhubung dengan alat.

Risiko terkait terkadang disebut pencucian izin: suatu tindakan tampak sah karena dilakukan melalui alat atau perantara yang berwenang, meskipun perilaku gabungannya melanggar batas kewenangan yang dimaksudkan.

Ketika beberapa agen bekerja sama, hubungan di antara mereka memerlukan aturan eksplisit yang mengatur partisipasi, pertukaran informasi, dan tindakan yang diizinkan.

Tanggung jawab juga harus ditetapkan di seluruh arsitektur.

Penyedia model, operator platform, pengembang agen, dan organisasi yang menerapkannya mungkin mengendalikan bagian-bagian sistem yang berbeda. Model tanggung jawab bersama yang efektif mengidentifikasi siapa yang mengendalikan setiap batas, siapa yang dapat mengizinkan pengecualian, siapa yang memantau pelaksanaan, dan siapa yang merespons jika terjadi masalah.

Otonomi tidak menghapus tanggung jawab. Otonomi justru membuat pemahaman tentang letak tanggung jawab itu semakin penting.

Offensive Rigor: Menguji Hal-Hal yang Kita Yakini

Hal ini membawa kita pada konsep yang saya sebut Offensive Rigor.

Offensive Rigor adalah pendekatan disiplin terhadap pengujian adversarial, kajian kritis, dan validasi berbasis bukti yang menguji asumsi keamanan. Pendekatan ini menilai perilaku sistem dalam kondisi realistis, alih-alih hanya mengandalkan rancangan arsitektur, kontrol yang terdokumentasi, atau perlindungan yang dianggap tersedia.

Praktik-praktik yang mendasarinya sudah mapan. Pengujian penetrasi, pemodelan ancaman, pengujian tim merah, dan validasi keamanan telah lama digunakan untuk menguji asumsi pertahanan.

Offensive Rigor menyatukan praktik-praktik tersebut dengan satu pertanyaan utama:

Bukti apa yang menunjukkan bahwa batas keamanan yang dimaksudkan tetap terjaga?

Sebuah organisasi mungkin memiliki kebijakan yang membatasi informasi sensitif, model yang dikonfigurasi untuk menolak permintaan terlarang, dan agen yang beroperasi dengan izin terbatas.

Semua itu merupakan perlindungan yang berarti. Namun, keberadaannya saja tidak membuktikan secara mandiri bahwa seluruh sistem berperilaku aman dalam kondisi adversarial.

Model mungkin menolak instruksi berbahaya, sementara alat yang berwenang tetap memungkinkan tindakan yang tidak diinginkan. Sebuah kebijakan mungkin tampak benar, tetapi interaksi antarsistem dapat menciptakan jalur tak terduga untuk mengakalinya.

Terkadang saya menyebutnya ‘ilusi pagar pengaman’: mengira bahwa keberadaan pagar pengaman membuktikan sistem tidak mungkin melampaui batas yang hendak ditegakkannya.

Pagar pengaman berguna. Namun, efektivitasnya tetap perlu dibuktikan.

Bayangkan sebuah agen otonom yang diberi wewenang untuk menyelidiki dugaan kompromi sistem. Agen itu dapat mengambil log, memeriksa aktivitas pengguna, dan merekomendasikan langkah pembatasan.

Dalam uji keamanan yang telah diotorisasi, seorang penguji adversarial menyisipkan instruksi yang menyesatkan ke dalam informasi yang diperkirakan akan diproses oleh agen tersebut.

Pengujian tidak seharusnya berhenti pada penentuan apakah agen mengikuti instruksi tersebut.

Pengujian juga perlu memeriksa apakah agen mencoba melakukan tindakan tanpa izin, apakah kontrol independen mencegah tindakan itu dijalankan, apakah upaya tersebut dicatat, dan apakah sistem pulih sebagaimana mestinya.

Ketelitian Ofensif menghubungkan lima kegiatan:

1. Menetapkan asumsi: Mengidentifikasi properti keamanan yang diharapkan dapat ditegakkan oleh arsitektur.
2. Menguji asumsi: Menguji jalur serangan yang realistis, masukan yang dimanipulasi, dan kombinasi kemampuan yang sah.
3. Mengumpulkan bukti: Menentukan apa yang dicoba dilakukan sistem, apa yang dijalankan, dan kontrol mana yang berfungsi.
4. Memperbaiki kelemahan: Menangani model, alur kerja, izin, arsitektur, atau proses operasional yang menyebabkan kegagalan.
5. Memverifikasi perbaikan: Menguji ulang jalur serangan yang relevan dan memastikan properti keamanan yang dimaksud benar-benar ditegakkan.

Inilah perbedaan antara menguji respons model dan menguji keamanan sistem secara keseluruhan.

Hal ini juga mengharuskan kita memeriksa apa yang terjadi setelah akses awal diperoleh. Penyerang mungkin mencoba mengumpulkan kredensial, meningkatkan hak akses, mempertahankan akses, atau bergerak secara lateral dengan menyalahgunakan kemampuan yang sudah tersedia di dalam lingkungan.

Fakta bahwa suatu alat sah tidak berarti setiap penggunaannya juga sah.

Tujuan Ketelitian Ofensif bukanlah menganggap sistem otonom tidak aman, melainkan memastikan melalui pengujian di mana batas keamanan sistem tersebut tetap berfungsi.

Otonomi Bersyarat: Memisahkan Kecerdasan dari Wewenang

Salah satu pendekatan arsitektural adalah membedakan kemampuan yang dimiliki sistem AI dari tindakan yang diizinkan untuk dilakukannya.

Saya menyebut pendekatan ini otonomi bersyarat.

Otonomi bersyarat mengakui bahwa tingkat kemandirian yang tepat bergantung pada tugas, lingkungan operasi, potensi konsekuensi, ketidakpastian, dan bukti yang tersedia untuk membenarkan suatu tindakan.

Agen yang merangkum informasi publik belum tentu memerlukan pengawasan yang sama dengan agen yang berwenang menonaktifkan akun, mengubah aturan firewall, atau memodifikasi infrastruktur produksi.

Agen yang disebut terakhir mungkin memerlukan aturan pelaksanaan yang tegas, izin yang ditegakkan secara independen, otorisasi yang lebih kuat, dan persetujuan manusia untuk tindakan yang berdampak besar.

Batasan ini tidak seharusnya diperluas hanya karena agen memutuskan bahwa akses yang lebih luas akan membantu mencapai tujuannya.

Agen dapat mempertimbangkan kembali cara melaksanakan tugas yang diizinkan tanpa memperoleh wewenang tambahan.

10 Ancaman Teratas OWASP untuk Aplikasi LLM membahas masalah ini melalui kategori LLM06:2025 Agensi Berlebihan. OWASP mengidentifikasi fungsionalitas, izin, dan otonomi yang berlebihan sebagai sumber risiko, serta merekomendasikan pembatasan kemampuan dan penegakan otorisasi secara independen.

Otonomi bersyarat menerapkan prinsip-prinsip ini sesuai dengan risiko operasional.

Akses informasi harus dibatasi pada hal-hal yang diperlukan untuk tugas. Izin alat harus dibatasi pada operasi yang disetujui. Anggaran tindakan, batas laju, persyaratan persetujuan, dan kondisi penghentian dapat membatasi pelaksanaan.

Perlindungan ini sangat penting dalam pengujian ofensif otonom.

Agen pengujian mungkin secara sah menemukan kredensial atau informasi sensitif saat menjalankan tujuan yang telah diizinkan. Namun, menemukan kredensial bukan berarti model perlu menerima nilainya dalam bentuk teks biasa.

Kerangka pengamanan dapat memisahkan kredensial sensitif dari model dan mengatur penggunaannya melalui otorisasi yang ditegakkan secara independen. Sebagai contoh, perantara kredensial dapat memberikan rahasia langsung kepada layanan yang disetujui tanpa memaparkannya kepada model secara tidak perlu.

Pendekatan ini menerapkan prinsip hak istimewa minimum dan pemisahan tugas yang sudah mapan.

Hal ini juga memunculkan pertanyaan menarik tentang arsitektur Bring Your Own Model (BYOM) atau Bring Your Own LLM (BYO-LLM).

Jika model yang mendasarinya diganti besok, jaminan keamanan apa yang tetap berlaku?

Otorisasi tugas, isolasi kredensial, pembatasan cakupan, pencatatan log, dan penegakan kebijakan dapat berada di dalam kerangka pendukung, alih-alih sepenuhnya bergantung pada perilaku model.

Namun, itu tidak berarti kerangka pendukung otomatis aman atau model-model dapat saling dipertukarkan. Model yang berbeda mungkin menafsirkan instruksi secara berbeda, memanggil alat dengan cara berbeda, dan menimbulkan jenis kegagalan yang berbeda.

Evaluasi yang bermakna harus menguji baik kontrol yang dimaksudkan agar tetap konsisten maupun perilaku yang berubah ketika model berganti.

Mungkin, beberapa properti keamanan yang paling tahan lama adalah properti yang tetap dapat ditegakkan secara independen sekalipun komponen kecerdasannya terus berkembang.

Ketika AI Bertindak terhadap AI: Masalah Verifikasi

Bayangkan alur kerja operasi keamanan berikut:

Selidiki insiden ini, kumpulkan bukti, identifikasi identitas yang terdampak, usulkan langkah penanganan, laksanakan tindakan yang disetujui, lalu verifikasi hasilnya.

Satu agen investigasi menganalisis telemetri. Agen lain merekomendasikan langkah pembatasan. Agen pelaksana yang berwenang melakukan perubahan. Agen verifikasi mengevaluasi hasilnya.

Ini menggambarkan respons insiden otonom dengan siklus tertutup, bukan kegagalan industri secara luas yang terdokumentasi.

Misalkan agen pertama keliru mengidentifikasi suatu identitas sebagai identitas yang telah disusupi. Agen kedua menerima kesimpulan itu dan menonaktifkan akun tersebut. Agen ketiga mengonfirmasi bahwa akun itu telah dinonaktifkan dan melaporkan keberhasilan.

Operasi yang dipilih telah selesai dilakukan.

Namun, apakah penetapan awal itu benar? Apakah tindakan tersebut diizinkan? Apakah pembatasan itu menangani ancaman yang sebenarnya? Apakah tindakan itu menimbulkan gangguan yang tidak perlu?

Verifikasi tidak cukup hanya dengan memastikan bahwa agen telah menyelesaikan tindakan yang dipilihnya.

Menugaskan verifikasi kepada agen AI lain juga tidak serta-merta membuat hasilnya independen.

Agen yang berbeda mungkin mengandalkan telemetri yang sama-sama tidak akurat, informasi yang telah disusupi, atau asumsi yang keliru. Kesepakatan mereka tidak secara independen membuktikan fakta yang mendasarinya.

Semakin besar konsekuensi suatu tindakan otonom, semakin kuat kebutuhan akan verifikasi yang independen dari sistem yang mengambil keputusan.

Independensi itu dapat diwujudkan melalui bukti yang bersumber secara terpisah, pemeriksaan kebijakan deterministik, lingkungan eksekusi yang dibatasi, peninjauan manusia, atau kombinasi berbagai pengamanan.

Pengendalian yang tepat harus sebanding dengan konsekuensi kesalahan.

Tindakan berdampak rendah yang dapat dibatalkan mungkin cocok diverifikasi secara otomatis. Tindakan berdampak tinggi atau sulit dibatalkan mungkin memerlukan otorisasi yang lebih ketat, konfirmasi independen, dan persetujuan tegas dari manusia.

Empat pertanyaan berikut membantu membedakan aspek keamanan yang relevan:

• Apakah sistem menafsirkan tugas yang dimaksud dengan benar?
• Apakah tindakan tersebut berada dalam batas kewenangan yang didelegasikan kepadanya?
• Apakah pelaksanaan tetap berada dalam batas yang diizinkan?
• Apakah hasil akhirnya memenuhi tujuan keamanan yang dimaksud?

Pertanyaan-pertanyaan ini saling berkaitan, tetapi tidak dapat dipertukarkan.

Agen dapat melakukan tindakan yang diizinkan tetapi menghasilkan dampak yang tidak diinginkan. Agen juga dapat menghasilkan dampak yang tampaknya bermanfaat melalui tindakan yang tidak diizinkan.

Keduanya tidak boleh serta-merta dianggap sebagai keberhasilan dalam hal keamanan.

Seiring meningkatnya kemampuan sistem otonom, tantangannya bukan sekadar memungkinkan sistem menyelesaikan alur kerja yang kompleks. Tantangannya adalah memperoleh bukti yang memadai bahwa tindakannya tetap diizinkan, tepat, dan benar.

Ini juga mencakup kemampuan mengetahui kapan harus berhenti, melakukan eskalasi, membatalkan suatu tindakan, atau menerima risiko terbatas yang dipahami secara jelas.

Kepercayaan Harus Berlandaskan Bukti

Dampak keamanan AI otonom tidak semata-mata negatif.

Sistem otonom dapat membantu tim pertahanan menemukan kelemahan, menyelidiki ancaman, dan melakukan pekerjaan validasi yang jika tidak, akan menyita banyak waktu dan tenaga manusia.

Model yang lebih baik, pengendalian eksternal yang lebih kuat, dan praktik operasional yang lebih matang dapat mengurangi sebagian risiko yang terkait dengan pendelegasian kewenangan.

Karena itu, terlalu dini untuk menyimpulkan bahwa AI otonom pada dasarnya tidak aman atau bahwa tata kelola tidak dapat mengimbangi perkembangannya.

Ada pula argumen tandingan yang serius terhadap anggapan bahwa AI otonom memerlukan prinsip keamanan yang benar-benar baru.

Banyak masalah mendasar—hak istimewa yang berlebihan, masukan yang tidak tepercaya, otorisasi yang lemah, penerapan kebijakan yang tidak konsisten, dan verifikasi yang tidak memadai—telah dikaji selama puluhan tahun.

Pengendalian yang sudah mapan mungkin telah menyediakan solusi yang dapat diterapkan, asalkan diterapkan dan diuji dengan benar.

Otonomi dapat mengubah kecepatan, skala, dan kompleksitas penerapannya. Namun, otonomi tidak serta-merta membuat pengendalian tersebut tidak lagi berlaku.

Bukti mengarah pada pertanyaan yang lebih bermanfaat: dalam kondisi apa sistem otonom dapat dipercaya untuk menjalankan kewenangan yang didelegasikan, dan bagaimana kita membuktikan bahwa kondisi tersebut terpenuhi?

Jawabannya tidak hanya bergantung pada kemampuan model.

Jawabannya membutuhkan batasan arsitektural, tanggung jawab yang ditetapkan dengan jelas, otorisasi yang ditegakkan secara independen, pengawasan yang sesuai, serta bukti bahwa pengamanan berfungsi dalam kondisi yang realistis.

Jawabannya juga memerlukan pandangan yang konsisten tetapi terus berkembang tentang keamanan dan risiko.

Prinsip-prinsip keamanan mendasar kita tidak perlu berubah setiap kali model baru hadir. Namun, asumsi kita tentang penerapan prinsip-prinsip tersebut harus terus diuji seiring berkembangnya kemampuan, lingkungan operasional, dan kewenangan yang didelegasikan.

Inilah tujuan pendekatan Offensive Rigor.

Bukan untuk membuktikan bahwa sistem AI akan gagal, melainkan untuk menemukan titik kegagalannya, menetapkan konsekuensinya, dan memvalidasi kontrol yang dimaksudkan untuk mencegah atau membatasi kegagalan tersebut.

Mungkin, keunggulan yang lebih bertahan lama bukan sekadar memilih model yang lebih mumpuni, melainkan membangun arsitektur yang memungkinkan model berganti tanpa mengorbankan batas-batas kepercayaan, kewenangan, dan verifikasi.

Permainan kucing-kucingan terus berlanjut. Semakin lama, kedua belah pihak mungkin memiliki pemain otonom.

Disiplin yang penting adalah memastikan kemampuan kita untuk menemukan kelemahan, memperbaikinya, dan membuktikan hasilnya tidak hilang dalam perlombaan untuk mengotomatiskan segala hal lainnya.

Kepercayaan harus berlandaskan bukti.

Catatan penulis: Pandangan dan penafsiran yang disampaikan dalam artikel ini merupakan pandangan dan penafsiran saya sendiri dan belum tentu mencerminkan posisi resmi, kebijakan, atau kemampuan produk perusahaan tempat saya bekerja.