Berapa Banyak Kebenaran Akses Patut Diberi kepada Ejen AI? Persoalan Baharu yang Syarikat Paling Enggan Hadapi tetapi Tidak Dapat Dielakkan

Seorang jurutera di sebuah syarikat perisian di Cyberjaya, demi membolehkan pembantu AI dalaman menyemak status pesanan, dengan mudah memberikannya kebenaran baca-sahaja kepada pangkalan data. Munasabah sahaja.

Dua bulan kemudian, pengurus produk mahu pembantu itu turut membantu mengemas kini nota pesanan. Jurutera itu berfikir sejenak, lalu menambah kebenaran tulis. Masih boleh diterima juga.

Sebulan selepas itu, ada yang bertanya sama ada boleh membenarkannya terus memproses bayaran balik. Barulah ketika itu ada orang teringat untuk bertanya: jadi sekarang, akaun pembantu ini sebenarnya boleh buat apa?

Tiada siapa yang mampu menjawab.

Latar Belakang

Laluan pelaksanaan AI beberapa tahun ini hampir semuanya sama: mula dengan sembang soal jawab (baca-sahaja), kemudian penjanaan kandungan (tidak menyentuh sistem), lalu mula menyambung alat (boleh menyemak), dan akhirnya mula melaksanakan tindakan (boleh mengubah).

Dalam tiga peringkat pertama, isu kebenaran tidak ketara. Menjelang peringkat keempat, sifatnya berubah sepenuhnya — ejen AI menjadi 'pelaku' yang mengendalikan sistem syarikat, sedangkan ia bukan pekerja dan bukan juga akaun perkhidmatan tradisional.

Akaun perkhidmatan (service account) tradisional mempunyai corak tingkah laku yang jelas dan tetap: menjalankan proses kelompok setiap pukul tiga pagi, dengan apa yang perlu dilakukan sudah dikodkan tegar dalam program. Ejen AI tidak begitu. Ia memutuskan alat mana yang hendak dipanggil dan data mana yang hendak diubah berdasarkan input, dan ruang tingkah lakunya begitu luas sehingga tidak dapat disenaraikan sepenuhnya.

Di situlah masalahnya. Rangka kerja tadbir urus akses sedia ada direka untuk 'program yang tingkah lakunya boleh diramal' dan 'manusia yang mempunyai kos psikologi'. Ejen bukan kedua-duanya.

Perkara Utama Kali Ini

Pada pandangan saya, tadbir urus akses dalam era ejen mempunyai empat isu reka bentuk yang mesti ditangani:

• Identiti bebas: ejen mesti mempunyai akaun dan kelayakannya sendiri, dan tidak boleh meminjam identiti pekerja. Ini prasyarat kepada semua kawalan seterusnya.
• Kebenaran minimum dan tempoh had: berikan hanya kebenaran yang diperlukan untuk menyiapkan tugas, dan sedaya upaya berikan kelayakan sementara yang mempunyai tempoh had, bukan kunci yang sah untuk tempoh yang panjang.
• Pengasingan tugas diterapkan pada akaun bukan manusia: satu ejen tidak sepatutnya memiliki kebenaran untuk 'mewujudkan' dan 'meluluskan' perkara yang sama serentak. Peraturan ini sepatutnya lebih ketat bagi ejen berbanding manusia.
• Jejak audit lengkap: siapa yang mencetuskan, berdasarkan apa, apa yang diubah, dan sama ada ada orang yang meluluskannya. Item keempat inilah yang paling kerap tertinggal.

Alat yang menangani kebenaran ERP dan pengasingan tugas di pasaran (contohnya Pathlock) asalnya direka untuk manusia, dan kini menghadapi masalah yang sama: bagaimana pangkalan peraturan SoD mereka hendak merangkumi pelaku bukan manusia. Ini masih peringkat di mana seluruh industri sedang meraba-raba.

Analisis Kesan Pasaran

Untuk pengguna di Malaysia: Perubahan yang akan dirasai oleh pekerja biasa ialah 'ejen sering berkata ia tidak dapat melakukannya'. Ini kedengaran seperti kekurangan fungsi, tetapi banyak kali ia sebenarnya reka bentuk yang disengajakan.

