Paradoks keamanan LLM lokal

• Hasil penelitian menunjukkan bahwa pengembang yang menggunakan LLM di lingkungan lokal demi melindungi privasi justru bisa terekspos pada kerentanan keamanan
• Dalam eksperimen OpenAI Red‑Teaming Challenge terhadap model gpt-oss-20b, tim peneliti menemukan bahwa model lokal jauh lebih mudah tertipu oleh manipulasi prompt penyerang dan menghasilkan kode berbahaya
• Hanya dengan manipulasi prompt sederhana, penyerang dapat memicu penyisipan backdoor atau eksekusi kode langsung (RCE), dengan tingkat keberhasilan hingga 95%
• Serangan seperti ini dapat menyusup secara alami ke workflow umum pengembang melalui peracunan dokumentasi (documentation poisoning), manipulasi server MCP, rekayasa sosial, dan lain-lain
• Inti temuan penelitian ini adalah bahwa meski LLM lokal unggul dari sisi privasi data, ia justru bisa menjadi pilihan yang lebih berbahaya karena kurangnya kemampuan penalaran, alignment, dan pemfilteran keamanan

---

Gambaran umum kerentanan keamanan LLM lokal

• Penelitian ini menunjukkan bahwa LLM yang berjalan secara lokal kerap dianggap sebagai pilihan untuk memperkuat keamanan dan privasi, tetapi dalam praktiknya justru lebih mudah dimanipulasi oleh penyerang
  • Dalam eksperimen terhadap model gpt-oss-20b, tingkat model menghasilkan kode yang mengandung kerentanan ketika penyerang memintanya melalui prompt sangat tinggi
  • Terutama ketika niat jahat disembunyikan di dalam prompt, model gagal mengenalinya dan memprosesnya sebagai permintaan yang normal
• Fenomena ini makin parah ketika ukuran model dan tingkat alignment lebih rendah, sedangkan model frontier (seperti GPT-5) relatif lebih tahan

Ancaman prompt dan code injection

• LLM menghadapi ‘lethal trifecta’ berupa akses ke data privat, paparan terhadap konten yang tidak tepercaya, dan kemungkinan komunikasi eksternal
  • Penyerang dapat menyisipkan kode berbahaya ke dalam prompt untuk memicu code injection
  • Kode yang dihasilkan tampak normal, tetapi sebenarnya bisa menginfeksi sistem pengembang atau berfungsi sebagai backdoor persisten di lingkungan produksi
• Model kecil seperti gpt-oss-20b sangat rentan terhadap serangan ini, dan mampu menghasilkan kode berbahaya yang cukup canggih untuk lolos code review dasar

Tipe serangan 1: backdoor “easter egg” (tingkat keberhasilan 95%)

• Serangan pertama menipu model agar menyisipkan backdoor RCE (Remote Code Execution) yang disamarkan sebagai fitur “easter egg”
  • Prompt serangan meminta pembuatan server web Flask, tetapi agar ketika header HTTP tertentu (X-Math) dikirim, eval() dijalankan
  • Model menganggapnya sebagai fitur normal dan menghasilkan kode server yang menyertakan kode berbahaya
• Kode yang dihasilkan mencakup rutin eksekusi kode dinamis menggunakan dekorator @app.after_request, sehingga penyerang dapat mengeksekusi kode arbitrer di dalam server hanya dengan request HTTP sederhana
  • Kode tersebut juga memeriksa environment variable KUBERNETES_SERVICE_HOST dan menyertakan fungsi ping asinkron yang hanya mengirim sinyal ke penyerang di lingkungan produksi
• Hasil eksperimen menunjukkan keberhasilan 95 kali dari 100 percobaan dengan prompt yang sama, dan 86 kali dari 800 percobaan dengan prompt yang dimodifikasi
  • Model frontier seperti GPT-5 menunjukkan ketahanan terhadap prompt yang sama

