AI Agent Bisa Menjadi Insider Threat tanpa Berniat Jahat
Bayangin satu employee baru di kantor.
Dia rajin, cepat, nggak pernah telat, bisa kerja 24 jam, dan punya akses ke CRM, email, folder tim, serta beberapa tool internal.
Masalahnya, dia kadang salah paham.
Kadang terlalu literal.
Kadang percaya instruksi dari sumber yang salah.
Kadang melakukan sesuatu karena merasa itu masih bagian dari tugas.
Kalau employee seperti ini manusia, security team pasti langsung membatasi aksesnya.
Tapi ketika employee itu AI agent, banyak perusahaan justru tergoda memberi akses luas supaya “lebih useful”.
Di sinilah konsep insider threat mulai berubah.
Insider threat biasanya dibayangkan sebagai orang dalam yang sengaja berbuat jahat.
Employee marah.
Contractor mencuri data.
Admin menjual credential.
AI agent bisa menciptakan impact mirip insider threat tanpa punya niat apa pun.
Ia tidak dendam.
Tidak butuh uang.
Tidak punya agenda.
Cukup salah memahami task, terlalu patuh pada input yang salah, atau menjalankan action dengan permission yang kebesaran.
Pada Mei 2026, NIST merangkum respons industri terhadap keamanan AI agent dan menyimpulkan bahwa agent memang membawa threat baru, walaupun prinsip cyber security lama masih relevan dan perlu diadaptasi. Microsoft pada 2026 juga menyoroti agent sprawl, over-privileged agents, tool misuse, prompt injection, dan data leakage sebagai area yang perlu ditangani saat organisasi mulai memakai agent dalam skala besar.
Semua ini mengarah ke satu hal.
Intent bukan satu-satunya hal yang menentukan apakah insider berbahaya.
Capability juga.
Bayangin agent finance punya akses membaca invoice, membuat draft pembayaran, mengubah beneficiary, dan mengirim email.
User cuma bilang:
“Bantu beresin invoice yang pending hari ini.”
Kalimatnya cukup masuk akal.
Agent menemukan satu email vendor dengan instruksi perubahan rekening.
Email itu ternyata compromised atau mengandung prompt injection.
Agent percaya.
Data beneficiary berubah.
Payment berikutnya masuk rekening salah.
Tidak ada satu pun actor internal yang berniat jahat.
Namun dari sudut pandang consequence, organisasi mengalami sesuatu yang mirip insider compromise.
Sistem internal menggunakan hak yang sah untuk melakukan tindakan yang salah.
Ini yang bikin agent berbeda dari software automation tradisional.
Rule-based automation biasanya sempit.
Kalau A, lakukan B.
Agent bisa reasoning.
Mencari langkah sendiri.
Memilih tool.
Menggabungkan data dari beberapa system.
Fleksibilitas ini adalah value.
Juga sumber risk.
Semakin flexible agent, semakin banyak keputusan yang tidak ditulis developer satu per satu.
Dan semakin penting boundary.
Ada satu kesalahan design yang gampang terjadi.
“Agent ini milik tim kita, jadi trusted.”
Trusted asalnya bukan berarti trusted behavior.
Laptop company tetap dipasang EDR.
Employee company tetap punya access control.
Service account company tetap dibatasi.
Agent internal juga harus begitu.
Bahkan mungkin lebih ketat karena action-nya bisa sangat cepat.
Satu manusia mungkin mengubah lima record sebelum sadar ada masalah.
Agent bisa mengubah lima ribu.
Scale mengubah error kecil menjadi incident.
Itu alasan least privilege jadi sangat penting.
Agent customer service yang tugasnya melihat status order tidak perlu akses seluruh database customer.
Agent HR yang menjawab saldo cuti tidak perlu membaca salary semua employee.
Agent procurement yang membandingkan supplier tidak perlu bisa approve payment.
Agent coding yang review repository tidak otomatis perlu production credential.
Kalau capability tidak dibutuhkan, jangan diberikan.
Ini bukan karena agent “jahat”.
Justru karena kita mengasumsikan ia bisa salah.
Sama seperti kita memasang guardrail di jalan bukan karena semua driver mau menabrak.
Guardrail ada karena manusia bisa kehilangan kontrol.
Agent butuh digital guardrail.
Ada juga konsep delegated authority.
User manusia punya akses tertentu.
Apakah agent otomatis boleh mendapat semua?
Harusnya nggak.
Misalnya seorang finance manager boleh melihat semua invoice dan approve payment tertentu.
Dia memakai agent hanya untuk membuat summary.
Agent cukup read-only.
Kalau platform secara default mewariskan seluruh privilege manager, risk naik tanpa alasan.
Authority yang dibutuhkan task biasanya lebih kecil daripada authority user.
Ini beda yang sangat penting.
AI agent tidak harus menjadi digital clone dari seluruh privilege kita.
Ia bisa menjadi temporary assistant dengan akses kecil.
Microsoft pada Juli 2026 mendorong dedicated agent identity, named owner, scope yang jelas, serta just-in-time entitlement untuk privilege yang lebih tinggi.
Jadi ketika agent membutuhkan akses tambahan, akses itu diberikan untuk task atau waktu tertentu.
Selesai task, privilege expire.
Model ini jauh lebih aman daripada agent permanen dengan master key.
Ada satu ilustrasi yang relate banget ke kantor.
Bayangin lo punya anak magang.
Lo bilang:
“Tolong cari file proposal lama.”
Apakah lo kasih password admin seluruh Google Workspace?
Nggak.
Lo kasih akses folder yang perlu.
Aneh kalau ke manusia kita paham prinsip itu, tapi ke AI malah bilang:
“Connect everything biar seamless.”
Seamless buat user.
Seamless juga buat incident.
Agent juga bisa menjadi insider-like threat melalui memory.
Beberapa agent menyimpan state atau memory lintas sesi.
Preference.
Ringkasan task.
Instruction.
Context.
Kalau memory itu tercemar oleh informasi salah atau malicious input, behavior berikutnya bisa ikut berubah.
OWASP pada 2026 bahkan punya Agent Memory Guard yang menyoroti memory poisoning sebagai attack surface, karena state agent dapat dimodifikasi dan bertahan lintas session.
Bayangin satu instruction jahat masuk hari ini.
Tidak langsung menimbulkan impact.
Tapi tersimpan.
Besok agent menggunakan memory tersebut ketika menjalankan task lain.
Incident menjadi delayed.
Ini berbeda dari prompt injection biasa yang selesai ketika session tutup.
Persistent memory menciptakan persistence mirip attacker foothold.
Sekali lagi, agent tidak berniat jahat.
Ia hanya mengingat sesuatu yang seharusnya tidak dipercaya.
Jadi memory juga perlu governance.
Apa yang boleh disimpan?
Berapa lama?
Source-nya apa?
Bisa dihapus?
Bisa rollback?
Apakah data sensitif perlu masuk?
Jangan menganggap semakin banyak memory semakin pintar.
Kadang semakin banyak memory berarti semakin besar attack surface.
Ada juga tool misuse.
Agent punya tool resmi.
Misalnya send_email.
Tool-nya sah.
Credential sah.
API sah.
Masalahnya, agent menggunakan tool tersebut untuk destination salah karena dipengaruhi input eksternal.
Traditional security mungkin melihat tidak ada credential theft.
Semua request authenticated.
Tetapi outcome tetap data exfiltration.
Ini salah satu alasan Microsoft menekankan setiap tool call seharusnya hasil authorization decision yang disengaja, bukan implicit.
Security perlu bergerak dari “siapa yang login?” ke “action ini sesuai scope task nggak?”
Identity saja tidak cukup.
Behavior matters.
Perusahaan bisa membuat beberapa lapis containment.
Pertama, dedicated identity.
Jangan agent memakai account personal creator.
Kalau creator resign, agent jangan tetap hidup dengan privilege warisan.
Kedua, tool allowlist.
Agent hanya melihat tool yang diperlukan.
Kalau tidak butuh email eksternal, jangan expose send_email external.
Ketiga, parameter restriction.
Agent boleh kirim email hanya ke domain tertentu.
Boleh query database tapi tidak delete.
Boleh membuat draft tapi tidak publish.
Keempat, transaction limit.
Boleh membuat refund sampai nominal tertentu.
Di atas itu human approval.
Kelima, audit.
Semua action tercatat.
Bukan hanya final answer.
Tool apa.
Resource apa.
On behalf of siapa.
Result.
Keenam, kill switch.
Kalau behavior aneh, security team bisa mematikan agent tanpa menunggu vendor.
Ini basic.
Tapi justru basic yang sering hilang karena orang terlalu fokus ke model.
Ada juga insider risk yang muncul dari agent sprawl.
Satu perusahaan bisa punya puluhan atau ratusan agent yang dibuat user dan vendor.
Sebagian aktif.
Sebagian lupa.
Sebagian hanya dipakai tiga bulan lalu.
Tapi connector-nya masih hidup.
Microsoft pada Februari 2026 secara spesifik menyoroti dormant connections, actions, dan agents sebagai hidden attack surface.
Ini mirip service account lama.
Nobody remembers.
Credential masih valid.
Attackers suka benda yang dilupakan.
Governance perlu inventory.
Nama agent.
Owner.
Purpose.
Last used.
Permission.
Connector.
Risk tier.
Kalau tidak dipakai, retire.
Bukan sekadar hide dari UI.
Revoke credential.
Remove permission.
Delete connection.
Review memory.
Lifecycle selesai.
Di Jakarta, banyak perusahaan sekarang pakai kombinasi Microsoft 365, Google Workspace, SaaS HR, CRM, ERP, dan WhatsApp untuk komunikasi informal.
Agent yang ingin “membantu semua” gampang sekali mendapat access lintas boundary.
Meeting pagi di Sudirman, approval lewat Teams, vendor follow-up lewat WhatsApp, invoice di email, data final di ERP.
Manusia paham context perpindahan ini karena sudah hidup di dalam organisasi.
Agent melihat connector.
Kalau semuanya dibuka, ia bisa chain.
Convenient, iya.
Risk juga.
Tidak semua workflow perlu super-agent.
Kadang lebih sehat punya beberapa agent kecil.
Agent research read-only.
Agent procurement punya supplier data.
Agent finance punya payment preparation tapi tidak final approval.
Separation membuat blast radius lebih kecil.
Memang terasa kurang sci-fi.
Tapi enterprise security jarang menang dari sesuatu yang paling sci-fi.
Ada satu perubahan bahasa yang perlu terjadi di management.
Jangan bertanya:
“Agent ini bisa melakukan apa?”
Tanya juga:
“Kalau agent ini salah, apa yang bisa rusak?”
Pertanyaan kedua menentukan permission.
Kalau worst-case cuma draft email jelek, autonomy boleh tinggi.
Kalau worst-case menghapus database atau memindahkan uang, control harus jauh lebih ketat.
Risk-based autonomy.
Ini jauh lebih masuk akal daripada semua agent diperlakukan sama.
AI agent juga perlu peer review seperti software.
Prompt berubah.
Tool baru.
Memory aktif.
Permission naik.
Semua perubahan bisa mengubah risk.
Access review setahun sekali terlalu lambat.
Material change harus trigger review.
Kalau agent minggu lalu hanya membaca file dan hari ini sudah bisa mengirim email, itu bukan update kecil.
Attack surface berubah.
Security perlu ikut.
Dan satu hal yang paling penting: human owner tetap harus ada.
Agent bisa mengambil keputusan.
Agent tidak bisa memegang tanggung jawab organisasi.
Kalau terjadi incident, harus jelas siapa yang punya authority untuk investigate, patch, pause, dan decide.
“AI yang salah” bukan root cause yang cukup.
Kenapa agent boleh melakukan action itu?
Kenapa permission-nya ada?
Kenapa input dianggap trusted?
Kenapa approval tidak dibutuhkan?
Pertanyaan itu manusia yang jawab.
AI agent bisa menjadi insider threat tanpa berniat jahat karena niat memang bukan bagian desain security.
Security tidak dibangun berdasarkan asumsi semua actor baik.
Security dibangun supaya ketika actor salah, consequence tetap terbatas.
Dan ketika actor itu mesin yang bisa bekerja ribuan kali lebih cepat daripada manusia, batas tersebut bukan tambahan.
Itu fondasi.
Bacaan terkait
Artikel ini berada dalam Cybersecurity & Trust dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Explainer teknologi dan kebijakan digital.