Asisten berbasis AI Anda mematuhi instruksinya sekitar 99% dari waktu, tetapi 1% yang hilang itulah tempat penyerang menyerang. Dengan memberikan prompt yang dirancang khusus, pengguna jahat dapat membuat model memanggil fungsi yang tidak seharusnya, mencuri data atau melakukan tindakan istimewa. Solusinya bukanlah kata-kata yang lebih sopan—melainkan memperlakukan celah tersebut sebagai masalah otorisasi dan menghapus alat-alat berbahaya dari jangkauan model.

Mengapa prompt injection bukan sekadar masalah pemilihan kata

Pengembang sering mencoba memperkuat agen dengan peringatan huruf kapital, aturan bernomor, atau klausul "jangan panggil fungsi admin". Pertahanan tersebut mengasumsikan bahwa model akan mematuhi kalimat yang berbunyi "jangan lakukan X." Dalam praktiknya, model dapat dibujuk untuk mengabaikan instruksi tersebut dengan menyusun ulang permintaan, memainkan peran persona yang berbeda, atau sekadar menambahkan konteks tambahan. Batasan bahasa Inggris bersifat negosiasi; prompt penyerang tidak terbatas dan tidak memerlukan biaya untuk diuji.

Kerentanan yang sebenarnya terletak pada daftar alat yang diterima agen. Ketika skema prompt berisi fungsi yang memberikan hak admin, model kini memiliki peta menuju kekuatan tersebut. Bahkan jika prompt mengatakan "jangan gunakan untuk pelanggan," model masih dapat dibujuk untuk memanggilnya karena fungsi tersebut ada dalam lingkungan eksekusinya. Oleh karena itu, masalahnya adalah celah otorisasi: sistem mengekspos kemampuan istimewa kepada pemanggil yang tidak memiliki hak atas kemampuan tersebut.

Mengamankan agen dengan membatasi paparan

Cara termudah untuk menutup celah tersebut adalah dengan berhenti memberikan akses kepada model ke alat-alat yang tidak diotorisasi untuk digunakan. Anggaplah daftar alat sebagai kunci API: jika kunci tersebut tidak ada, panggilan tidak dapat terjadi. Tidak ada kata-kata cerdik yang dapat memanggil fungsi yang tidak ada dalam konteks saat ini.

Cara yang salah

Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”

Model masih melihat adminDeleteUser dalam kotak peralatannya dan dapat dikelabui untuk memanggilnya.

Cara yang benar

Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }

adminDeleteUser tidak pernah muncul, sehingga model tidak memiliki jalur untuk memanggilnya.

Tiga aturan praktis untuk pengembang

  1. Bangun daftar alat per permintaan – Hasilkan katalog fungsi secara dinamis, berdasarkan izin pemanggil yang terautentikasi. Pelanggan hanya melihat fungsi yang mereka butuhkan; admin melihat set lengkapnya.
  2. Gagal tertutup (fail closed) – Jika identitas pengguna tidak dapat diverifikasi, kembalikan daftar kosong daripada fallback "semua alat tersedia" yang bersifat umum. Ini menjamin bahwa permintaan yang tidak terautentikasi tidak akan pernah mendapatkan kekuatan yang tidak terduga.
  3. Hindari status bersama (shared state) – Saat melakukan caching definisi alat, jangan pernah menulis data spesifik pengguna ke dalam objek bersama. Gunakan copy-on-write atau salinan per sesi sehingga izin satu pengguna tidak dapat merembes ke permintaan pengguna lain.

Jika skema yang disajikan kepada pengguna biasa terlihat identik dengan yang ditunjukkan kepada admin, batasan keamanan tetaplah teks prompt, dan prompt bukanlah mekanisme keamanan yang andal.

Apa yang membawa kita ke sini