Saya rasa syarikat perlu menjelaskan sebab perkara ini kepada pekerja. Jika tiada siapa yang menerangkannya, reaksi pekerja ialah memintasnya — membuka skrip sendiri, menarik keluar satu set data sendiri untuk kegunaan sendiri. Itulah risiko keselamatan yang sebenar. Jika reka bentuk kebenaran menjadikan kerja yang sah terlalu menyakitkan, manusia pasti akan mencari jalan untuk memintasnya.

Untuk aplikasi perniagaan: Syarikat di Malaysia mempunyai dua kelemahan struktur yang akan diperbesar oleh isu ini.

Pertama ialah kebenaran yang hanya ditambah dan tidak pernah dikurangkan selama bertahun-tahun. Pengurusan kebenaran di kebanyakan syarikat ialah 'tambah apabila perlu, padam hanya apabila berhenti kerja', dan setelah terkumpul selama belasan tahun, sekadar memahami keadaan semasa pun sudah menjadi kerja besar. Menambah ejen di atas asas sebegini sama seperti membina bangunan di atas asas yang reput.

Kedua ialah tanggungjawab dan kuasa yang kabur antara IT dan unit operasi. Siapa sebenarnya yang patut memutuskan 'ejen ini patut ada kebenaran apa'? IT rasa itu urusan unit operasi, unit operasi pula rasa itu kepakaran IT. Akhirnya tiada siapa yang memutuskan, jadi beri banyak dahulu.

Pendekatan praktikal ialah mewujudkan sebuah 'daftar ejen': setiap ejen AI yang dilancarkan mesti mendaftarkan tujuan, kebenaran yang dimiliki, pengurus unit operasi yang bertanggungjawab, dan kitaran semakan. Ini tidak memerlukan pembelian sistem — sehelai hamparan pun sudah boleh memulakannya, tetapi ia memaksa keluar persoalan yang paling penting — setiap ejen mesti mempunyai seorang penanggungjawab manusia.

Untuk pembangun: Tiga prinsip reka bentuk yang saya rasa patut dijadikan peraturan tegas.

Pertama, kebenaran tulis dimatikan secara lalai. Apabila ejen dilancarkan, berikan hanya kebenaran baca; fungsi tulis mesti dimohon dan dinilai secara berasingan. Ini bertentangan dengan tabiat pembangunan biasa (beri kebenaran penuh dahulu supaya mudah diuji, kemudian tarik balik), tetapi persekitaran ujian dan persekitaran produksi ejen sering berkongsi data yang sama, dan 'tarik balik nanti' selalunya tidak pernah berlaku.

Kedua, tindakan yang merosakkan mesti sentiasa diluluskan oleh manusia. Memadam, membayar balik, menghantar e-mel kepada pelanggan luar, mengubah jumlah — kategori tindakan ini patut direka sebagai 'ejen bersedia, manusia tekan sahkan'. Ini bukan kerana tidak mempercayai AI, tetapi kerana kos kesilapan bagi tindakan ini tidak simetri: kos menekan sahkan sekali lagi amat rendah, kos menghantar satu e-mel salah kepada pelanggan amat tinggi.

Ketiga, rekodkan juga 'penolakan'. Kebanyakan sistem hanya merekodkan operasi yang berjaya. Tetapi apa yang cuba dilakukan oleh ejen namun disekat oleh kebenaran ialah isyarat yang amat bernilai — ia mungkin bermakna serangan suntikan prompt, atau mungkin bermakna reka bentuk kebenaran anda tidak sepadan dengan keperluan sebenar. Kedua-duanya perlu dilihat oleh manusia.

Aliran Perkembangan Masa Depan

Saya rasa tiga perkara akan berlaku.