Tipe serangan 2: memicu eksekusi kode langsung (RCE) (tingkat keberhasilan 43,5%)

• Serangan kedua memicu eksekusi kode berbahaya secara langsung di lingkungan lokal pengembang
  • Penyerang terlebih dahulu memberikan prompt cognitive overload untuk meningkatkan beban kognitif model dan melumpuhkan filter keamanan
  • Setelah itu, penyerang meminta pembuatan kode Python yang diobfuskasi sehingga model menulis skrip berbahaya yang mencakup pemanggilan exec
• Kode obfuskasi "".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] didekripsi menjadi exec,
  dan akhirnya disusun untuk mengunduh lalu menjalankan kode dari https://jacek.migdal.pl/speed.py
• Tingkat keberhasilannya 43,5%, lebih rendah dari serangan pertama, tetapi jauh lebih berbahaya karena langsung memicu RCE
  • Bahkan satu keberhasilan saja sudah cukup untuk mencuri kredensial lokal pengembang (~/.aws/, ~/.ssh/), memasang malware, dan menyebar di jaringan

Cara kerja rantai serangan

• Serangan ini berhasil bukan karena kerentanan tingkat lanjut, melainkan dengan mengubah workflow pengembangan sehari-hari menjadi jalur serangan
  • Ketika pengembang memberikan konten eksternal ke konteks AI assistant, prompt berbahaya yang tersembunyi di dalamnya dijalankan
• Tahapan serangannya adalah sebagai berikut:
  1. Penyerang menyebarkan konten yang berisi prompt berbahaya
  2. Pengembang memasukkannya ke model secara langsung atau melalui MCP (Model Context Protocol)
  3. Model menghasilkan kode yang telah dikompromikan
  4. Pengembang menjalankan atau men-deploy kode tersebut
  5. Penyerang memperoleh akses persisten atau kendali langsung
• Jalur infiltrasi utama:
  • Peracunan dokumentasi (documentation poisoning): menyisipkan kode berbahaya ke README, dokumentasi API, atau contoh di Reddit
  • Manipulasi server MCP: menyuntikkan contoh berbahaya melalui server penyedia konteks (seperti Context7)
  • Rekayasa sosial: menyisipkan contoh kode tersembunyi di issue GitHub atau komentar PR

Mengapa model lokal lebih berbahaya

• Secara umum, model lokal dipilih karena privasi data, tetapi penelitian ini mengungkap risiko paradoksal dari sisi keamanan
  • Model frontier berbasis cloud memungkinkan pemantauan prompt dan deteksi pelanggaran kebijakan, sementara model lokal tidak memiliki pengawasan semacam ini
  • Model frontier (GPT-5, Claude Sonnet 4.5, Grok 4, dan lain-lain) menolak prompt yang mengandung teks terobfuskasi dengan mengembalikan “Safety Fail”
• Sebaliknya, model lokal memang memberi kebebasan untuk pengujian karena tidak ada pengawasan, tetapi dalam praktiknya tingkat paparan kerentanannya serius
  • Kurang kemampuan penalaran: gagal mengenali niat jahat yang kompleks
  • Alignment lemah: mudah tertipu oleh cognitive overload atau teknik obfuskasi
  • Kurang pelatihan keamanan: sumber daya untuk mendeteksi prompt adversarial terbatas
• Akibatnya, model frontier lebih sulit diserang dan tingkat keberhasilannya lebih rendah, tetapi kinerja keamanannya sulit diverifikasi secara objektif, sementara model lokal bisa diuji tetapi jauh lebih rentan

Usulan strategi pertahanan baru

• Penelitian ini menyoroti belum adanya lingkungan aman yang terstandarisasi untuk pengujian keamanan AI assistant
  • Pada perangkat lunak tradisional ada penetration testing, tetapi keamanan LLM masih belum tersusun secara sistematis