Prompt injection muncul ketika pengembang mulai menghubungkan model bahasa besar (LLM) ke alur kerja produksi yang mengharuskan model untuk memanggil API eksternal, menjalankan kode, atau memodifikasi database. "Penalaran" model dipandu oleh prompt yang juga menyertakan daftar alat yang tersedia. Prototipe awal mengasumsikan model akan mematuhi aturan bahasa alami seperti "jangan hapus catatan untuk non-admin." Penyerang dengan cepat menunjukkan bahwa beberapa kalimat tambahan dapat melewati aturan tersebut, yang memicu model untuk tetap memanggil fungsi hapus yang sama.

Reaksi pertama komunitas adalah memperketat bahasa prompt, menambahkan klausul "jangan pernah lakukan X", atau menyematkan filter regex yang menghapus token mencurigakan. Langkah-langkah tersebut mengurangi penyalahgunaan yang tidak disengaja tetapi tidak menghentikan lawan yang gigih yang dapat dengan mudah menyusun ulang permintaan. Penyebab utamanya—mengekspos fungsi istimewa kepada pemanggil yang tidak tepercaya—tetap ada.

Siapa yang menang, siapa yang kalah

Perusahaan yang mengadopsi pembatasan alat per permintaan (per-request tool scoping) mendapatkan batasan yang jelas dan dapat ditegakkan. Agen mereka dapat diterapkan dalam skala besar tanpa takut satu prompt yang salah format akan membuka kemampuan admin. Tim kepatuhan juga menghargai jejak auditnya: daftar fungsi yang dikirim ke model adalah artefak nyata yang dapat dicatat dan ditinjau.

Pengembang yang mengandalkan penjaga berbasis prompt saja terus menghadapi target yang terus berubah. Agen mereka mungkin tampak berfungsi dalam pengujian tetapi dapat disusupi di dunia nyata, yang menyebabkan kebocoran data, transaksi tidak sah, atau pelanggaran kepatuhan. Biaya dari sebuah pelanggaran jauh lebih besar daripada upaya membangun daftar alat yang dinamis.

Argumen lawan: “Prompt yang lebih baik sudah cukup”

Beberapa orang berpendapat bahwa dengan rekayasa instruksi yang cukup—prompt berlapis, pesan sistem, dan reinforcement learning from human feedback—model dapat dibuat untuk mematuhi klausul “jangan”. Kenyataannya adalah model bahasa merupakan generator probabilistik; mereka menimbang kelanjutan yang paling mungkin, bukan aturan keamanan yang kaku. Bahkan dengan guardrails yang telah disempurnakan, ungkapan baru dapat lolos, terutama ketika penyerang dapat melakukan iterasi tanpa henti dengan biaya nol. Guardrails berguna untuk mengurangi noise tetapi tidak boleh menjadi satu-satunya lini pertahanan.

Apa yang perlu diperhatikan selanjutnya

  • Framework yang mengekspos tool scoping sebagai API kelas utama – Nantikan pustaka baru yang memungkinkan Anda mendeklarasikan kapabilitas per-pengguna dan secara otomatis memangkas daftar fungsi sebelum prompt disusun.
  • “function manifests” yang terstandardisasi – Kelompok industri mungkin akan mendefinisikan skema JSON yang memisahkan fungsi publik dan fungsi dengan hak istimewa, sehingga memudahkan pembuatan manifest khusus permintaan.
  • Penegakan runtime – Beberapa platform sedang bereksperimen dengan eksekusi sandboxed yang memeriksa token pemanggil terhadap fungsi yang dipanggil, menambahkan lapisan kedua di luar prompt scoping.

Kesimpulannya jelas: perlakukan prompt injection sebagai celah otorisasi. Dengan menghapus alat yang tidak sah dari kotak peralatan model, Anda menghilangkan permukaan serangan yang coba dieksploitasi oleh prompt dengan kata-kata yang disusun secara cerdik. Prompt dapat memandu perilaku; mereka tidak dapat menggantikan kontrol akses yang tepat.