Cara Menghentikan "Tiga Ancaman Mematikan" AI

• LLM memiliki masalah struktural karena tidak mampu memisahkan kode dan data, sehingga rentan terhadap serangan prompt injection
• Terutama ketika akses ke data eksternal, kemampuan membaca rahasia internal, dan izin berkomunikasi ke luar diberikan secara bersamaan, akan muncul apa yang disebut lethal trifecta (tiga ancaman mematikan) yang dapat menyebabkan kerusakan serius
• Para engineer AI perlu berpikir seperti insinyur mesin; alih-alih pendekatan deterministik, mereka harus menerima ketidakpastian sistem probabilistik dan menyediakan margin keselamatan
• Seperti para insinyur era Victoria yang menambahkan cadangan lewat desain berlebih untuk mengantisipasi ketidakpastian material, sistem AI juga perlu menerapkan batas keselamatan, toleransi risiko, dan tingkat kesalahan
• Seperti jembatan di dunia fisik memiliki batas beban, kini sudah saatnya sistem AI juga memiliki norma yang menetapkan batas eksplisit dan margin keselamatan

---

Masalah Keamanan Intrinsik LLM

• Model bahasa besar memiliki cacat struktural karena tidak dapat memisahkan kode dan data
• Akibatnya, model ini rentan terhadap serangan prompt injection
  • Menipu sistem agar mengikuti perintah yang seharusnya tidak diikuti
  • Dalam beberapa kasus, hasilnya hanya memalukan, misalnya membuat agen dukungan pelanggan berbicara seperti bajak laut
  • Dalam kasus lain, dampaknya bisa jauh lebih merusak

Lethal Trifecta (Tiga Ancaman Mematikan)

• Dampak terburuk muncul ketika tercipta "tiga elemen mematikan"
• Tiga elemen tersebut terdiri dari
  • Hak akses ke data yang tidak tepercaya
  • Kemampuan membaca informasi rahasia yang penting
  • Kemampuan untuk berkomunikasi dengan dunia luar
• Ketika perusahaan ingin memberi karyawan asisten AI yang kuat lalu memberikan ketiganya sekaligus, masalah serius hampir tak terelakkan
• Bukan hanya engineer AI, pengguna umum juga perlu belajar cara menggunakan AI dengan aman
  • Kombinasi aplikasi yang salah dapat secara tidak sengaja menciptakan tiga elemen tersebut

Perlunya Perubahan Pola Pikir Engineer AI

Berpikir Seperti Insinyur Mesin

• Rekayasa AI yang lebih baik adalah garis pertahanan pertama
• Para engineer AI harus berpikir seperti insinyur yang membangun struktur seperti jembatan
  • Menyadari bahwa pekerjaan yang buruk dapat merenggut nyawa

Pelajaran dari Rekayasa Era Victoria

• Bangunan-bangunan besar Inggris pada era Victoria dibangun oleh para insinyur yang tidak bisa sepenuhnya yakin akan karakteristik material
  • Pada masa itu, besi sering berkualitas buruk karena inkompetensi atau kecurangan
  • Karena itu para insinyur memilih berhati-hati dan mengintegrasikan redundansi lewat desain berlebih
  • Hasilnya adalah mahakarya yang bertahan selama berabad-abad

Masalah Industri Keamanan AI Saat Ini

• Penyedia keamanan AI tidak berpikir dengan cara seperti itu
• Pemrograman konvensional bersifat deterministik
  • Kerentanan keamanan dianggap sebagai bug yang harus diperbaiki
  • Setelah diperbaiki, bug itu dianggap hilang
• Para engineer AI sudah terbiasa dengan pola pikir ini sejak masa sekolah
  • Karena itu mereka bertindak seolah masalah bisa diselesaikan hanya dengan lebih banyak data pelatihan dan system prompt yang lebih cerdas

Pendekatan yang Sesuai untuk Sistem Probabilistik

Batasan Data Pelatihan dan Prompt

• Data pelatihan dan prompt yang cerdas memang dapat mengurangi risiko
  • Model terbaru yang paling cerdas lebih unggul daripada model lama atau model kecil dalam mendeteksi dan menolak permintaan jahat