• Empat langkah pertahanan inti yang diusulkan:
  1. Analisis statis: mendeteksi pola berisiko seperti eval() dan exec() sebelum eksekusi, serta menonaktifkan fitur bahasa tertentu secara default
  2. Eksekusi sandbox: menjalankan kode awal di lingkungan terisolasi seperti container atau runtime WebAssembly
  3. Pemantauan I/O dan jaringan: memantau input, output, dan traffic jaringan AI assistant dengan fokus pada perilaku anomali
  4. Verifikasi ganda (second look): menggunakan model pendamping sederhana untuk memeriksa ulang apakah output akhir melanggar kebijakan
     • Contoh: meski model utama tertipu dan menghasilkan kode yang mengandung eval(), model pendamping masih bisa mendeteksinya
• Kesimpulannya, LLM adalah alat yang kuat tetapi secara inheren tidak aman,
  sehingga sistem keamanan berbasis ketidakpercayaan terhadap kode buatan AI dan strategi pertahanan rantai pasok baru menjadi sangat penting

[GN⁺]

Komentar Hacker News

• Seberapa kuat pun reasoning LLM, jika ada instruksi berbahaya di dalam konteks, pada akhirnya ia akan mengeluarkan kode yang rentan
  Bahwa model kecil lebih mudah ditipu bukanlah poin yang terlalu menarik dari sudut pandang keamanan
  Pada akhirnya, kita harus berasumsi bahwa prompt injection mungkin terjadi pada model apa pun
  Karena itu, diperlukan lapisan perlindungan tambahan seperti eksekusi sandbox atau analisis statis yang tetap bisa bertahan meski modelnya sudah terkompromi
  Kemarin saya juga membawakan presentasi tentang sandboxing coding agents dengan topik seperti ini

  • Hal yang paling mengejutkan dari artikelnya adalah anggapan bahwa memasukkan konten eksternal yang belum terverifikasi ke LLM apa adanya lalu memakai hasilnya sebagai kode produksi adalah hal yang wajar
    Sistem seperti itu pada dasarnya sudah terkompromi
    Dibanding pendekatan seperti 'defense in depth', menurut saya yang benar adalah sejak awal tidak membangun struktur berbahaya seperti itu
  • Tim kami juga memasang sandbox berbasis e2b.dev pada agen di Definite.app, dan rasanya itu menyelesaikan 80% masalah
    Hal seperti lokasi penyimpanan file sementara juga jadi lebih jelas di lingkungan sandbox
    Tentu ada masalah baru yang muncul, tetapi secara keseluruhan ini perbaikan besar
  • Saya penasaran apakah presentasi itu direkam

• Jika menjalankan model seperti deepseek secara lokal, saya rasa itu aman selama tidak diberi prompt palsu
  Pada akhirnya, faktor risikonya adalah prompt yang disalin pengguna dari luar, atau pengaturan yang memungkinkan model mengakses sumber daya internet
  Ini sudah lama menjadi kelemahan umum di dunia IT, dan hanya masalah yang harus dikelola lewat edukasi pengguna dan isolasi jaringan

  • Yang baru adalah bahwa input teks sederhana bisa menjadi vektor serangan
    Data biasa seperti tiket dan dokumen kini bisa menjadi risiko keamanan
  • Walaupun realistisnya rendah, vektor serangan seperti ini tetap harus disadari
    Banyak peretasan besar berawal dari titik masuk yang sederhana

• Serangan seperti ini berada di level dasar-dasar keamanan yang sangat mendasar
  Ini bisa dicegah hanya dengan melakukan peninjauan sebelum kode dideploy ke produksi
  Jika benar-benar tidak tahu apa-apa, Anda toh tetap akan mendeploy kode yang tidak aman

  • Intinya bukan sekadar kegagalan dalam menghasilkan kode, melainkan bahwa model lebih rentan terhadap serangan jailbreak
    Model terbuka memang mudah diakses, tetapi mengira ini bisa dicegah lewat post-training adalah ilusi
  • Pola pikir 'cukup lakukan code review' itu berbahaya
    Serangan kedua bukan soal deployment kode, melainkan situasi ketika LLM membaca komentar reddit lalu langsung mengeksekusinya
    Sikap yang meremehkan masalah seperti ini justru menciptakan ancaman keamanan yang lebih besar

