Authorization dalam Aplikasi LLM

• Large Language Model (LLM) adalah sistem yang tidak dapat diprediksi karena memproses input manusia yang tidak pasti, sehingga penerapan prinsip least privilege mutlak diperlukan
• Karena LLM kini benar-benar digunakan untuk berbagai pekerjaan seperti pencarian internal dan otomasi, LLM harus dijalankan hanya dalam "effective permissions" yang diberikan secara minimal agar insiden keamanan dan penyalahgunaan dapat dicegah
• Dalam arsitektur RAG (Retrieval-Augmented Generation), embedding data dan pemeriksaan otorisasi dipisahkan dari sumber data, sehingga diperlukan kontrol akses yang presisi di level resource
• Semakin meningkatnya penggunaan kompleks seperti data/RAG eksternal (3rd party), Agent, dan MCP, lokasi serta cara penerapan otorisasi yang sebenarnya menjadi isu inti keamanan
• Autentikasi berbasis token seperti OAuth memiliki keterbatasan untuk kontrol otorisasi yang rinci per resource, sehingga logika otorisasi yang sebenarnya harus diimplementasikan langsung di layer aplikasi

---

Istilah dan konsep dasar

• Prompt: permintaan pengguna yang dikirim ke LLM (perintah, pertanyaan, dan sebagainya)
• RAG (Retrieval-Augmented Generation): workflow yang melampirkan data tambahan ke prompt untuk meningkatkan akurasi respons LLM (contoh: secara otomatis melampirkan daftar cuti perusahaan)
• Context: data pendukung yang dilampirkan ke prompt (materi terkait yang ditemukan melalui pencarian, dan sebagainya)
• Embedding: representasi vektor numerik dari teks, digunakan untuk pencarian/pencocokan data
• Agent: mesin eksekusi berbasis LLM yang melakukan action sesuai prompt (seperti pemanggilan tool otomatis)
• Tool: fungsi eksternal seperti API/aplikasi yang dapat dipanggil langsung oleh LLM
• Model Context Protocol (MCP): protokol standar akses tool untuk LLM yang diusulkan Anthropic

Prinsip inti model otorisasi LLM

• Golden Rule:

  LLM harus beroperasi hanya dengan hak akses minimum yang benar-benar diperlukan untuk memproses permintaan pengguna

• Pada pengguna manusia, "kelebihan hak akses yang menjadi kebiasaan" masih sampai batas tertentu dapat ditoleransi, tetapi LLM tidak dapat diprediksi, bergerak cepat, dan ketika melakukan kesalahan dapat menimbulkan kerusakan berskala besar.
  → "effective permissions" LLM harus dibatasi pada irisan antara hak akses pengguna, LLM, dan tugas

Menghitung effective permissions

• Effective permissions aplikasi LLM =
  1. hak akses yang dimiliki LLM
  2. hak akses yang dimiliki pengguna
  3. hak akses yang diperlukan oleh tugas yang diminta
     irisan dari ketiga hal ini
• Pengguna "mendelegasikan" perannya kepada LLM (chatbot dan sebagainya),
  tetapi LLM tidak boleh melampaui cakupan hak akses yang dimiliki baik oleh LLM maupun pengguna
• Dijelaskan secara intuitif melalui diagram Venn otorisasi
  • Eksekusi hanya diizinkan ketika hak akses tugas sepenuhnya termasuk dalam irisan tersebut

RAG (Retrieval-Augmented Generation) dan penanganan otorisasi

1. RAG data 1st Party (internal/perusahaan sendiri)

• Contoh: chatbot internal perusahaan mencari "file yang berisi secret key" di source code internal
• Embedding: semua file diubah menjadi vektor dan disimpan di DB, lalu prompt juga diubah menjadi vektor untuk pencocokan berbasis kemiripan
• Lokasi penerapan otorisasi:
  • Segera periksa organisasi pemilik, jenis, repository, dan hak akses pengguna dari "file" yang dikembalikan sebagai hasil pencarian
  • Pastikan pengguna memang dapat mengakses file tersebut (otorisasi level resource)
  • Lakukan pemeriksaan otorisasi di layer aplikasi dalam proses penghubungan embedding ke data sumber
• Memasukkan logika otorisasi ke dalam LLM itu sendiri tidak stabil (karena sifat probabilistiknya, tidak dapat dijamin)
• Ringkasan:
  • Inti RAG adalah menerapkan otorisasi yang kuat per pengguna/per resource setelah embedding dihubungkan kembali ke data asli

2. RAG data 3rd Party (eksternal)

• Memanfaatkan data dari API/sistem eksternal (misalnya wiki, sistem tiket, dan sebagainya) dengan membuat embedding
• Masalah: embedding dan data asli berada di sistem yang berbeda → lokasi penerapan otorisasi menjadi ambigu
• Tiga cara penanganan otorisasi
  1. Mendelegasikan otorisasi ke sistem eksternal (memeriksa hak akses sebenarnya pada tiap request API, tetapi ada masalah respons lambat dan rate limit)
  2. Menyinkronkan ACL (access control list) ke aplikasi (akurasi/keandalan tinggi, tetapi biaya pengelolaan/sinkronisasi ACL meningkat)
  3. Mengimplementasikan ulang logika otorisasi eksternal di dalam sistem internal (beban pengelolaan/sinkronisasi meningkat, kompleksitas logika bertambah)
• Kesimpulan: trade-off soal "lokasi penerapan otorisasi" dan caranya penting sesuai kondisi nyata
  (perlu memilih antara performa-kesederhanaan, biaya pengelolaan-presisi, dan sebagainya)

LLM berbasis agent (AI Agent) dan otorisasi

• Contoh: chatbot melakukan pekerjaan maintenance otomatis seperti menghapus branch repository atau menutup issue
• Dengan MCP (Model Context Protocol), tool (fungsi/API) diekspos ke LLM dengan cara yang terstandarisasi
• Pada setiap request MCP, model effective permissions harus diterapkan
  (irisan hak akses pengguna/agent/tugas)
• Keterbatasan autentikasi berbasis token seperti OAuth
  • Informasi hak akses memang disertakan dalam token, tetapi tidak dapat mencakup otorisasi real-time di level asset/resource
  • Dalam praktiknya, hanya sebagian informasi yang dimasukkan ke token, dan sisanya memerlukan implementasi logika otorisasi terpisah di layer aplikasi

Kesimpulan dan ringkasan praktis

• Dalam lingkungan LLM/RAG/Agent, inti manajemen otorisasi adalah memilih "lokasi dan cara penerapan otorisasi"

• Melalui model effective permissions, batasi agar LLM hanya beroperasi dalam irisan "pengguna + LLM + tugas"

• Token autentikasi seperti OAuth hanya digunakan untuk mengidentifikasi "siapa yang meminta",
  sedangkan verifikasi otorisasi sebenarnya per resource harus selalu dilakukan di aplikasi

• Saat terhubung dengan sistem eksternal,
  1) mendelegasikan otorisasi (performa menurun), 2) sinkronisasi ACL (operasional kompleks), 3) implementasi ulang logika otorisasi (maintenance tinggi)
  dan trade-off lain perlu dipertimbangkan dalam desain

• Ringkasan akhir:

  LLM harus beroperasi hanya dalam hak akses minimum yang benar-benar diperlukan untuk memproses permintaan pengguna,
  dan effective permissions didefinisikan sebagai irisan dari hak akses LLM, hak akses pengguna, dan hak akses tugas
  Verifikasi otorisasi yang sebenarnya harus selalu dilakukan per resource, di layer aplikasi