Ketika perusahaan menambahkan AI agent ke aplikasi bisnis, perhatian biasanya tertuju pada pekerjaan yang dapat dipercepat. AI agent dapat merangkum dokumen, memeriksa transaksi, memperbarui data pelanggan, membuat tiket, atau menjalankan alur kerja secara otomatis.

Namun, setiap kemampuan tersebut hanya dapat berjalan setelah sistem memberikan sesuatu yang lebih sensitif daripada kecerdasan: akses.

AI agent memerlukan identitas untuk masuk ke sistem, izin untuk menggunakan data, serta tools untuk menjalankan tindakan. Ketika ketiga unsur tersebut digabungkan, perusahaan tidak lagi sekadar memasang fitur AI. Perusahaan telah menciptakan identitas non manusia yang dapat bertindak di dalam proses bisnis.

Keputusan ini membawa konsekuensi keamanan yang lebih besar daripada penggunaan chatbot biasa. Chatbot mungkin hanya memberikan jawaban, sedangkan AI agent dapat mengubah kondisi sistem secara langsung.

Risiko Berubah ketika AI Mulai Mengambil Tindakan

Perbedaan paling penting antara chatbot dan AI agent tidak terletak pada kemampuan menghasilkan teks. Perbedaannya terletak pada kewenangan.

Chatbot konvensional umumnya menerima pertanyaan dan memberikan jawaban. AI agent dapat memanggil API, membaca file, mengirim email, membuat transaksi, memperbarui database, atau menjalankan instruksi melalui connector.

Artinya, kesalahan AI tidak lagi berhenti sebagai informasi yang kurang akurat. Kesalahan tersebut dapat diterjemahkan menjadi tindakan operasional.

Apabila AI agent salah memahami permintaan, dampaknya dapat berupa perubahan data. Jika agent dipengaruhi oleh prompt berbahaya, dampaknya dapat berupa pengiriman informasi sensitif. Jika connector disusupi, kredensial resmi yang digunakan agent dapat menjadi jalur masuk ke sistem lain.

Semakin luas kemampuan AI agent, semakin besar pula konsekuensi jika proses pengambilan keputusannya dimanipulasi.

Produktivitas AI Agent Berasal dari Akses

AI agent tidak menjadi berguna hanya karena modelnya mampu bernalar. Nilai bisnis muncul karena agent memperoleh akses terhadap sistem yang sebelumnya hanya dapat digunakan manusia atau aplikasi tertentu.

Akses tersebut dapat mencakup:

• database pelanggan;
• sistem keuangan;
• aplikasi sumber daya manusia;
• penyimpanan dokumen;
• email perusahaan;
• platform komunikasi;
• sistem tiket;
• source code repository;
• infrastruktur cloud;
• API internal dan eksternal;
• workflow automation.

Setiap integrasi membuka kemampuan baru. Pada saat yang sama, setiap integrasi juga menambahkan jalur serangan baru.

Sebuah AI agent yang hanya dapat membaca katalog produk memiliki risiko berbeda dari agent yang dapat memperbarui harga. Agent yang dapat membuat draf email juga memiliki risiko berbeda dari agent yang dapat mengirim pesan tanpa persetujuan manusia.

Oleh sebab itu, pertanyaan keamanan tidak cukup berhenti pada “Apa yang dapat dilakukan AI agent?” Perusahaan juga harus menanyakan: menggunakan identitas siapa, terhadap data apa, melalui tool mana, dan sejauh mana tindakannya dapat dijalankan?

AI Agent Menjadi Identitas Baru di Dalam Sistem

Setiap tindakan dalam sistem bisnis seharusnya dapat dikaitkan dengan identitas yang jelas. Prinsip ini berlaku untuk manusia, aplikasi, service account, maupun AI agent.

Persoalan muncul ketika agent menggunakan akun bersama atau kredensial dengan hak akses luas. Log sistem mungkin hanya menunjukkan bahwa sebuah API dipanggil oleh akun layanan. Namun, sistem tidak dapat menjelaskan pengguna yang memulai tugas, agent yang mengambil keputusan, atau alasan tindakan tersebut dilakukan.

