CAPMAS, sebuah upaya bersama dari EPFL dan Swisscom, memungkinkan pengembang memberikan izin dengan cakupan sempit kepada agen anak AI melalui macaroon. Ini memangkas latensi penanganan token sebanyak 30 kali lipat dan menjaga agar JWT pengguna penuh tetap berada di luar jangkauan agen.
Mengapa perubahan ini penting
Ketika sebuah LLM mengorkestrasi alat-alat downstream, tim sering kali memberikan JWT yang sama dengan yang digunakan pengguna saat login kepada agen "anak" yang baru dibuat. JWT adalah blob bertanda tangan yang mencantumkan setiap izin yang dimiliki pengguna—data HR, file proyek, hak admin, dan sebagainya. Jika model berhalusinasi menghasilkan perintah yang merusak, agen anak dapat mengeksekusinya dengan otoritas penuh pengguna. Satu kesalahan dapat mengekspos data seluruh organisasi.
Kekurangan dari solusi sementara saat ini
Pembuatan (minting) token sempit sesuai permintaan dengan alur pertukaran token RFC 8693 menambah beberapa putaran (round-trips) ke sistem IAM, meningkatkan lalu lintas jaringan, dan menimbulkan latensi yang nyata. Tim yang menjalankan banyak agen berumur pendek akan segera merasakan beban kerja (overhead) yang melumpuhkan.
Cara kerja CAPMAS
CAPMAS membagi pemberian izin menjadi dua tahap:
- Pengodean di sisi IAM – Layanan IAM menjalankan pengode (encoder) yang menerjemahkan permintaan bahasa alami (misalnya, "daftar file di folder keuangan") menjadi sekumpulan hak istimewa (privileges) yang sesuai.
- Pembuatan macaroon – Hak istimewa tersebut menjadi caveats di dalam sebuah macaroon, format token fleksibel yang memungkinkan agen downstream menambahkan batasan lebih lanjut tetapi tidak pernah menghapus batasan yang sudah ada.
Saat agen menerima macaroon, ia dapat memperketat cakupannya—misalnya, membatasi permintaan daftar file ke subdirektori—tetapi ia tidak dapat memperluasnya. Pada setiap lompatan (hop), layanan IAM memvalidasi irisan dari semua caveat, menjamin bahwa tidak ada agen yang melampaui izin asli.
Angka performa yang berbicara sendiri
- Kecepatan – CAPMAS memproses permintaan izin dalam waktu kurang dari 20 ms, kira-kira 30 × lebih cepat daripada pertukaran RFC 8693.
- Akurasi – Dalam tolok ukur (benchmark) dengan katalog alat yang besar, LLM standar melewatkan 53% hak istimewa yang dibutuhkannya. CAPMAS mencapai akurasi 90,9% dengan tingkat kegagalan hanya 2,1%.
- Bandwidth – Karena macaroon hanya membawa sekumpulan caveat akhir, data yang dipertukarkan hanya sebagian kecil dari apa yang dibutuhkan oleh alur pertukaran token penuh.
Alur kerja adopsi yang pragmatis
- Filter awal permintaan – Ubah maksud bahasa alami pengguna menjadi daftar izin (allowlist) top-k sebelum orkestrator menyentuh katalog alat.
- Segel daftar izin – Kodekan daftar izin tersebut ke dalam macaroon yang tidak dapat diperluas oleh agen anak.
- Verifikasi di layanan – Biarkan layanan target meminta IAM untuk menghitung irisan dari semua caveat sebelum memproses permintaan tersebut.
Langkah-langkah ini menggantikan pola "memberikan kunci rumah seluruhnya kepada anak" dengan model "menyerahkan kunci sekali pakai dengan cakupan terbatas".
Apa yang tidak diperbaiki oleh CAPMAS
Kerangka kerja ini tidak menghentikan serangan injeksi prompt (prompt-injection), di mana penyerang memanipulasi prompt LLM untuk menyuntikkan perintah berbahaya. Perlindungannya mencakup agen yang "jujur tapi penasaran" (honest-but-curious) dan LLM yang tidak tepercaya yang mungkin bertindak menggunakan JWT penuh. Tim masih memerlukan pertahanan terpisah—sanitasi input, sandboxing, atau guardrails tingkat model—untuk menangani ancaman berbasis prompt.
Siapa yang akan diuntungkan
- Pengembang perusahaan (Enterprise developers) yang membangun asisten berbasis AI yang memanggil API internal.
- Tim keamanan yang ingin mengurangi radius dampak (blast radius) dari model yang terkompromi.
- Pemilik produk yang membutuhkan pemeriksaan izin yang cepat dan andal untuk pembuatan agen dengan frekuensi tinggi.
Apa selanjutnya
CAPMAS adalah desain yang diusulkan.
Kesimpulan: Mengganti JWT pengguna penuh dengan macaroon berjangkauan sempit memberi pengembang cara untuk menjaga kejujuran agen AI tanpa harus menanggung penalti latensi dari alur pertukaran token tradisional. Kompensasinya tetap merupakan kebutuhan berkelanjutan akan pengamanan injeksi prompt.
