Autentikasi memeriksa siapa Anda; otorisasi memutuskan apa yang boleh Anda lakukan. Semakin banyak aplikasi bertenaga AI yang memverifikasi identitas pengguna sekali saat login dan kemudian membiarkan agen yang mendasarinya bertindak pada sumber daya apa pun selama sisa sesi, yang secara efektif memberikannya "cek kosong." Desain tersebut membuka pintu bagi kebocoran data yang tidak disengaja, email yang tidak diinginkan, atau bahkan pembaruan database yang merusak, dan risikonya meningkat setiap kali asisten AI dapat memanggil berbagai alat dengan latensi milidetik.

Mengapa kesalahan ini terus terjadi

Sebagian besar pengembang AI menganggap layar login sebagai satu-satunya gerbang keamanan. Kode meminta kata sandi atau token, menandai sesi sebagai "terautentikasi," dan kemudian berasumsi bahwa setiap permintaan berikutnya aman. Dalam aplikasi web tradisional, klik lambat pengguna manusia memberikan titik pembatasan alami; manusia akan berhenti sejenak sebelum menekan "hapus." Namun, agen AI dapat mengirimkan lusinan panggilan alat dalam hitungan detik. Jika platform hanya bertanya "Apakah pengguna sudah login?" setiap panggilan akan mewarisi hak istimewa yang sama tanpa batasan.

Penyebab utamanya adalah kenyamanan. Tim sering kali menyediakan satu akun layanan berjangka panjang untuk seluruh aplikasi agar kode tidak perlu mengelola banyak token atau scope. Akun tersebut biasanya memiliki izin yang luas—baca, tulis, hapus—di seluruh proyek. Ketika asisten AI berjalan di dalam sesi tersebut, ia secara otomatis mewarisi hak-hak tersebut, terlepas dari apakah tugas saat ini benar-benar membutuhkannya.

Apa yang dipertaruhkan

  • Paparan data – Agen yang dapat membaca file apa pun setelah pengguna login mungkin secara tidak sengaja menarik dokumen rahasia ke dalam respons yang kemudian dibagikan ke luar organisasi.
  • Tindakan yang tidak disengaja – Pembantu AI seorang insinyur dukungan dapat mengeksekusi kueri SQL mentah terhadap database produksi hanya karena sesi insinyur tersebut masih aktif, meskipun kueri tersebut tidak terkait dengan tiket yang sedang ditangani.
  • Kepatuhan regulasi – Banyak aturan perlindungan data mengharuskan akses dibatasi pada kebutuhan minimum. Model izin menyeluruh dapat melanggar prinsip-prinsip tersebut dan memicu audit atau denda.
  • Biaya operasional – Kesalahan yang menghapus atau mengubah catatan memaksa tim untuk membatalkan perubahan, menyelidiki penyebab utama, dan membangun kembali kepercayaan dengan pengguna—yang semuanya membuang waktu dan uang.

Langkah yang hilang: otorisasi per-tindakan

Otorisasi harus dievaluasi pada setiap "pintu" di dalam sistem, bukan hanya di pintu masuk depan. Pertanyaannya berubah dari "Siapa ini?" menjadi "Bolehkah tindakan spesifik ini pada sumber daya spesifik ini dilakukan sekarang?" Menerapkan pemeriksaan tersebut tidak memerlukan desain ulang total; hanya memerlukan peralihan dari satu flag sesi ke token berjangka pendek dengan scope tertentu.

Cara kerjanya dalam praktik

  1. Meminta token dengan scope yang ditentukan – Saat agen AI perlu memanggil alat, ia pertama-tama mendapatkan token yang mencantumkan izin tepat yang diperlukan (misalnya, read:ticket, execute:sql_query).
  2. Validasi token untuk setiap panggilan – Sebelum alat dijalankan, layanan memeriksa bahwa token menyertakan scope yang dibutuhkan dan bahwa token tersebut belum kedaluwarsa.
  3. Cocokkan sumber daya dengan scope – Jika permintaan menargetkan proyek atau database tertentu, token harus secara eksplisit memberikan akses ke pengenal tersebut.
  4. Tolak atau izinkan – Jika ada pemeriksaan yang gagal, panggilan ditolak dan agen menerima kesalahan yang dapat ia sampaikan kepada pengguna.