NIST telah menempatkan identitas dan otorisasi software agent sebagai persoalan yang perlu diperhatikan secara khusus. Pembahasannya mencakup identifikasi, otorisasi, audit, non repudiation, serta pengendalian terhadap prompt injection.

Dalam penerapannya, perusahaan perlu membedakan beberapa pola identitas.

AI agent dapat bertindak atas nama pengguna yang sedang aktif. Agent juga dapat memiliki identitas sendiri untuk menjalankan fungsi tertentu. Pada kondisi lain, agent bekerja secara otonom berdasarkan jadwal, event, atau instruksi dari agent lain.

Ketiga pola tersebut memiliki risiko berbeda. Agent yang bekerja atas nama pengguna harus dibatasi oleh kewenangan pengguna tersebut. Agent yang memiliki identitas sendiri harus mempunyai pemilik dan tujuan yang jelas. Sementara itu, agent otonom memerlukan pengawasan lebih ketat karena dapat bertindak tanpa pengguna yang sedang terlibat.

Izin Pengguna Bukan Izin Otomatis bagi AI Agent

Salah satu pendekatan yang terlihat praktis adalah membiarkan AI agent menggunakan seluruh izin pengguna. Cara ini memudahkan integrasi karena agent tidak memerlukan model otorisasi tambahan.

Namun, kewenangan pengguna seharusnya menjadi batas maksimum, bukan izin yang otomatis diwariskan sepenuhnya kepada agent.

Seorang manajer mungkin memiliki akses ke ribuan dokumen karena tanggung jawab pekerjaannya. AI agent yang diminta merangkum satu laporan tidak harus memperoleh akses ke seluruh dokumen tersebut.

Masalah serupa muncul ketika agent menggunakan session pengguna tanpa pembatasan. Selama session masih aktif, agent mungkin dapat menjalankan tindakan lain yang tidak berkaitan dengan tugas awal.

Pemberian akses perlu mempertimbangkan:

• siapa yang meminta tindakan;
• tujuan tugas;
• data yang diperlukan;
• jenis operasi yang diizinkan;
• durasi akses;
• sistem yang boleh dihubungi;
• volume tindakan;
• kebutuhan persetujuan manusia.

Pendekatan tersebut membantu mencegah AI agent memperoleh kewenangan yang lebih luas daripada kebutuhan sebenarnya.

Satu Connector Dapat Membuka Beberapa Jalur Serangan

Connector sering dipandang sebagai penghubung teknis antara AI agent dan aplikasi bisnis. Padahal, connector juga membentuk batas kepercayaan baru.

Satu connector dapat menghubungkan model dengan email, penyimpanan cloud, CRM, database, atau sistem pembayaran. Jika connector menggunakan kredensial yang terlalu luas, seluruh kemampuan tersebut berpotensi digunakan melalui satu jalur.

Serangan tidak selalu dimulai dengan pencurian password. Penyerang dapat menempatkan instruksi berbahaya dalam dokumen, email, halaman web, atau data yang akan dibaca agent.

Rantai kejadiannya dapat berlangsung sebagai berikut:

1. AI agent menerima dokumen yang berisi instruksi tersembunyi.
2. Model menafsirkan instruksi tersebut sebagai bagian dari tugas.
3. Agent memilih tool yang tersedia.
4. Tool menggunakan kredensial resmi.
5. Sistem tujuan menganggap tindakan itu sebagai aktivitas sah.

Pada kondisi tersebut, penyerang tidak perlu memperoleh akses langsung ke sistem. Mereka memengaruhi agent yang sudah memiliki akses.

Inilah yang membuat attack surface AI berbeda dari aplikasi biasa. Data yang dibaca agent dapat berubah menjadi instruksi, sedangkan instruksi dapat berubah menjadi tindakan.

Prompt Injection Hanya Pemicu, Izin Menentukan Dampaknya

Prompt injection sering menjadi pusat pembahasan keamanan AI. Ancaman tersebut memang penting, tetapi prompt injection bukan satu-satunya unsur yang menentukan risiko.

Dampak sebenarnya bergantung pada kewenangan yang dimiliki AI agent.

