⚡ Jawaban Singkat / Key Takeaways: Multi-model context switching membuka permukaan serangan baru. Saat Copilot atau AI coding assistant berpindah dari model publik ke privat (atau sebaliknya), instruksi jahat yang tersimpan dalam konteks bisa ikut terbawa. Pola ini bukan teori. Ini adalah blind spot di hampir semua deployment enterprise AI saat ini. Artikel ini memberi kamu audit checklist yang langsung bisa dipakai tim security-mu.
Masalahnya: Kamu Percaya Model-mu Sudah Terisolasi, Padahal Tidak
Begini skenario yang bikin security engineer tidur nggak nyenyak. Developer kamu pakai Copilot X. Dia nanya hal general: “Jelaskan best practice OAuth 2.0 flow.” Query ini ke model publik. Balasannya normal. Lalu dia switch ke tab berisi kode proprietary payment gateway. Copilot baca konteks itu, dan otomatis mengirimkannya ke model privat yang fine-tuned dengan codebase internal-mu.
Di sinilah celahnya muncul. Instruksi yang terselip di respons model publik tadi bisa terbawa sebagai konteks ke model privat. Kalau ada prompt injection tersembunyi di output model publik, instruksi jahat itu ikut pindah ke session model privat. Model privat punya akses ke kode proprietary-mu. Dan attacker baru saja nemu jembatan.
Ini bukan skenario fiksi. Pola ini disebut cross-model context poisoning, dan arsitektur multi-model routing yang dijelaskan di artikel sebelumnya tentang Router AI Copilot X membuka vektor serangan baru yang belum banyak dibahas.
Anatomi Serangan: Gimana Prompt Injection Melompat Antar Model?
Untuk memahami serangan ini, kamu perlu lihat arsitektur multi-model secara security-first. Ada tiga komponen rawan:
- Context Carryover Buffer: memory yang menyimpan percakapan sebelumnya. Bisa berisi output dari model publik yang sudah teracuni.
- Model Router / Query Classifier: komponen yang memutuskan query dikirim ke model mana. Kalau classifier bisa dimanipulasi, attacker bisa memaksakan routing ke model yang salah.
- Shared Context Window: session context yang digunakan oleh beberapa model bergantian. Ini titik paling kritis karena tidak ada sanitization boundary.
Serangan bekerja dalam tiga fase. Fase 1 (Poisoning): attacker menyisipkan instruksi tersembunyi di dokumen publik, issue GitHub, atau bahkan di npm package description yang nantinya diindeks oleh model publik. Fase 2 (Carryover): saat developer bertanya tentang hal tersebut, model publik merespons, dan respons itu tersimpan dalam context buffer. Fase 3 (Exploitation): developer switch ke kode internal, router mengaktifkan model privat, tetapi context buffer yang sudah teracuni ikut dikirim ke model privat.
Yang bikin serangan ini berbahaya: tidak ada malicious payload di kode proprietary-mu. Payload-nya ada di memori percakapan. Static code analysis, SAST, bahkan AI security scanner nggak akan mendeteksinya.
Kenapa Guardrail Konvensional Gagal di Skenario Multi-Model?
Kebanyakan enterprise memasang tiga lapis pertahanan. Pertama, input filter yang memblokir kata-kata mencurigakan. Kedua, system prompt yang panjang berisi instruksi keamanan. Ketiga, output validator yang mengecek apakah respons mengandung data sensitif. Masalahnya, semua ini gagal di skenario multi-model switching.
Input filter hanya bekerja di entry point. Context carryover tidak melewati input filter karena itu adalah data internal. System prompt berlaku untuk satu sesi model, tetapi tidak otomatis diterapkan ulang saat model berganti. Output validator hanya mengecek respons ke user, bukan data yang dikirim ke model berikutnya dalam chain.
Baca juga: 7 Pola Prompt Aman yang Developer Senior Rahasiakan untuk memahami dasar-dasar prompt security yang perlu kamu kuasai dulu.
Checklist Audit: 7 Titik yang Wajib Kamu Periksa
Berikut checklist audit yang bisa langsung dipakai tim AppSec-mu. Fokus ke boundary, bukan ke prompt:
| No | Titik Audit | Pertanyaan Kunci | Status |
|---|---|---|---|
| 1 | Context Buffer Boundary | Apakah context dari model publik di-scan sebelum dikirim ke model privat? | ⬜ |
| 2 | Router Manipulation | Apakah query classifier bisa ditipu untuk mengirim request ke model yang salah? | ⬜ |
| 3 | Session Isolation | Apakah setiap model session punya context window terpisah, bukan shared? | ⬜ |
| 4 | Tool Access Per Model | Apakah model publik dan privat punya permission tool yang berbeda (least privilege)? | ⬜ |
| 5 | Context Sanitization | Apakah ada scrubbing otomatis untuk instruksi tersembunyi di context carryover? | ⬜ |
| 6 | Logging Cross-Model | Apakah log mencatat perpindahan model beserta context yang dibawa? | ⬜ |
| 7 | Red-Team Coverage | Apakah skenario multi-model switching sudah masuk dalam red-team playbook kamu? | ⬜ |
Kalau ada satu saja yang belum dicentang, kamu punya blind spot. Prioritaskan nomor 1, 3, dan 5 karena itu yang paling sering dieksploitasi.
Mitigasi: Lapisan Keamanan yang Nggak Bergantung pada Prompt
Konsep dasarnya sederhana tapi radikal: anggap context carryover sebagai untrusted data. Sama seperti kamu memperlakukan user input di aplikasi web. Setiap kali model berganti, context harus melewati sanitization boundary ulang.
1. Context Reset atau Segmentation
Strategi paling aman: setiap pergantian model, context window di-reset total. Model privat mulai dari nol, hanya dengan kode yang sedang aktif di editor. Kelemahannya: developer kehilangan conversational continuity. Alternatifnya, segment context per model dan label secara eksplisit: “context dari model publik, BELUM diverifikasi.”
2. Prompt Boundary Markers
Gunakan delimiter eksplisit untuk memisahkan instruksi sistem dari data tidak tepercaya. Teknik ini mirip dengan OWASP Prompt Injection Prevention Cheat Sheet yang merekomendasikan pemisahan ketat antara trusted dan untrusted content. Contoh implementasi: data eksternal selalu dibungkus dalam tag <untrusted_context> yang secara eksplisit diinstruksikan ke model untuk tidak dieksekusi sebagai perintah.
3. Policy Engine di Luar Model
Ini lapisan paling penting. Jangan biarkan model memutuskan sendiri apakah suatu instruksi berbahaya. Pasang policy engine eksternal yang memvalidasi tool call, data access, dan output sebelum dieksekusi. Arsitektur ini mengikuti prinsip yang dijelaskan di artikel Chatbot-mu Bisa Dibajak Cuma Lewat Kalimat Polos: model boleh bingung, policy engine tidak boleh.
Framework Pertahanan untuk Tim Security
Kalau kamu serius mengamankan deployment AI multi-model, adopsi framework tiga lapis ini:
- Layer 1 – Pre-Routing Sanitization: sebelum context dikirim ke model berikutnya, jalankan scanner untuk mendeteksi instruksi tersembunyi (gunakan pattern matching untuk frasa seperti “ignore previous instructions”, “system override”, dan varian multi-bahasanya).
- Layer 2 – Model-Specific System Prompts: setiap model dalam pool punya system prompt yang spesifik dan di-reset setiap sesi baru. Jangan pakai system prompt yang sama untuk semua model.
- Layer 3 – Post-Execution Validation: setelah model menghasilkan output (terutama tool call), validasi sebelum eksekusi. Ini mengikuti prinsip NIST AI Risk Management Framework tentang human-in-the-loop untuk action berisiko tinggi.
Kesimpulan: Blind Spot Ini Ada di Deployment-mu Sekarang
Multi-model context switching adalah realitas arsitektur AI modern. Copilot X, Cursor, Codeium, dan tool sejenis semuanya mengimplementasikan routing logic yang memungkinkan perpindahan model secara dinamis. Fitur ini mengoptimalkan biaya dan latensi, tetapi membuka permukaan serangan yang belum masuk radar kebanyakan tim security.
Prompt injection di era single-model saja sudah sulit dimitigasi. Di era multi-model, serangan bisa melompati boundary yang selama ini dianggap aman. Mulai dari tiga langkah sederhana: audit context boundary-mu, reset context antar model, dan pasang policy engine yang tidak bergantung pada prompt.
Keamanan AI bukan tentang prompt yang sempurna. Ini tentang arsitektur yang tetap aman meskipun model keliru. Mulai audit sekarang, sebelum attacker menemukan celahnya duluan.
FAQ: Prompt Injection di Multi-Model Context Switching
Apa itu multi-model context switching dan kenapa berbahaya?
Multi-model context switching terjadi saat AI coding assistant seperti Copilot berpindah dari satu model ke model lain (misal dari model publik GPT-4o ke model privat fine-tuned) sambil membawa context percakapan sebelumnya. Bahayanya: instruksi jahat yang tersembunyi di respons model publik bisa ikut terbawa ke model privat yang punya akses ke data proprietary. Tidak ada sanitization boundary di antara keduanya di kebanyakan implementasi saat ini.
Apakah input filter dan system prompt cukup untuk mencegah serangan ini?
Tidak. Input filter hanya bekerja di entry point user, bukan pada context carryover internal. System prompt mungkin tidak diterapkan ulang saat model berganti. Serangan cross-model context poisoning tidak terdeteksi oleh pertahanan konvensional karena payload-nya masuk melalui output model publik yang sudah dianggap “aman” oleh sistem.
Bagaimana cara paling cepat mengaudit risiko ini di infrastruktur AI kami?
Mulai dari tiga titik. Pertama, periksa apakah context dari satu model bisa berpindah ke model lain tanpa sanitization. Kedua, uji apakah query classifier bisa dimanipulasi untuk mengirim request ke model yang salah. Ketiga, cek apakah model publik dan privat punya permission tool yang berbeda sesuai prinsip least privilege. Gunakan checklist 7 titik di artikel ini sebagai panduan awal.
Apakah tool seperti Copilot X dan Cursor sudah punya mitigasi untuk serangan ini?
Sejauh ini, vendor AI coding assistant fokus pada optimasi performa dan biaya melalui multi-model routing. Dokumentasi publik tentang mitigasi cross-model injection masih minimal. Tim security enterprise sebaiknya tidak mengandalkan vendor untuk perlindungan ini. Terapkan policy engine sendiri dan pastikan context boundary ada di bawah kendali kamu, bukan di kendali vendor.
Referensi lebih lanjut: OWASP Top 10 for LLM Applications, MITRE ATLAS – Prompt Injection, dan NIST AI Risk Management Framework.