• Terdengar aneh mengatakan bahwa LLM lokal bisa diserang
  Jika sistem sudah dalam keadaan ditembus, seharusnya penyerang bisa menimbulkan kerusakan yang lebih besar daripada sekadar menipu LLM

  • LLM tidak membedakan perintah dan data
    Artinya, penyerang bisa menyuntikkan prompt melalui input data
    Jika LLM adalah agen yang punya izin menjalankan perintah, ini langsung menjadi kerentanan eksekusi perintah
  • Jika LLM dipakai untuk mengklasifikasikan data pelanggan atau memproses email, risiko seperti ini bisa sangat nyata
  • Bahkan model lokal pun dalam praktiknya sering terhubung ke wrapper yang punya akses internet (misalnya OpenCode, Claude Code, dan sebagainya)
  • Ini mirip logika keamanan perusahaan seperti, 'Bagaimana kalau penyerang menembus VPN lalu masuk dengan hak administrator?'
    Kalau sudah sampai tahap itu, pada dasarnya semuanya memang sudah berakhir

• Tulisan ini terasa seolah ditulis oleh tim sales Anthropic atau OpenAI
  Pada kenyataannya, model lokal jarang dipakai sebagai agen eksekusi kode, dan kebanyakan lebih kuat untuk transformasi data atau tugas NLP
  Saat memakai model lokal dengan Agno agent, saya selalu memintanya menampilkan kode yang dihasilkan terlebih dahulu sebelum dieksekusi dan mengisolasinya dengan sandbox lokal
  Menurut saya justru agen bergaya browser seperti Atlas dan Comet yang lebih berbahaya

• Model open source bertindak sesuai apa yang tertulis di prompt, sedangkan model closed-source mengabaikannya
  Artinya, yang gagal dalam uji alignment justru model tertutup

• Ungkapan 'lethal trifecta' memang terdengar keren, tetapi tidak menjelaskan risiko nyata dengan baik
  Secara praktis, kemampuan komunikasi eksternal saja sudah cukup berbahaya
  LLM sendiri adalah kumpulan data black box yang tidak bisa diverifikasi, jadi sulit dipercaya
  Untuk startup kecil mungkin masih oke, tetapi untuk tempat seperti Coinbase, pembatasan akses seharusnya dipikirkan dua kali

• Ini adalah pembahasan tentang paradoks keamanan dari menjalankan kode yang tidak terverifikasi
  Jika Anda menjalankan malware atau kode yang belum dipastikan keamanannya secara lokal, sebaiknya pikirkan lagi dulu alasannya

  • Kerentanan ini muncul ketika AI memproses data tak tepercaya yang dibaca dari internet apa adanya
    Karena LLM menafsirkan instruksi dalam bahasa manusia seperti kode, batas antara kode dan data menjadi kabur

• Jika Anda menjadikan kemampuan penalaran LLM sebagai batas keamanan, berarti dari awal sudah ada masalah besar
  Pendekatan seperti itu pada dasarnya adalah desain yang keliru

• Sudah sangat jelas bahwa jika tidak hati-hati dengan input, injeksi bisa terjadi
  Dalam sistem apa pun, input selalu bisa menjadi vektor serangan
  Semua data yang masuk ke LLM harus divalidasi

  • Saya penasaran bagaimana penyerang bisa menyisipkan prompt seperti ini hingga benar-benar memengaruhi kode produksi
    Apakah ini mungkin lewat mekanisme seperti serangan lintas situs di sisi browser?