Agent yang hanya dapat membuat ringkasan mungkin menghasilkan jawaban yang salah. Namun, agent yang dapat mengirim email, mengubah database, atau menjalankan deployment dapat menimbulkan dampak lebih besar dari manipulasi yang sama.

OWASP menggunakan istilah excessive agency untuk menggambarkan risiko ketika sistem berbasis AI memperoleh fungsi, izin, atau otonomi yang berlebihan.

Excessive agency dapat terjadi ketika agent diberikan terlalu banyak tools. Risiko juga muncul apabila connector memiliki permission yang lebih luas daripada kebutuhan tugas. Kondisi lain terjadi ketika agent diperbolehkan menjalankan tindakan sensitif tanpa persetujuan manusia.

Dengan demikian, prompt injection dapat menjadi awal serangan, tetapi izin menentukan seberapa jauh serangan dapat bergerak.

Tool yang Terlihat Sederhana Dapat Memiliki Kewenangan Berlebihan

Batas kewenangan AI agent tidak hanya ditentukan oleh role atau token. Desain tool juga menentukan tindakan yang dapat dilakukan.

Sebuah tool untuk membaca dokumen mungkin sekaligus menyediakan fungsi mengubah dan menghapus file. Connector email dapat memiliki kemampuan membaca, mengirim, dan menghapus pesan meskipun kebutuhan awalnya hanya membuat ringkasan.

Masalah serupa dapat ditemukan pada tool database yang menerima query bebas, connector CRM dengan akses seluruh tenant, atau tool eksekusi yang menyediakan perintah sistem terlalu luas.

AI agent sebaiknya tidak diberikan tool serbaguna jika kebutuhan bisnisnya dapat dipenuhi menggunakan fungsi yang lebih terbatas.

Sebagai contoh, agent yang bertugas membaca data tidak perlu menggunakan kredensial yang memiliki izin untuk melakukan pembaruan. Agent yang hanya membuat draf tidak perlu memperoleh kemampuan mengirim. Agent yang memeriksa konfigurasi tidak harus dapat mengubah lingkungan produksi.

Pembatasan perlu diterapkan pada sisi tool dan sistem tujuan. Mengandalkan instruksi model agar “tidak melakukan tindakan tertentu” bukan pengganti kontrol otorisasi yang deterministik.

Least Privilege untuk AI Agent Harus Bersifat Kontekstual

Penerapan least privilege pada AI agent tidak cukup dilakukan dengan memberikan role umum seperti “reader” atau “operator”.

AI agent dapat merencanakan tugas dalam beberapa tahap. Agent juga dapat menghubungkan informasi dari berbagai sistem dan memilih tool berdasarkan konteks. Izin statis yang terlihat kecil pada satu aplikasi dapat menghasilkan kewenangan besar ketika digabungkan dengan izin pada aplikasi lain.

Contohnya, agent memiliki akses membaca dokumen dan mengirim email. Masing-masing izin terlihat wajar. Namun, kombinasi keduanya dapat memungkinkan informasi internal dikirim ke penerima eksternal.

Karena itu, least privilege untuk AI agent perlu diterapkan berdasarkan identitas, tugas, tool, data, waktu, dan konteks.

Beberapa kontrol yang dapat digunakan meliputi:

• identitas terpisah untuk setiap agent;
• token dengan masa berlaku pendek;
• scope akses yang spesifik;
• izin berbeda untuk membaca dan mengubah;
• pembatasan penerima eksternal;
• rate limiting;
• validasi parameter tool;
• otorisasi pada setiap tindakan;
• isolasi antar-user dan antar-tenant;
• persetujuan manusia untuk tindakan sensitif.

Prinsip utamanya sederhana: kemampuan AI agent tidak boleh lebih luas daripada kebutuhan tugas yang sedang dijalankan.

Human-in-the-Loop Tidak Cukup Hanya dengan Tombol Konfirmasi

Persetujuan manusia sering digunakan sebagai pengaman tambahan. Namun, persetujuan tersebut tidak akan efektif jika pengguna tidak memahami tindakan yang akan dilakukan.

Tombol “Allow” atau “Continue” tidak memberikan kontrol yang berarti apabila pengguna tidak mengetahui data yang akan diakses, sistem yang akan dihubungi, dan dampak dari tindakan tersebut.