Pertama, 'identiti ejen' akan menjadi kategori identiti yang tersendiri. Sistem pengurusan identiti sekarang terbahagi kepada 'manusia' dan 'akaun perkhidmatan', dan ejen tidak tergolong sepenuhnya dalam mana-mana kategori. Produk IAM masa depan sepatutnya memperkenalkan jenis identiti ejen yang khusus, dengan pengisytiharan tujuan, sempadan tingkah laku dan tempoh sah.

Kedua, alat tadbir urus akses akan mula memasukkan ejen ke dalam analisis SoD. Ini jurang produk yang jelas bagi vendor sedia ada, dan juga peluang bagi syarikat baharu.

Ketiga, kawal selia akan menyusul, tetapi bermula daripada kewangan dan perubatan dahulu. Kedua-dua industri ini paling ketat dalam menuntut 'siapa yang membuat keputusan', dan akan menjadi kumpulan pertama yang dikehendaki menjelaskan reka bentuk kebenaran ejen.

Saya ingin menambah satu pemerhatian yang agak berhati-hati: perbincangan tentang tadbir urus ejen di pasaran sekarang terlalu berat dengan bahasa teknikal — bercakap tentang OAuth scope, sandbox, policy engine. Tetapi apa yang sebenarnya menyekat syarikat selalunya masalah yang lebih awal: tiada siapa yang tahu berapa banyak ejen yang sebenarnya berjalan dalam syarikat. Ini masalah yang sama dengan shadow IT sepuluh tahun lalu, dan penyelesaiannya juga sama, iaitu buat inventori dahulu.

TheAI Academy — Rumusan dan Ulasan

Kembali kepada contoh syarikat di Cyberjaya tadi. Apa yang akhirnya mereka lakukan sangat mudah: menukar akaun pembantu daripada akaun perkhidmatan berkongsi kepada akaun khusus, menukar fungsi bayaran balik kepada 'pembantu bersedia, khidmat pelanggan mengesahkan', dan mendaftarkan semua ejen ke dalam satu borang kongsi.

Mengambil masa dua minggu, tanpa membeli sebarang alat.

Ulasan: Bagi hal kebenaran ejen, masa terbaik ialah sebelum ia dilancarkan, dan masa kedua terbaik ialah sekarang. Jika menunggu sehingga berlaku masalah barulah mereka bentuk, apa yang perlu anda tangani bukan lagi sekadar masalah teknikal.

Cadangan khusus untuk pembaca di Malaysia, tiga perkara yang boleh dibuat minggu depan:

Pertama, buat satu inventori ejen. Berapa banyak ejen AI sedang berjalan dalam syarikat sekarang? Masing-masing menggunakan akaun apa? Siapa yang bertanggungjawab? Sekadar menyenaraikan jadual ini pun, kebanyakan syarikat akan mendapati satu dua benda yang tiada siapa ingat masih berjalan.

Kedua, tarik balik kebenaran tulis dan mohon semula. Ini akan menerima rungutan, tetapi berbaloi. Selepas ditarik balik, anda akan mendapati sesetengah ejen sebenarnya tidak pernah menggunakan kebenaran tulisnya — itu risiko semata-mata tanpa sebarang nilai yang sepadan.

Ketiga, lantik seorang penanggungjawab manusia bagi setiap ejen. Bukan IT, tetapi pengurus unit operasi yang sebenarnya menggunakan ejen itu. Orang ini mesti mampu menjawab 'kenapa ejen ini memerlukan kebenaran ini'. Yang tidak mampu dijawab, itulah yang patut ditarik balik.

Bacaan lanjut: Sebelum melaksanakan ejen AI, tanya dahulu berapa versi data yang ada membincangkan persediaan aspek data, AI Masuk ke Bilik Audit membincangkan sempadan automasi kawalan dalaman, manakala Kebolehcerapan dan Tadbir Urus Ejen AI membincangkan pemantauan selepas dilancarkan.

Sumber Rujukan

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• Penerangan produk rasmi Pathlock

Disusun berdasarkan maklumat awam, dengan sumber rasmi sebagai rujukan muktamad; artikel ini merupakan cadangan umum, reka bentuk kawalan bagi persekitaran tertentu hendaklah mengikut penilaian risiko masing-masing.