Apakah agen AI sebaiknya memakai akun khusus atau meminjam akun karyawan?

Wajib akun khusus. Meminjam akun karyawan punya tiga masalah: jejak audit tak bisa membedakan aksi manusia atau agen, agen ikut mati atau jadi akun yatim setelah karyawan resign, dan cakupan hak pasti terlalu besar (hak karyawan memang lebih banyak daripada yang dibutuhkan agen). Ini prinsip paling dasar dan paling sering dilanggar.

Apakah pemisahan tugas masih berlaku untuk agen AI?

Justru lebih berlaku. Manusia berbuat buruk punya beban psikologis dan batas kecepatan, agen tidak — sebuah agen yang sekaligus bisa membuat pemasok dan menyetujui pembayaran akan merusak jauh lebih cepat saat salah atau dimanipulasi. Saat merancang hak akses agen, pemisahan tugas seharusnya lebih ketat daripada untuk manusia, bukan lebih longgar.

Apa saja yang harus dicatat jejak audit agen?

Setidaknya empat hal: aksi ini dipicu siapa (agen mana, versi mana), berdasarkan input apa, apa yang sebenarnya diubah, dan apakah ada yang menyetujui. Poin keempat paling sering terlewat, padahal ia menentukan apakah pertanggungjawaban bisa dijelaskan saat terjadi masalah.

Apakah UKM perlu seketat itu?

Skalanya boleh dikecilkan, prinsipnya tak boleh dihilangkan. UKM setidaknya harus melakukan tiga hal: agen memakai akun mandiri, hak jenis tulis mati secara bawaan (biarkan hanya baca dulu), dan nominal atau kuantitas yang melampaui ambang wajib disetujui manusia. Tiga hal ini tak butuh membeli alat apa pun.

Berapa Banyak Hak Akses yang Boleh Dimiliki Agen AI? Soal Baru yang Paling Enggan Dihadapi Perusahaan, tapi Tak Terhindarkan

Ketika AI bergeser dari menjawab pertanyaan menjadi menjalankan aksi, sebuah pertanyaan lama mendadak jadi sangat baru: akun ini bisa melakukan apa saja? Kebanyakan perusahaan memberi agen hak akses "lebih besar dulu biar mudah bekerja", lalu tak ada kelanjutannya. Tulisan ini membahas bagaimana tata kelola akses di era agen harus dirancang, dan kenapa konsep lama pemisahan tugas mendadak penting lagi.

Seorang engineer di sebuah perusahaan software di Bandung, agar asisten AI internal bisa mengecek status pesanan, dengan santai memberinya hak akses baca-saja ke basis data. Sangat masuk akal.

Dua bulan kemudian, product manager berharap asisten itu juga bisa membantu memperbarui catatan pesanan. Sang engineer berpikir sejenak, lalu menambahkan hak tulis. Masih cukup masuk akal juga.

Sebulan berikutnya, ada yang bertanya apakah asisten itu bisa langsung memproses pengembalian dana. Barulah saat itu seseorang teringat untuk bertanya: jadi sekarang akun asisten ini sebenarnya bisa melakukan apa saja?

Tidak ada yang bisa menjawab.

Latar Belakang

Jalur penerapan AI beberapa tahun ini hampir selalu sama: mulai dari tanya-jawab chat (hanya baca), lalu pembuatan konten (tidak menyentuh sistem), kemudian mulai menyambung alat (bisa mengecek), dan akhirnya mulai menjalankan aksi (bisa mengubah).

Pada tiga tahap pertama, soal hak akses tidak terasa. Sampai tahap keempat, sifatnya berubah total — agen AI berubah menjadi "aktor" yang mengoperasikan sistem perusahaan, padahal ia bukan karyawan, bukan pula akun layanan tradisional.

Akun layanan (service account) tradisional punya pola perilaku yang jelas dan tetap: setiap pukul tiga dini hari menjalankan satu batch, apa yang dikerjakannya sudah dipatok mati dalam kode. Agen AI tidak begitu. Ia menentukan alat mana yang dipanggil dan data mana yang diubah berdasarkan input, dengan ruang perilaku yang terlalu luas untuk didaftar habis.

Di situlah masalahnya. Kerangka tata kelola akses yang ada dirancang untuk "program yang perilakunya bisa diprediksi" dan "manusia yang punya beban psikologis". Agen bukan keduanya.