• Namun, risiko tidak dapat dihilangkan sepenuhnya
  • Berbeda dari sebagian besar perangkat lunak, LLM bersifat probabilistik
  • Output ditentukan oleh pemilihan acak di antara respons-respons yang mungkin
  • Karena itu, pendekatan keamanan yang deterministik menjadi tidak memadai

Meniru Rekayasa di Dunia Fisik

• Cara yang lebih baik adalah meniru para insinyur di dunia fisik
• Belajar bekerja bersama sistem yang tidak dapat diprediksi
  • Bukan melawan sistem yang berubah-ubah dan tak bisa dijamin selalu bekerja sesuai niat, melainkan bekerja bersamanya
• Menghadapi ketidakpastian dengan lebih nyaman melalui margin keselamatan, toleransi risiko, dan tingkat kesalahan

Strategi Desain Berlebih di Era AI

• Menggunakan model yang lebih kuat daripada yang sebenarnya diperlukan
  • Mengurangi risiko model ditipu agar berperilaku tidak semestinya
• Menerapkan batas jumlah kueri yang dapat diterima LLM dari sumber eksternal
  • Disesuaikan dengan tingkat risiko kerusakan akibat kueri jahat
• Menekankan safe failure
  • Jika sistem AI harus mengakses rahasia, hindari memberikan kunci kerajaan begitu saja

Perlunya Menetapkan Batas Keselamatan

• Di dunia fisik, jembatan memiliki batas beban
  • Meski tidak selalu ditampilkan dengan jelas kepada pengemudi, batas itu tetap ada
  • Poin pentingnya: batas tersebut menyisakan margin yang cukup besar dalam rentang toleransi nyata dibandingkan kapasitas yang secara perhitungan diperkirakan mampu ditahan jembatan
• Kini sudah waktunya dunia virtual sistem AI memiliki hal serupa
• Merancang sistem dengan batas keselamatan yang jelas dan margin cadangan adalah hal yang esensial

[GN⁺]

Opini Hacker News