Sebelum memberikan persetujuan, pengguna sebaiknya dapat melihat:

• tindakan yang akan dilakukan;
• sumber data yang digunakan;
• tujuan pengiriman data;
• penerima atau sistem tujuan;
• perubahan yang akan terjadi;
• apakah tindakan dapat dibatalkan;
• agent dan tool yang terlibat.

Persetujuan manusia sebaiknya diwajibkan untuk tindakan dengan dampak tinggi, seperti transfer dana, penghapusan data, perubahan permission, pengiriman informasi eksternal, deployment ke production, dan perubahan konfigurasi keamanan.

Untuk tindakan berisiko rendah, perusahaan dapat menggunakan batas transaksi, kebijakan otomatis, atau sampling audit agar proses tetap efisien.

Multi-Agent Memperpanjang Rantai Kepercayaan

Arsitektur agentic AI dapat melibatkan satu agent utama dan beberapa subagent. Agent pertama membagi tugas, sedangkan agent lain mencari data, membuat analisis, atau menjalankan tindakan.

Model ini dapat meningkatkan efisiensi, tetapi juga memperpanjang rantai kepercayaan.

Agent penerima mungkin memiliki izin lebih tinggi daripada agent pengirim. Instruksi dapat berubah selama proses delegasi. Data juga dapat berpindah melewati boundary yang sebelumnya tidak direncanakan.

Risiko lain muncul ketika satu agent yang disusupi mengirim instruksi kepada agent lain. Jika setiap agent otomatis mempercayai permintaan dari sesama agent, serangan dapat menyebar melalui workflow.

Setiap delegasi perlu membawa informasi mengenai identitas pengirim, pengguna yang memulai tugas, tujuan, batas izin, serta data yang boleh digunakan. Agent penerima tetap harus melakukan otorisasi dan tidak boleh menganggap agent lain selalu tepercaya.

Memory Dapat Membuat Serangan Bertahan Lebih Lama

Sebagian AI agent menggunakan memory untuk menyimpan preferensi, riwayat tugas, hasil interaksi, atau informasi yang dianggap penting.

Kemampuan tersebut membantu agent menjaga konteks. Namun, memory juga dapat menjadi jalur serangan persisten.

Instruksi berbahaya yang tersimpan dapat memengaruhi keputusan pada sesi berikutnya. Data sensitif dapat bertahan lebih lama daripada kebutuhan awal. Informasi dari satu pengguna juga berpotensi masuk ke konteks pengguna lain jika isolasi memory tidak diterapkan dengan baik.

Pengamanan memory perlu mencakup:

• validasi sebelum penyimpanan;
• pemisahan antar-user dan antar-tenant;
• pembatasan data sensitif;
• masa retensi;
• pencatatan sumber informasi;
• mekanisme koreksi dan penghapusan;
• pemeriksaan ulang sebelum memory digunakan untuk tindakan.

Tidak semua informasi yang diterima agent harus diperlakukan sebagai fakta atau instruksi permanen.

Audit Log Harus Menjelaskan Asal Wewenang

Log aplikasi biasa mungkin hanya mencatat endpoint yang dipanggil, waktu akses, dan akun yang digunakan. Informasi tersebut belum cukup untuk menjelaskan tindakan AI agent.

Audit trail perlu memisahkan tiga lapisan: pengguna yang memulai tugas, agent yang mengambil keputusan, dan sistem yang mengeksekusi tindakan.

Log yang memadai setidaknya dapat menjawab:

• siapa yang memulai tugas;
• agent mana yang menjalankannya;
• identitas dan token apa yang digunakan;
• data apa yang diakses;
• tool apa yang dipanggil;
• izin apa yang digunakan;
• apakah terdapat persetujuan manusia;
• agent lain apa yang terlibat;
• perubahan apa yang terjadi;
• apakah tindakan berhasil, ditolak, atau dibatalkan.

Kemampuan ini penting untuk investigasi insiden. Tanpa audit trail yang jelas, perusahaan mungkin mengetahui bahwa perubahan telah terjadi, tetapi tidak dapat menjelaskan mengapa agent mengambil keputusan tersebut.

