Pembantu dipacu AI anda mematuhi arahan sebanyak 99% masa, tetapi 1% yang hilang itulah tempat penyerang menyerang. Dengan memasukkan prompt yang direka khas, pengguna berniat jahat boleh membuat model memanggil fungsi yang tidak sepatutnya, mencuri data atau melakukan tindakan berkuasa tinggi. Penyelesaiannya bukan dengan kata-kata yang lebih sopan—tetapi dengan menganggap kecacatan tersebut sebagai isu autorisasi dan mengeluarkan alatan berbahaya daripada jangkauan model.
Mengapa suntikan prompt bukan sekadar masalah pemilihan kata
Pembangun sering cuba memperkukuh ejen dengan amaran huruf besar, peraturan bernombor, atau klausa "jangan panggil fungsi admin". Pertahanan tersebut mengandaikan model akan mematuhi ayat yang berbunyi "jangan lakukan X." Dalam praktiknya, model boleh dipujuk untuk mengabaikan arahan tersebut dengan mengubah suai permintaan, melakukan lakon peranan persona yang berbeza, atau sekadar menambah konteks tambahan. Sempadan bahasa Inggeris boleh dirunding; prompt penyerang adalah tanpa had dan tidak memerlukan kos untuk diuji.
Kerentanan sebenar terletak pada senarai alatan yang diterima oleh ejen. Apabila skema prompt mengandungi fungsi yang memberikan hak admin, model kini mempunyai peta ke kuasa tersebut. Walaupun prompt menyatakan "jangan gunakannya untuk pelanggan," model masih boleh dipujuk untuk memanggilnya kerana fungsi tersebut wujud dalam persekitaran pelaksanaannya. Oleh itu, masalahnya adalah jurang autorisasi: sistem mendedahkan keupayaan istimewa kepada pemanggil yang tidak mempunyai hak ke atasnya.
Mengamankan ejen dengan mengehadkan pendedahan
Cara termudah untuk menutup jurang tersebut adalah dengan berhenti memberi model akses kepada alatan yang tidak diberi kuasa untuk digunakan. Anggap senarai alatan sebagai kunci API: jika kunci tidak ada, panggilan tidak boleh berlaku. Tiada kata-kata bijak yang dapat memanggil fungsi yang tidak ada dalam konteks semasa.
Cara yang salah
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
Model masih melihat adminDeleteUser dalam kotak alatan dan boleh diperdaya untuk memanggilnya.
Cara yang betul
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser tidak pernah muncul, jadi model tidak mempunyai jalan untuk memanggilnya.
Tiga peraturan praktikal untuk pembangun
- Bina senarai alatan mengikut permintaan – Jana katalog fungsi secara dinamik, berdasarkan kebenaran pemanggil yang telah disahkan. Pelanggan hanya melihat fungsi yang mereka perlukan; admin melihat set yang lengkap.
- Gagal secara tertutup (Fail closed) – Jika identiti pengguna tidak dapat disahkan, kembalikan senarai kosong berbanding pilihan sandaran "semua alatan tersedia" yang generik. Ini menjamin bahawa permintaan tanpa pengesahan tidak akan memperoleh kuasa yang tidak dijangka.
- Elakkan keadaan dikongsi (shared state) – Apabila menyimpan cache definisi alatan, jangan sekali-kali menulis data khusus pengguna pada objek yang dikongsi. Gunakan copy-on-write atau salinan setiap sesi supaya kebenaran seorang pengguna tidak boleh meresap ke dalam permintaan pengguna lain.
Jika skema yang dibentangkan kepada pengguna biasa kelihatan serupa dengan yang ditunjukkan kepada admin, sempadan keselamatan masih terletak pada teks prompt, dan prompt bukanlah mekanisme keselamatan yang boleh dipercayai.
Apa yang membawa kita ke sini
Suntikan prompt muncul apabila pembangun mula menyepadukan model bahasa besar (LLM) ke dalam aliran kerja pengeluaran yang memerlukan model memanggil API luaran, menjalankan kod, atau mengubah suai pangkalan data. "Penaakulan" model dipandu oleh prompt yang juga menyertakan senarai alatan yang tersedia. Prototaip awal mengandaikan model akan mematuhi peraturan bahasa semula jadi seperti "jangan padam rekod untuk bukan admin." Penyerang dengan cepat menunjukkan bahawa beberapa ayat tambahan boleh memintas peraturan tersebut, mendorong model untuk memanggil fungsi padam yang sama juga.
Tindak balas pertama komuniti adalah untuk memperketat bahasa prompt, menambah klausa "jangan sesekali lakukan X," atau menyematkan penapis regex yang membuang token yang mencurigakan. Langkah-langkah tersebut mengurangkan penyalahgunaan tidak sengaja tetapi tidak menghentikan lawan yang bertekad yang hanya perlu mengubah suai permintaan. Punca utamanya—mendedahkan fungsi istimewa kepada pemanggil yang tidak dipercayai—tetap kekal.
Siapa yang menang, siapa yang kalah
Perusahaan yang mengguna pakai skop alatan mengikut permintaan mendapat sempadan yang jelas dan boleh dikuatkuasakan. Ejen mereka boleh digunakan pada skala besar tanpa bimbang bahawa satu prompt yang salah format akan membuka keupayaan admin. Pasukan pematuhan juga menghargai jejak audit: senarai fungsi yang dihantar ke model adalah artifak konkrit yang boleh direkod dan disemak.
Pembangun yang bergantung kepada kawalan prompt sahaja akan terus menghadapi sasaran yang sentiasa berubah. Ejen mereka mungkin kelihatan berfungsi semasa ujian tetapi boleh diceroboh di dunia nyata, membawa kepada pelanggaran data, transaksi tanpa kebenaran, atau pelanggaran pematuhan. Kos pelanggaran jauh lebih besar daripada usaha membina senarai alatan yang dinamik.
Hujah balas: “Prompt yang lebih baik sudah mencukupi”
Some argue that with enough instruction engineering—layered prompts, system messages, and reinforcement learning from human feedback—the model can be made to respect “do not” clauses. The reality is that language models are probabilistic generators; they weigh the most likely continuation, not a hard security rule. Even with fine-tuned guardrails, a novel phrasing can slip through, especially when the attacker can iterate endlessly at zero cost. Guardrails are useful for reducing noise but should not be the sole line of defense.
What to watch next
- Frameworks that expose tool scoping as a first-class API – Expect new libraries that let you declare per-user capabilities and automatically prune the function list before the prompt is built.
- Standardized “function manifests” – Industry groups may define a JSON schema that separates public and privileged functions, making it easier to generate request-specific manifests.
- Runtime enforcement – Some platforms are experimenting with sandboxed execution that checks the caller’s token against the function being invoked, adding a second layer beyond prompt scoping.
The takeaway is clear: treat prompt injection as an authorization flaw. By removing unauthorized tools from the model’s toolbox, you eliminate the attack surface that a cleverly worded prompt seeks to exploit. Prompts can guide behavior; they cannot replace proper access control.