Poin Utama

Menurut saya, tata kelola akses di era agen punya empat persoalan desain yang wajib ditangani:

Identitas mandiri: agen harus punya akun dan kredensial sendiri, tidak boleh meminjam identitas karyawan. Ini prasyarat semua kontrol selanjutnya.
Hak minimal dan berbatas waktu: hanya beri hak yang diperlukan untuk menuntaskan tugas, dan sebisa mungkin beri kredensial sementara yang berbatas waktu, bukan kunci yang berlaku permanen.
Pemisahan tugas diterapkan ke akun non-manusia: satu agen tidak boleh sekaligus punya hak "membuat" dan "menyetujui" hal yang sama. Aturan ini seharusnya lebih ketat bagi agen dibanding bagi manusia.
Jejak audit yang lengkap: siapa yang memicu, berdasarkan apa, apa yang diubah, dan apakah ada yang menyetujui. Poin keempat paling sering terlewat.

Alat yang menangani hak akses ERP dan pemisahan tugas di pasaran (misalnya Pathlock) semula dirancang untuk manusia, dan kini menghadapi masalah yang sama: bagaimana basis aturan pemisahan tugas mereka bisa mencakup aktor non-manusia. Ini masih tahap yang sedang diraba-raba seluruh industri.

Analisis Dampak Pasar

Bagi pengguna di Indonesia: perubahan yang akan dirasakan karyawan biasa adalah "agen sering bilang tidak bisa melakukannya". Kedengarannya seperti fitur yang kurang, padahal sering kali itu memang desain yang disengaja.

Menurut saya perusahaan perlu menjelaskan alasannya kepada karyawan. Kalau tak ada yang menjelaskan, reaksi karyawan adalah mengakalinya — bikin skrip sendiri, tarik sendiri sebagian data untuk diolah. Itulah risiko keamanan yang sebenarnya. Kalau desain hak akses membuat pekerjaan yang sah jadi terlalu menyakitkan, orang pasti akan mencari jalan pintas.

Bagi penerapan di perusahaan: perusahaan Indonesia punya dua kelemahan struktural yang akan diperbesar oleh topik ini.

Pertama, hak akses bertahun-tahun hanya ditambah, tak pernah dikurangi. Pengelolaan akses di banyak perusahaan adalah "kalau perlu tambah, kalau resign baru hapus". Menumpuk belasan tahun, sekadar memahami kondisi saat ini saja sudah pekerjaan besar. Menambahkan agen di atas fondasi seperti ini sama saja membangun gedung di atas fondasi rapuh.

Kedua, batas wewenang antara IT dan unit bisnis kabur. "Hak akses apa yang seharusnya dimiliki agen ini" sebenarnya harus diputuskan siapa? IT merasa itu urusan unit bisnis, unit bisnis merasa itu keahlian IT. Ujungnya tak ada yang memutuskan, beri saja hak besar dulu.

Cara praktisnya adalah membuat "daftar registrasi agen": setiap agen AI yang naik ke produksi harus dicatat tujuannya, hak akses yang dimilikinya, kepala unit bisnis yang bertanggung jawab, serta siklus peninjauannya. Ini tidak perlu membeli sistem, satu spreadsheet sudah bisa jadi awal, tetapi ia memaksa munculnya pertanyaan paling penting — setiap agen harus punya satu penanggung jawab manusia.

Bagi pengembang: tiga prinsip desain yang menurut saya harus dijadikan aturan keras.

Pertama, hak tulis mati secara bawaan. Saat agen naik ke produksi, beri hanya hak baca; fitur tulis harus diajukan dan dievaluasi satu per satu. Ini berlawanan dengan kebiasaan pengembangan umum (beri hak penuh dulu supaya mudah dites, baru dikurangi nanti), tetapi lingkungan uji dan lingkungan produksi agen sering berbagi data yang sama, dan "dikurangi nanti" biasanya tidak pernah terjadi.

Kedua, aksi yang bersifat merusak wajib disetujui manusia. Menghapus, mengembalikan dana, mengirim email ke pelanggan eksternal, mengubah nominal — jenis aksi ini harus didesain "agen menyiapkan, manusia menekan konfirmasi". Ini bukan soal tidak percaya AI, melainkan karena biaya kesalahan hal-hal ini asimetris: biaya menekan konfirmasi sekali lagi sangat rendah, biaya salah kirim satu email ke pelanggan sangat tinggi.