Perbedaan kodenya cukup sederhana. Pendekatan "buruk" mungkin terlihat seperti:

if session.is_authenticated():
    tool.run(params)

Pendekatan "baik" memperluas pemeriksaan tersebut:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Pola kedua menambahkan beberapa baris tetapi memaksa sistem untuk mengajukan pertanyaan yang tepat untuk setiap operasi.

Standar yang mempermudah

Scope OAuth 2.0 sudah menyediakan cara yang diadopsi secara luas untuk membatasi apa yang dapat dilakukan oleh sebuah token. Dengan menerbitkan token akses berjangka pendek yang menyandikan scope seperti project:1234:write atau email:send, pengembang dapat mengandalkan pustaka yang ada untuk melakukan langkah verifikasi.

Rich Authorization Requests (RFC 9396) yang lebih baru memperluas ide ini, memungkinkan klien untuk meminta izin granular pada saat runtime alih-alih mendefinisikan daftar statis sebelumnya. Fleksibilitas tersebut berguna ketika alur kerja AI mungkin perlu menambah atau menghapus kemampuan secara langsung berdasarkan niat pengguna.

Argumen lawan: kesederhanaan versus keamanan

Beberapa tim berpendapat bahwa pemeriksaan per-tindakan menambah latensi dan kompleksitas kode, terutama ketika asisten AI harus memanggil banyak alat secara berturut-turut dengan cepat. Mereka menunjukkan bahwa satu token sesi dapat menghindari beban tambahan (overhead) dalam mengambil dan memvalidasi token baru untuk setiap panggilan. Namun, risikonya adalah paparan penyalahgunaan yang jauh lebih tinggi. Layanan validasi token modern dirancang untuk beroperasi dalam hitungan mikrodetik, dan tambahan perjalanan bolak-balik jaringan (network round-trip) dapat dikelompokkan (batched) atau disimpan dalam cache tanpa mengorbankan prinsip hak istimewa minimum (principle of least privilege). Dalam lingkungan di mana integritas data dan kepatuhan tidak dapat ditawar, biaya performa yang kecil tersebut sebanding dengan pengurangan risiko yang didapat.

Apa yang perlu diperhatikan selanjutnya

  • Adopsi scoped tokens dalam AI SDK – Pantau pembaruan pada toolkit platform AI utama; banyak yang mulai menyediakan fungsi pembantu (helper functions) untuk cakupan (scopes) berbasis OAuth.
  • Framework policy-as-code – Solusi yang sedang berkembang memungkinkan tim untuk mendeklarasikan aturan otorisasi dalam file deklaratif, yang secara otomatis ditegakkan saat runtime.
  • Log audit yang menampilkan keputusan per-tindakan – Seiring dengan semakin banyaknya platform yang mencatat setiap pemeriksaan otorisasi, organisasi akan mendapatkan visibilitas mengenai tindakan AI mana yang diizinkan atau diblokir, yang dapat menjadi dasar penyesuaian kebijakan di masa mendatang.

Kesimpulan

Menganggap sesi yang sudah masuk (logged-in) sebagai izin untuk melakukan apa saja adalah resep bagi konsekuensi yang tidak diinginkan. Dengan memindahkan keputusan otorisasi dari saat login ke setiap panggilan alat secara individual—dan dengan memanfaatkan scoped tokens yang berumur pendek—aplikasi AI dapat mempertahankan kenyamanan agen otonom sambil tetap melindungi data, mematuhi regulasi, dan menghindari kesalahan fatal yang merugikan. Baris kode tambahan tersebut adalah harga kecil untuk sistem yang mengajukan pertanyaan yang tepat setiap kali sebuah tindakan dicoba.