• Tautan artikel arsip
• Ini adalah artikel Economist kedua minggu ini yang menyebut lethal trifecta. Yang pertama adalah Sistem AI tidak akan pernah sepenuhnya aman — ‘tiga serangkai mematikan’ yang harus dihadapi, dan menurut saya itu menjelaskan dengan paling jelas apa itu prompt injection dan mengapa hal itu berbahaya. Saya memang sedikit bias karena ada bagian yang mengutip saya, tetapi ini benar-benar artikel yang saya rekomendasikan untuk para eksekutif. Artikel baru kali ini kurang saya sukai. Artikel itu menyebut bahwa karena LLM bersifat non-deterministik, celah keamanan sulit diperbaiki, lalu memakai analogi bahwa karena itu sistem harus di-‘overengineer’ seperti jembatan dan disiapkan toleransinya. Untuk jembatan mungkin masuk akal, tetapi untuk celah keamanan saya rasa itu bukan solusi mendasar. Jika sebuah sistem hanya gagal terhadap prompt injection 1 dari 100 kali pun, penyerang akan terus mencoba varian serangan sampai berhasil. Jika salah satu saja dari lethal trifecta (akses ke data privat, paparan terhadap instruksi tak tepercaya, jalur eksfiltrasi ke luar) diblokir, serangan tidak bisa berhasil
  • Pembangun jembatan pada umumnya tidak mendesain dengan asumsi adanya serangan yang bersifat adversarial. Kalaupun iya, fokusnya biasanya pada kemudahan pemindahan dan redeployment cepat, bukan sekadar membuatnya sekuat mungkin. Daripada satu jembatan superkokoh yang tetap berdiri setelah dibom, sering kali lebih cepat dan murah memasang satu jembatan sementara lagi. Lihat contoh konkret
  • LLM, seperti manusia, bersifat non-deterministik. Jadi pengelolaan keamanannya pun bisa didekati seperti manusia. Berikan hanya hak minimum yang diperlukan lewat role-based access control, dan pastikan pekerjaan yang berisiko atau mahal harus melalui proses persetujuan. Untuk organisasi penting di bidang teknologi, infrastruktur, pertahanan, keuangan, dan sebagainya, merupakan hal dasar untuk membuat model ancaman dengan asumsi bahwa agen pemerintah asing dari Rusia, Tiongkok, Israel, Korea Utara, dan lain-lain mungkin sudah menyusup ke dalam tim
  • Sebenarnya kedua artikel itu adalah artikel yang sama. Di Economist, ada seri artikel “Leaders” di bagian depan setiap edisi mingguan yang merangkum atau menggeneralisasi artikel-artikel mendalam dalam edisi yang sama. Artinya, mereka pada dasarnya menerapkan struktur piramida terbalik ke seluruh surat kabar (penjelasan piramida terbalik). Jadi artikel yang ditautkan kali ini berfungsi seperti versi ringkas dari keseluruhan artikel utama tentang masalah tersebut
  • Saya memikirkan masalah keamanan LLM sebagai “bagaimana jika kode saya bisa ditembus lewat social engineering?” LLM, seperti manusia, pada akhirnya bisa ditipu tak peduli seberapa banyak dilatih. Jika Anda memberi komputer hak root lalu mengizinkan siapa pun di seluruh dunia berbicara dengan LLM tersebut, sistem itu pada akhirnya pasti akan rentan. Sama seperti kita tidak mendelegasikan hak tak terbatas kepada manusia, kita juga seharusnya tidak mengizinkan LLM mengakses data yang tidak terkait dengan peminta, atau mengubah data pengguna
  • Masalahnya adalah cukup memotong satu sisi dari lethal trifecta. Tiga elemen ini sebenarnya saling terkait. Misalnya, konten eksternal seperti email juga bisa merupakan informasi pribadi, dan bila email dikirim, isi inbox saya bisa bocor ke penyerang. Selain itu, email, GitHub, dan sebagainya paling berguna ketika keduanya bisa menerima dan mengirim. Menyediakan server terpisah khusus untuk tiap fungsi jadi tidak efisien
• Dari sudut pandang teknik mesin, saya merasa artikel ini tidak memadai. Orang sering bilang “tinggal tambah strength”, tetapi dalam praktiknya itu hanya bisa diterapkan setelah memahami berbagai mode kegagalan secara sangat rinci. lethal trifecta hanyalah salah satu mode kegagalan, lalu kita menambahkan “strength” untuk mencegahnya. Ini bukan soal “jembatan ini terlalu bergetar → mari pikirkan cara aman menyeberangi jembatan yang bergetar”, melainkan mengubah jembatan itu agar sejak awal tidak bergetar berlebihan
  • Rasanya dunia sudah gila. Jika mengikuti analogi jembatan itu, kita seperti sudah lama tahu cara membangun jembatan, tetapi kadang-kadang lantainya tiba-tiba menghilang dan orang-orang jatuh ke sungai, lalu alih-alih membahas “mari cari pendekatan lain”, kita justru berkata “pasang jaring di bawahnya, lalu tangkap kalau semua jatuh”. Kita sedang membakar miliaran di atas teknologi yang secara inheren tidak dapat diprediksi, lalu hanya menambah guardrail. Benar-benar tidak masuk akal
  • Begitu saya melihat frasa ‘coders need to’ di artikel, saya langsung kehilangan minat. Analoginya sendiri terasa salah, dan bahkan bagi orang yang berpengalaman di bidang aslinya terdengar janggal. Skenario contoh wartawan itu sendiri bermasalah: “jika perusahaan membiarkan LLM sekaligus mengakses data tak tepercaya, informasi penting, dan komunikasi dengan pihak luar.” Sering kali perusahaan menciptakan risiko itu sendiri karena memprioritaskan fungsi di atas keamanan. Klaim bahwa “karena LLM non-probabilistik, pendekatan deterministik jadi tidak cocok” terasa seperti lompatan logika. Walaupun non-deterministik, logika sandbox tetap valid. Dengan kata lain, jika analogi itu dipaksakan terlalu jauh, justru kurang membantu bagi bidang terkait. Akan lebih baik memakai istilah yang tepat dan pengetahuan domain yang relevan, walaupun itu mungkin membuat artikelnya kurang menarik
