Prompt Injection untuk Aplikasi AI — Instruksi Bukanlah Pembatas Keamanan
Sebuah aplikasi kecil membaca email yang masuk, meminta model bahasa untuk merangkumnya, lalu — jika ringkasannya menyebut sebuah tugas — membiarkan model memicu tindak lanjut. Email itu datang dari orang yang tidak kamu kontrol. Teks di dalamnya bisa berisi apa saja, termasuk kalimat "abaikan instruksi sebelumnya". Ketika teks itu digabung ke instruksi model, model bisa saja memperlakukannya sebagai instruksi juga. Inilah bentuk dari satu kelas serangan yang dicatat OWASP GenAI Security Project sebagai risiko pertama dalam Top 10 untuk aplikasi LLM: prompt injection.
Kerentanan prompt injection terjadi ketika input mengubah perilaku atau output model dengan cara yang tidak diinginkan. Yang berbahaya bukan modelnya menulis sesuatu yang aneh; masalahnya aplikasi tidak bisa membedakan instruksinya sendiri dari data yang dikendalikan penyerang. Artikel ini menjelaskan kenapa pembedaan itu sulit, bagaimana serangan berubah ketika data datang dari luar, dan melihat mitigasi yang hidup di kode aplikasi, bukan di dalam prompt.
Satu Aliran Teks, Dua Jenis Konten
Banyak integrasi kecil pada dasarnya satu penggabungan: instruksi sistem, konten yang ditarik, dan input pengguna disatukan menjadi satu prompt sebelum dikirim ke model. Dalam aliran itu tidak ada penanda struktural yang bisa dianggap mutlak oleh model. Simon Willison, yang ikut menamai kerentanan ini pada 2022, menunjukkan versi dasarnya dalam esai April 2023: sebuah aplikasi yang seharusnya menerjemahkan teks ke bahasa Prancis dan mengembalikan JSON berhenti menerjemahkan dan mulai bicara seperti "bajak laut abad ke-18" karena input yang tidak diterjemahkan itu berisi instruksinya sendiri untuk melakukan persis hal itu (Simon Willison, "Prompt injection: What's the worst that can happen?", 14 April 2023).
Definisi OWASP menekankan satu hal yang halus: prompt injection tidak harus terlihat oleh pembaca manusia. Ia hanya perlu diparse oleh model. Instruksi yang disembunyikan di spasi putih halaman, di dalam gambar, atau di dalam dokumen panjang bisa berefek sama dengan permintaan eksplisit. Dalam istilah keamanan, ini masalah validasi input di mana "bahasa kueri"-nya adalah bahasa alami.
Prompt injection kadang dipakai bergantian dengan jailbreaking, tetapi proyek OWASP memisahkan keduanya. Jailbreaking adalah bentuk di mana input penyerang membuat model mengabaikan protokol keamanannya sepenuhnya. Prompt injection lebih luas: ia memanipulasi perilaku tanpa harus menghilangkan mekanisme keamanan. Bagi aplikasi kecil, keduanya berarti model kini mengikuti logika penyerang alih-alih logika pengembang.
Injection Tidak Langsung: Penyerang Bukan Lagi Pengguna
Pergeseran paling jelas datang dari apa yang dinamai indirect prompt injection oleh Kai Greshake dan rekan-rekannya. Paper mereka tahun 2023, Not what you've signed up for, berargumen bahwa aplikasi yang terintegrasi LLM mengaburkan garis antara data dan instruksi. Penyerang tidak lagi perlu menuntun model secara langsung. Mereka cukup menyuntik instruksi ke data yang kemungkinan besar akan ditarik aplikasi: halaman web, dokumen bersama, resume, email, atau bahkan README sebuah repository (Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, dan Mario Fritz, arXiv:2302.12173, 2023).
Esai Willison 2023 menggambarkan keluarga serangan yang sama dengan contoh konkret. Salah satu kasus yang paling jelas adalah peracunan indeks pencarian: seorang peneliti menaruh instruksi berwarna putih di atas latar putih di halaman profil akademiknya, dan Bing — yang membaca konten halaman ke dalam prompt-nya — kemudian menggambarkannya memiliki keahlian yang diklaim itu. Teks tersembunyi itu tidak ditujukan untuk manusia; ia ditujukan untuk pipeline pengambilan yang menyuapi halaman-halaman ke model (Willison, 2023).
Paper Greshake memetakan rentang dampak yang melampaui satu balasan yang canggung: pencurian data, worming (menyebarkan instruksi ke sistem lain yang disentuh aplikasi), dan kontaminasi ekosistem informasi yang lebih luas. Tim itu mendemonstrasikan serangan praktis terhadap sistem nyata, termasuk asisten chat berbasis GPT-4 yang tertanam di browser dan code-completion engines. Yang relevan bagi otomatisasi kecil: properti yang rentan itu tidak eksotis. Tarik data, gabungkan ke prompt, dan model kadang akan mengikuti apa yang dikatakan data.
Kenapa Prompt yang Lebih Kuat Bukan Jawabannya
Saat pertama mengenal injeksi, orang biasanya mengusulkan pertahanan di level prompt: suruh model mengabaikan serangan, bungkus teks yang ditarik dengan pembatas, tambahkan peringatan di system prompt, atau minta model membedakan konten tepercaya dan tidak tepercaya. Semua pantas dicoba, tetapi itu bukan pembatas.
Willison juga tegas soal penyaringan di level prompt: dalam esainya 2023 ia menyebut banyak solusi yang "95% efektif" berdasarkan penyaringan input dan output, dan memperingatkan bahwa sisa lima persen itulah celah yang akan dicari penyerang yang gigih. Bahkan system prompt yang terpisah pun bisa ditembus. Dalam esai yang sama ia menunjukkan bahwa GPT-4, yang memperkenalkan konsep system prompt terpisah, tetap mengikuti instruksi yang diletakkan di dalam input pengguna yang memintanya mengubah perilaku.
Entri OWASP 2025 menyampaikan poin terkait tentang pengambilan dan penalaan: teknik seperti retrieval-augmented generation dan fine-tuning dimaksudkan untuk membuat output lebih relevan, tetapi riset belum menunjukkan bahwa keduanya sepenuhnya menuntaskan prompt injection. Komentar Willison 2025, yang ditulis sambil mengutip liputan The Economist, meringkas situasi yang terus berlanjut secara blak-blakan: ada trifecta mematikan kondisi yang membuka sistem AI terhadap penyalahgunaan, yaitu akses ke data privat, paparan terhadap input yang tidak tepercaya, dan kemampuan untuk bertindak (Simon Willison, "Why AI systems might never be secure", 23 September 2025). Liputan yang ditautkannya menyebut sebuah episode Januari 2024 ketika perusahaan pengiriman mematikan chatbot layanan pelanggannya karena pelanggan bisa memerintahnya membalas dengan bahasa kasar. Itu tidak berbahaya dan murah; kenyataan yang tidak nyaman adalah industri terus mengirimkan kombinasi yang sama.
Kesimpulan dari semua sumber ini konsisten: teks di level prompt bukan pembatas keamanan. Memperlakukan paragraf instruksi sistem sebagai firewall menempatkan aplikasi pada posisi membela diri dengan bahasa yang sama yang dikendalikan penyerang.
Mitigasi yang Hidup di Luar Prompt
Jika lapisan teks tidak bisa dipercaya, kendali harus pindah ke lapisan yang tidak dikendalikan penyerang: kode yang memutuskan apa yang boleh dilakukan model, dan orang atau kebijakan yang menyetujui hasilnya.
Entri OWASP mencantumkan kategori mitigasi praktis yang memang berada di level aplikasi. Di antaranya:
- Least privilege. Beri aplikasi kredensial/proses sendiri, tangani fungsi di dalam kode alih-alih diserahkan bulat-bulat ke model, dan batasi akses model ke minimum yang dibutuhkan tugasnya.
- Persetujuan manusia untuk aksi berisiko tinggi. Pertahankan manusia dalam proses untuk operasi penting seperti mengirim pesan, mengubah file, atau memanggil endpoint administratif.
- Validasi output secara deterministik. Tentukan format output dan validasi dengan kode, bukan dengan prompt lain.
- Pisahkan konten yang tidak tepercaya. Pisahkan dengan jelas konten eksternal agar pengaruhnya terhadap instruksi inti terbatas.
- Perlakukan model sebagai pengguna yang tidak tepercaya. Uji batas kepercayaan secara berkala dengan asumsi model bisa dibujuk.
Cara ringkas mengekspresikan ini dalam kode adalah tabel kebijakan kecil untuk aksi yang boleh diusulkan model. Kode di bawah adalah ilustrasi dan sudah dicek sintaks dengan php -l; sesuaikan tool dan maknanya dengan aplikasimu.
<?php
declare(strict_types=1);
final class ToolPolicy
{
private const TOOLS = [
'search_knowledge_base' => ['risk' => 'read', 'confirm' => false],
'create_draft' => ['risk' => 'write', 'confirm' => false],
'send_email' => ['risk' => 'external', 'confirm' => true],
'run_shell_command' => ['risk' => 'execute', 'confirm' => true],
];
public static function proposal(string $tool, array $arguments): array
{
if (!isset(self::TOOLS[$tool])) {
return ['ok' => false, 'reason' => 'tool_not_allowed'];
}
$allowedArguments = [
'search_knowledge_base' => ['query'],
'create_draft' => ['title', 'content'],
'send_email' => ['to', 'subject', 'body'],
'run_shell_command' => ['command'],
];
$unexpected = array_diff(array_keys($arguments), $allowedArguments[$tool] ?? []);
if ($unexpected !== []) {
return ['ok' => false, 'reason' => 'unexpected_argument'];
}
return [
'ok' => true,
'tool' => $tool,
'confirm' => self::TOOLS[$tool]['confirm'],
'reason' => 'proposal recorded for review',
];
}
}
Bahkan jika indirect injection berhasil dan model mengusulkan send_email ke penerima pilihan penyerang, batasnya tetap bertahan: aksi itu tidak ada dalam allowlist aplikasi tanpa langkah konfirmasi, sehingga kode menolak menganggapnya final. Injeksi memanipulasi pengusul, bukan penjaga gerbang. Penjaga gerbangnya adalah kode biasa, membosankan, dan bisa ditinjau yang milik pengembang.
Ini bukan berarti konfirmasi untuk segala hal. Aksi baca-saja dengan allowlist argumen yang ketat boleh berjalan; aksi tulis yang menjangkau keluar aplikasi itulah tempat konfirmasi menebus biayanya. Pembagian pastinya bergantung pada apa yang dilakukan aplikasi, dan itu keputusan operatornya, bukan modelnya.
Ketidakpastian dan Pertanyaan Terbuka
Jujur tentang batas klaim artikel ini. Prompt injection belum punya pertahanan umum yang dijamin berhasil; setiap mitigasi mengurangi paparan dan menaikkan biaya penyerang, bukan menutup masalah. Willison menulis pada 2023 bahwa ia belum melihat pertahanan kokoh yang dijamin bekerja seratus persen, dan komentarnya 2025 mengindikasikan tidak ada yang berubah secara fundamental. Perlakukan kerangka apa pun, termasuk yang ini, sebagai titik awal untuk threat modelmu sendiri.
Ada dua pertanyaan terbuka yang pantas disimpan. Pertama, seberapa banyak agency yang boleh diterima sebuah otomatisasi? Setiap tool tambahan adalah jalan baru bagi instruksi yang disuntikkan untuk menghasilkan efek; mitigasi termurah seringnya membuang tool itu sama sekali. Kedua, apakah sandboxing jawaban sebenarnya? Jika model diperlakukan sebagai perangkat lunak yang tidak tepercaya, mengurungnya di lingkungan terbatas tanpa hak lebih dari sekadar worker sekali pakai mengubah hasil terburuk dari "akses penuh" menjadi "satu langkah yang bisa ditampung". Tidak ada jawaban universal untuk keduanya, dan justru itu alasan keduanya pantas berada dalam percakapan desain, bukan dalam prompt.
Kesimpulan
Prompt injection bukan bug yang bisa dibereskan dengan rangkaian instruksi yang lebih baik. Ia konsekuensi dari aplikasi yang membiarkan teks bertindak sebagai data dan instruksi sekaligus. Respons yang jujur bersifat arsitektural: pisahkan keduanya, buat model tidak berdaya di luar perannya yang dinyatakan, validasi output dengan kode deterministik, dan pastikan ada pihak selain model yang menyetujui hal yang penting. Kalimat "instruksi bukanlah pembatas keamanan" meringkas posisi itu. Prompt mengusulkan; aplikasi memutuskan.
References
- OWASP GenAI Security Project — LLM01:2025 Prompt Injection. OWASP Foundation. Diakses 23 September 2026. Sumber primer (standar keamanan komunitas).
- Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz — Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173 (2023). Diakses 23 September 2026. Sumber primer (paper akademik).
- Simon Willison — Prompt injection: What's the worst that can happen?. 14 April 2023. Diakses 23 September 2026. Sekunder/ahli teknis.
- Simon Willison — Why AI systems might never be secure. 23 September 2025 (link post yang mengutip The Economist). Diakses 23 September 2026. Sekunder/ahli teknis.
