Setiap perusahaan di Indonesia yang kini memasang chatbot layanan pelanggan, asisten internal berbasis RAG, atau agen AI yang bisa memanggil API pasti pernah bertanya: risiko apa yang harus kami tutup lebih dulu? Daftar OWASP Top 10 for LLM Applications adalah salah satu rujukan yang paling sering dipakai untuk menjawabnya. Edisi 2026 membawa perubahan yang layak dibaca pelan-pelan, bukan hanya karena urutannya bergeser, melainkan karena cara daftar ini disusun ikut berubah.
Artikel ini membedah apa saja yang berubah, mengapa pergeseran itu penting, dan bagaimana tim engineering serta tim keamanan di Indonesia dapat menerjemahkannya menjadi tindakan konkret. Seluruh data di bawah ini dirangkum dari analisis publik para praktisi keamanan; periksa dokumen resmi OWASP GenAI Security Project untuk teks otoritatif.
Metodologi Baru: Konsensus Pakar Bertemu Data Insiden
Perubahan paling mendasar bukan pada daftar risikonya, melainkan pada cara memeringkatnya. Menurut ringkasan berbagai analis, edisi 2026 memakai pendekatan hibrida: sekitar 75% bobot berasal dari konsensus pakar dan praktisi, sedangkan 25% berasal dari korpus insiden nyata yang terdokumentasi secara publik. Dari korpus tersebut, sebanyak 6.639 insiden dilaporkan memiliki informasi yang cukup untuk diklasifikasikan. Satu sumber menyebut korpus awalnya berisi 7.714 insiden.
Artinya, daftar ini bergerak dari sekadar “apa yang menurut pakar berbahaya” menuju “apa yang benar-benar terjadi di lapangan”. Bagi pengambil keputusan, ini membuat daftar lebih mudah dipertanggungjawabkan saat menyusun anggaran keamanan: urutan risiko kini punya jejak bukti, bukan hanya opini.
Catatan: beberapa sumber sekunder mencantumkan tanggal rilis yang berbeda-beda untuk edisi ini, sehingga artikel ini sengaja tidak menyebut satu tanggal pasti. Rujuk langsung situs OWASP untuk versi dan tanggal resminya.
Daftar Sepuluh Risiko Edisi 2026
Berikut urutan yang dilaporkan oleh analisis publik, beserta perubahannya dibanding edisi 2025:
- LLM01 Prompt Injection — tetap di puncak, cakupan diperluas.
- LLM02 Sensitive Information Disclosure — tetap di posisi dua, cakupan diperluas.
- LLM03 Excessive Agency — naik dari posisi 6 ke 3, lompatan terbesar dalam daftar.
- LLM04 Supply Chain — turun satu peringkat, cakupan diperluas.
- LLM05 Data and Model Poisoning — turun satu peringkat.
- LLM06 Unbounded Consumption — naik empat peringkat dari posisi 10.
- LLM07 Misinformation — naik dua peringkat dari posisi 9.
- LLM08 Hidden Context Exposure — nama baru pengganti System Prompt Leakage.
- LLM09 Vector and Embedding Weaknesses — turun satu peringkat, cakupan dipertajam.
- LLM10 Improper Output Handling — turun lima peringkat dari posisi 5.
Delapan dari sepuluh entri berubah posisi. Menurut para analis, justru pola pergeseran inilah yang paling informatif, karena ia menunjukkan ke mana insiden produksi bergerak.
Pergeseran 1: Excessive Agency Menjadi Risiko Utama Era Agen
Excessive Agency melompat tiga peringkat. Risiko ini muncul ketika sistem LLM diberi otonomi berlebih: terlalu banyak tool, izin terlalu luas, atau kemampuan mengeksekusi aksi tanpa pengawasan manusia. Selama chatbot hanya menjawab pertanyaan, dampak kesalahan terbatas pada teks yang keliru. Begitu model dapat memanggil API, menjalankan kode, atau mengubah data produksi, kesalahan atau manipulasi berubah menjadi tindakan nyata.
Ini sejalan dengan tren yang sudah kami bahas di blog ini, mulai dari insiden agen AI yang lepas kendali hingga krisis keamanan protokol MCP. Polanya konsisten: model bukan lagi sekadar generator teks, melainkan aktor dengan hak akses.
Rekomendasi inti
Para analis menekankan prinsip “asumsikan model suatu saat akan gagal”. Konsekuensinya, otorisasi harus ditegakkan di luar model:
- Berikan izin sempit dan spesifik per tugas, bukan akses luas yang permanen.
- Batasi tool yang tersedia bagi agen dan izin turunannya.
- Sertakan identitas pengguna ketika agen bertindak atas nama manusia, agar akses dievaluasi pada saat runtime.
- Gunakan pemeriksaan kebijakan deterministik, bukan keputusan yang diserahkan kepada model.
- Simpan catatan audit yang memuat identitas, kebijakan, dan konteks keputusan.
- Cadangkan persetujuan manusia untuk aksi berdampak tinggi atau tak dapat dibatalkan, saat peninjauan memang bermakna.
Pergeseran 2: Unbounded Consumption, Ketika Tagihan Jadi Vektor Serangan
Unbounded Consumption naik empat peringkat. Alasannya mudah dipahami oleh siapa pun yang pernah melihat tagihan API LLM membengkak: permintaan tak terkendali dapat menyebabkan denial of service sekaligus kerugian finansial. Bagi perusahaan Indonesia dengan anggaran terukur, ini bukan risiko abstrak. Satu agen yang terjebak dalam loop pemanggilan tool dapat menghabiskan anggaran bulanan dalam hitungan jam.
Kontrol dasarnya sederhana namun sering terlewat: batas laju per pengguna dan per agen, plafon biaya harian, batas jumlah langkah dalam satu eksekusi, serta saklar darurat (kill switch) yang dapat dioperasikan tanpa menunggu deployment baru.
Pergeseran 3: Dari System Prompt Leakage ke Hidden Context Exposure
Penggantian nama ini lebih dari kosmetik. Edisi sebelumnya fokus pada bocornya system prompt. Edisi 2026 memperluas perhatian ke seluruh konteks tersembunyi yang ikut masuk ke jendela konteks model: dokumen hasil retrieval, memori agen, respons tool, dan state aplikasi. Dalam sistem RAG korporat, ini berarti pertanyaan pentingnya bukan lagi “apakah system prompt kami bocor?”, melainkan “dokumen mana yang dapat ditarik ke konteks oleh pengguna yang tidak berhak melihatnya?”.
Implikasinya langsung ke kontrol akses di lapisan retrieval: filter izin harus diterapkan pada saat pencarian vektor, bukan setelah jawaban dihasilkan.
Yang Turun Peringkat Bukan Berarti Aman
Improper Output Handling turun lima peringkat, dan Supply Chain serta Data and Model Poisoning turun satu. Penurunan peringkat dalam daftar yang dipengaruhi data insiden berarti risiko lain tumbuh lebih cepat atau tercatat lebih banyak, bukan bahwa kerentanannya hilang. Output model yang diteruskan mentah ke browser, shell, atau database tetap merupakan jalan klasik menuju XSS, injeksi perintah, dan SQL injection. Tim web dan mobile yang mengintegrasikan LLM ke aplikasi tetap wajib memperlakukan keluaran model sebagai input tak tepercaya.
Pendamping: Agent Control Standard
Bersamaan dengan daftar ini, Cloud Security Alliance mencatat hadirnya spesifikasi pendamping bernama Agent Control Standard (ACS) yang menyediakan tata kelola runtime lewat titik penegakan berbasis guardian agent, observabilitas berbasis OpenTelemetry, dan Agent Bill of Materials (AgBOM) dengan format seperti CycloneDX, SWID, dan SPDX. ACS saat ini masih versi 0.1, sehingga CSA menyarankan perusahaan memperlakukannya sebagai panduan arsitektur, bukan standar yang siap diadopsi penuh.
Menerjemahkan ke Register Risiko Internal
Cara paling praktis memakai daftar ini adalah memetakannya ke register risiko yang sudah ada. Contoh kerangka sederhana untuk mengurutkan prioritas kontrol berdasarkan eksposur sistem Anda sendiri:
RISIKO = {
"LLM03_excessive_agency": {"relevan_jika": "agen punya tool tulis/eksekusi", "kontrol": ["izin per tugas", "policy check deterministik", "approval aksi ireversibel"]},
"LLM06_unbounded_consumption": {"relevan_jika": "ada loop agen / API berbayar", "kontrol": ["rate limit", "plafon biaya", "kill switch"]},
"LLM08_hidden_context": {"relevan_jika": "RAG / memori agen / tool output", "kontrol": ["filter izin saat retrieval", "redaksi konteks", "log akses dokumen"]},
"LLM10_improper_output": {"relevan_jika": "output LLM masuk ke UI/DB/shell", "kontrol": ["encode output", "parameterized query", "allowlist perintah"]},
}
def prioritas(ciri_sistem):
skor = []
for kode, info in RISIKO.items():
if any(k in ciri_sistem for k in info["relevan_jika"].split()):
skor.append(kode)
return skor
Kode di atas hanya ilustrasi untuk memulai diskusi; nilai sebenarnya ada pada wawancara dengan pemilik sistem untuk menjawab: tool apa saja yang bisa dipanggil, data apa yang masuk ke konteks, dan ke mana keluaran model mengalir.
Konteks Hukum dan Tata Kelola di Indonesia
Bagi organisasi di Indonesia, risiko seperti Sensitive Information Disclosure dan Hidden Context Exposure bersinggungan langsung dengan UU Pelindungan Data Pribadi No. 27 Tahun 2022. Bila sistem LLM membocorkan data pribadi pelanggan, kewajiban notifikasi kegagalan pelindungan data (Pasal 46) dapat berlaku terlepas dari apakah penyebabnya manusia atau model. Pengaksesan sistem tanpa hak oleh pihak penyerang juga dapat berimplikasi pada Pasal 30 UU ITE. Selain itu, tenggat kepatuhan peraturan pelaksana PDP yang telah kami bahas di artikel sebelumnya perlu dipertimbangkan dalam jadwal remediasi.
Dari sisi tata kelola, daftar OWASP paling efektif bila dipadukan dengan kerangka manajemen risiko seperti NIST AI RMF dan sistem manajemen AI ISO/IEC 42001. OWASP memberi daftar ancaman teknis; NIST dan ISO memberi struktur proses, peran, dan bukti audit.
Langkah Praktis Minggu Ini
- Inventarisasi semua sistem LLM dan agen yang berjalan, termasuk “shadow AI” yang dipasang tim tanpa sepengetahuan TI.
- Petakan tiap sistem ke sepuluh risiko di atas; mulai dari Excessive Agency, Unbounded Consumption, dan Hidden Context Exposure karena ketiganya bergerak naik.
- Pindahkan otorisasi keluar dari prompt: instruksi “jangan lakukan X” di system prompt bukan kontrol keamanan.
- Pasang batas biaya dan laju pada setiap agen, lengkap dengan alarm dan saklar darurat.
- Audit lapisan retrieval: pastikan filter izin dokumen berlaku sebelum konteks sampai ke model.
- Uji secara berkala dengan skenario adversarial, bukan sekali menjelang peluncuran.
Penutup
Pesan terbesar dari edisi 2026 adalah bahwa risiko AI bergerak dari “apa yang dikatakan model” ke “apa yang dapat dilakukan model”. Prompt injection tetap di puncak, tetapi dampaknya ditentukan oleh seberapa banyak hak akses yang Anda titipkan kepada sistem. Mengendalikan hak akses, biaya, dan konteks yang terlihat oleh model akan memberi pengurangan risiko lebih besar daripada upaya menyempurnakan kalimat di dalam prompt.
Siberindo membantu organisasi memetakan risiko sistem AI, menguji ketahanan agen, dan menyusun tata kelola yang selaras dengan regulasi Indonesia. Jika tim Anda sedang menyiapkan atau sudah menjalankan agen AI di produksi, ini saat yang tepat untuk meninjau ulang register risikonya.