• Jangan-jangan artikel itu benar-benar hanya mengatakan bahwa solusi yang diperlukan hanyalah pembatasan laju dan model yang lebih baik? Insinyur perangkat lunak sudah meneliti hal seperti ini sejak puluhan tahun lalu. Industri ini sebenarnya tahu jawabannya untuk keamanan, masalahnya hanya karena hal itu tidak cocok dengan sikap sekarang yang terburu-buru meluncurkan produk AI
  • AI sekarang juga bagian dari ranah IT yang sama, jadi kalau begitu kesimpulannya adalah “kita sebenarnya belum memahami keamanan”. Mengatakan AI ceroboh tidak tepat. Fakta bahwa kita tidak punya cara untuk memisahkan data dan token instruksi secara sempurna adalah keterbatasan mendasar, bukan akibat kecerobohan. Mengklaim “semua ini sudah diketahui puluhan tahun lalu” itu arogan
  • Ucapan seperti “kita sudah menyelesaikan keamanan puluhan tahun lalu” adalah gejala ketika industri baru terburu-buru membangun ulang standar lama yang buruk untuk meluncurkan “produk AI”. Cukup lihat saja kasus seperti standar MCP yang sejak awal sudah berlubang; pendekatan seperti “tulis prompt yang bagus” jadi terasa nyaris konyol. Masalah terbesarnya adalah hampir semua orang di industri AI tampaknya merancang server MCP yang terhubung langsung ke DB tanpa banyak mempertanyakannya. Ini menunjukkan bahwa hanya karena sesuatu bisa dilakukan bukan berarti harus dilakukan. Karena keamanan yang serampangan seperti ini, banyak produk AI benar-benar sudah dikompromikan
  • Klaim “kita sudah paham keamanan” sebenarnya juga tidak benar. Apalagi ketika masuk ke ranah manusia, keadaannya malah lebih buruk; bahkan setelah menghabiskan miliaran untuk pelatihan berulang, efektivitasnya terus menurun. Belakangan ini pun ada kasus seorang pakar keamanan hebat tertipu phishing sederhana di YouTube
• Tulisan asli dari @simonw: The lethal trifecta for AI agents, dan bisa juga melihat tulisan tambahan terkait. Saya juga meninggalkan tautan ke diskusi terkait di HN
• lethal trifecta adalah masalah yang muncul ketika LLM sekaligus memiliki akses ke data tak tepercaya, dapat melihat informasi penting, dan bisa berkomunikasi ke luar. Solusinya adalah menurunkan risiko lewat pengelolaan batasan (izin), yang pada dasarnya hanya keamanan 101
  • Betul, tetapi dalam praktiknya ada ketegangan besar antara keamanan dan fungsionalitas. Jika ingin melakukan hal yang berguna dengan data pribadi, celah prompt injection jadi terbuka. Selain itu, menggabungkan konteks yang saling terkait sebanyak mungkin memang efektif untuk efisiensi agen, tetapi jika agen yang membaca input tak tepercaya benar-benar dipisah/diisolasi, utilitasnya justru turun. Lihat blog terkait
  • Ini pun secara ketat sebenarnya hanya access control dasar. Begitu terhubung ke internet, risikonya melonjak. Jika ada peneliti keamanan yang sangat andal, hanya dengan satu prompt injection saja mereka bisa mengambil alih seluruh sistem, sehingga setidaknya satu dari syarat tersebut langsung terpenuhi