Ketiga, catat juga "penolakan". Kebanyakan sistem hanya mencatat operasi yang berhasil. Namun apa yang coba dilakukan agen tetapi diblokir oleh hak akses adalah sinyal yang sangat berharga — bisa menandakan serangan prompt injection, bisa juga menandakan desain hak akses Anda tidak sesuai kebutuhan nyata. Keduanya perlu ditinjau manusia.

Tren Perkembangan ke Depan

Menurut saya tiga hal akan terjadi.

Pertama, "identitas agen" akan menjadi kategori identitas tersendiri. Sistem manajemen identitas saat ini membagi "manusia" dan "akun layanan", sedangkan agen tak sepenuhnya masuk salah satunya. Produk IAM masa depan mestinya akan memunculkan tipe identitas agen khusus, lengkap dengan deklarasi tujuan, batas perilaku, dan masa berlaku.

Kedua, alat tata kelola akses akan mulai memasukkan agen ke dalam analisis pemisahan tugas. Ini celah produk yang jelas bagi vendor lama, sekaligus peluang bagi pemain baru.

Ketiga, regulasi akan menyusul, tapi mulai dari keuangan dan kesehatan. Kedua industri ini paling ketat menuntut "keputusan itu dibuat oleh siapa", dan akan menjadi kelompok pertama yang diminta menjelaskan desain hak akses agen.

Saya ingin menambahkan satu pengamatan yang agak menahan diri: diskusi soal tata kelola agen di pasaran saat ini sangat kental nuansa teknis — bicara OAuth scope, sandbox, policy engine. Namun yang sering benar-benar menghambat perusahaan justru persoalan yang lebih hulu: tidak ada yang tahu sebenarnya ada berapa agen yang berjalan di dalam perusahaan. Ini jenis masalah yang sama dengan shadow IT sepuluh tahun lalu, dan solusinya pun sama, mulai dari pemetaan.

Kesimpulan & Komentar TheAI Academy

Kembali ke contoh Bandung di awal tadi. Yang akhirnya mereka lakukan sederhana: mengganti akun asisten dari akun layanan bersama menjadi akun khusus, mengubah fitur pengembalian dana menjadi "asisten menyiapkan, tim layanan pelanggan mengonfirmasi", serta mencatat semua agen ke dalam satu formulir bersama.

Butuh dua minggu, tanpa membeli alat apa pun.

Komentar: soal hak akses agen, waktu terbaik adalah sebelum ia naik ke produksi, waktu terbaik kedua adalah sekarang. Menunggu sampai ada insiden baru mendesainnya berarti yang Anda hadapi bukan lagi sekadar masalah teknis.

Saran konkret untuk pembaca Indonesia, tiga hal yang bisa dikerjakan minggu depan:

Pertama, lakukan pemetaan agen sekali. Ada berapa agen AI yang sedang berjalan di perusahaan sekarang? Masing-masing memakai akun apa? Siapa penanggung jawabnya? Sekadar membuat daftar ini saja, kebanyakan perusahaan akan menyadari ada satu-dua hal yang tak diingat siapa pun tetapi masih berjalan.

Kedua, tarik kembali hak tulis, lalu ajukan ulang. Ini akan diomeli, tapi sepadan. Setelah ditarik, Anda akan menemukan hak tulis sejumlah agen ternyata tak pernah dipakai sama sekali — itu murni risiko tanpa nilai yang sepadan.

Ketiga, tunjuk penanggung jawab manusia untuk tiap agen. Bukan IT, tetapi kepala unit bisnis yang benar-benar memakai agen tersebut. Orang ini harus bisa menjawab "kenapa agen ini butuh hak akses ini". Yang tak bisa dijawab, itulah yang harus ditarik.

Bacaan lanjutan: Sebelum menerapkan agen AI, tanyakan dulu berapa versi data Anda membahas persiapan sisi data, AI masuk ruang audit membahas batas otomatisasi kontrol internal, sedangkan Observabilitas dan tata kelola agen AI membahas pemantauan setelah naik ke produksi.

Sumber

Dirangkum dari informasi publik, mengacu pada sumber resmi; artikel ini merupakan saran umum, desain kontrol untuk lingkungan spesifik silakan disesuaikan dengan penilaian risiko masing-masing.