AI Agent Memerlukan Pengelolaan Siklus Hidup

AI agent perlu dikelola seperti identitas non manusia lainnya. Setiap agent harus memiliki pemilik, tujuan, izin, dan masa berlaku.

Proses pengelolaannya dapat mencakup:

1. Mendaftarkan identitas agent.
2. Menentukan pemilik teknis dan bisnis.
3. Mendokumentasikan tujuan serta ruang lingkup.
4. Menyetujui data dan tools yang dapat digunakan.
5. Memberikan izin minimum.
6. Memantau aktivitas dan perubahan perilaku.
7. Mengevaluasi akses secara berkala.
8. Merotasi kredensial.
9. Menyediakan mekanisme suspend dan kill switch.
10. Mencabut akses ketika agent tidak lagi digunakan.

Agent yang sudah tidak digunakan tetapi masih memiliki token dapat berubah menjadi identitas terlupakan. Kondisi ini serupa dengan service account lama, tetapi dampaknya dapat lebih kompleks karena agent mampu memilih dan merangkai tindakan.

Pengujian Keamanan Tidak Boleh Berhenti pada Respons Model

Pengujian aplikasi berbasis AI sering berfokus pada upaya membuat model menghasilkan jawaban yang dilarang. Pendekatan tersebut belum cukup untuk menilai risiko AI agent.

Penetration testing perlu memeriksa keseluruhan arsitektur agentic, termasuk identitas, token, API, connector, tools, memory, dan workflow otomatis.

Skenario pengujian dapat mencakup:

• direct dan indirect prompt injection;
• manipulasi pemilihan tool;
• akses lintas pengguna atau tenant;
• privilege escalation;
• penggunaan ulang token;
• kebocoran data melalui connector;
• tool poisoning;
• manipulasi memory;
• penyalahgunaan komunikasi antar-agent;
• bypass persetujuan manusia;
• tindakan berulang tanpa rate limiting;
• kegagalan logging;
• kemampuan menghentikan agent ketika terjadi insiden.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Implementasi AI biasanya telah memiliki pembatasan pada prompt dan respons. Namun, kontrol pada identitas, akses API, penggunaan tools, serta dampak tindakan belum selalu memperoleh pengujian dengan kedalaman yang sama.

Padahal, model bukan satu-satunya komponen yang menentukan keamanan. Sistem di sekitar model justru menentukan data yang dapat dijangkau dan tindakan yang dapat dilakukan.

Otonomi Harus Mengikuti Kejelasan Wewenang

AI agent tidak menjadi berbahaya hanya karena mampu mengambil keputusan. Risiko muncul ketika keputusan tersebut menggunakan identitas yang tidak jelas, izin yang terlalu luas, dan tools yang dapat mengubah sistem nyata.

Sebelum memperluas otonomi, perusahaan harus memastikan setiap agent memiliki pemilik, batas tugas, izin minimum, masa berlaku, dan jalur audit. Tindakan berisiko tinggi harus memiliki validasi serta persetujuan yang tidak dapat dilewati oleh model.

Jika perusahaan tidak dapat menjelaskan siapa yang memberikan kewenangan, data apa yang boleh diakses, dan bagaimana akses dihentikan, AI agent tersebut belum siap terhubung dengan proses bisnis penting.

Uji Keamanan Aplikasi Berbasis AI Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi celah keamanan melalui layanan Vulnerability Assessment serta Penetration Testing Blackbox dan Greybox.

Pengujian dapat dilakukan terhadap web application, desktop application, aplikasi Android dan iOS, API, jaringan, serta server. Dalam implementasi AI agent, pengujian dapat diarahkan untuk mengevaluasi akses API, kelemahan otorisasi, connector, integrasi antarsistem, serta jalur serangan yang muncul dari workflow otomatis.

Hasil pengujian disertai laporan terperinci, rekomendasi perbaikan, konsultasi, dan pengujian ulang sesuai ruang lingkup layanan.

Hubungi Fourtrezz untuk mendiskusikan kebutuhan dan menentukan scope pengujian keamanan yang sesuai dengan arsitektur aplikasi perusahaan Anda.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]