• LLM tidak membedakan antara prompt dan data. Tidak ada konsep seperti NX bit (non-executable bit), dan tidak ada contoh implementasi sesuatu yang mirip. Tentu saja, sebagaimana NX bit pun tidak pernah sepenuhnya menghentikan remote code execution, ini sendiri juga bukan jawaban sempurna. Cara paling realistis saat ini adalah mengelola proses agen LLM dengan mekanisme keamanan yang sudah ada. Misalnya, jalankan dengan akun pengguna terpisah untuk membatasi akses file, lalu tambahkan pembatasan lewat jaringan, perangkat keras, dan cgroups. Meski begitu, jika instruksi bercampur dalam data tak tepercaya, tetap ada risiko bahwa LLM akan membocorkan data rahasia. Dan jika pengguna tanpa sadar menyalin keluaran LLM ke luar, jalur eksfiltrasi pun terbuka lagi
  • Anda bilang belum ada yang menciptakan sesuatu yang mirip ini, tetapi saya penasaran apakah benar ada orang yang bahkan pernah mencoba, atau apakah ada data pelatihan terkait. Hewan sosial secara alami melakukan compartmentalization. Anjing pun bisa membaca situasi manusia dan menyembunyikan keberadaan makanan. Saya sendiri saat membesarkan anak memisahkan dan mengelola informasi secara berbeda antara kehidupan sosial, pengetahuan rahasia, privasi anak, informasi yang masih sulit diterima anak, isi hati saya, serta hal-hal yang dipelajari dari sumber yang tidak tepercaya. Kecerdasan itu penting, tetapi kebijaksanaan masih belum menjadi pertimbangan kelas satu di ranah LLM. Bahkan anak anjing dan balita pun saat ini lebih unggul dalam kemampuan compartmentalization
• Saya menemukan kutipan menarik di artikel mendalam terkait: sistem CaMeL yang diusulkan Google menggunakan dua LLM untuk menghindari sebagian risiko lethal trifecta. Satu hanya boleh mengakses data tak tepercaya, dan yang lain menangani semua data lainnya. Model yang lebih tepercaya menerjemahkan instruksi bahasa pengguna menjadi kode dengan ruang lingkup terbatas, dan model tak tepercaya mengisi bagian kosong dalam kode itu. Struktur ini memberi jaminan keamanan, tetapi sebagai gantinya sangat membatasi cakupan pekerjaan yang bisa dilakukan LLM. Saya baru pertama kali mendengarnya dan penasaran seberapa efektif ini dalam praktik. Apakah benar memberi keamanan yang “absolut”, batasan apa yang ditimbulkannya, dan apakah ini bisa menjadi alternatif yang nyata. Sumber artikel
  • Saya sudah lama memikirkan paper CaMeL itu. Itu pendekatan yang cukup bagus, tetapi implementasi nyatanya sangat sulit dan sistemnya hanya bisa melakukan fungsi yang cukup terbatas. Saya merangkumnya di analisis saya
• Ada analogi bahwa “insinyur AI juga harus berpikir seperti insinyur sungguhan di bidang seperti pembangunan jembatan, tempat kegagalan bisa menimbulkan korban jiwa”. Maksudnya kira-kira “insinyur AI sejak sekolah dibiasakan berpikir bahwa cukup dengan lebih banyak data pelatihan dan prompt yang lebih pintar, masalah akan selesai”
  • Di sini, “insinyur AI harus berpikir seperti insinyur sungguhan” berarti bukan sekadar seperti software engineer, tetapi seperti engineer dalam arti sebenarnya; sekarang perangkat lunak sudah tertanam di jembatan dan mobil juga, jadi setidaknya pola pikir engineering untuk dunia fisik perlu dimiliki
  • Ini terdengar seperti menyiratkan usulan bahwa para software engineer harus punya lisensi profesional dan bahkan sertifikasi etika. Tetapi karena perangkat lunak yang tidak etis namun legal bisa menghasilkan keuntungan yang sangat besar, saya rasa ide seperti ini sulit benar-benar diterapkan
  • Kesimpulan dari gagasan “cukup punya data pelatihan yang lebih baik maka semuanya selesai” pada akhirnya adalah bahwa tragedi-tragedi seperti ini sendiri akan menjadi data pelatihan
  • Jangan lupa juga peran ‘arsitek’, bukan hanya ‘insinyur’ perangkat lunak
• Saya jadi berpikir mungkin ada peluang bisnis jika menjalankan produk perangkat lunak berbasis langganan dengan biaya tertentu yang secara otomatis memantau akun LLM dan memfilter/memproses input melalui pipeline