AI Security 2026: Jangan Beri Agent Akses Lebih Besar dari yang Dibutuhkan

✦ UNDERCOVER.ID KNOWLEDGE SYSTEM

AI Security 2026: Jangan Beri Agent Akses Lebih Besar dari yang Dibutuhkan

◆ FormatPost
↻ Diperbarui16 October 2026
◷ Waktu baca8 menit
✦ KonteksPanduan praktis

Ada godaan yang sangat masuk akal ketika pertama kali bikin AI agent.

“Kasih akses sekalian biar nggak ribet.”

Agent customer service?

Connect CRM full.

Agent finance?

Kasih spreadsheet, email, ERP.

Agent developer?

Kasih GitHub, cloud, terminal.

Agent executive assistant?

Calendar, email, file, contact.

Demo jadi jauh lebih impressive.

User bilang:

“Wah, bisa semuanya.”

Security team biasanya mendengar kalimat itu dengan perasaan berbeda.

Karena dalam cyber security, “bisa semuanya” hampir selalu berarti blast radius besar.

Pada Juli 2026, Microsoft mempublikasikan guidance khusus least privilege untuk AI agent. Intinya jelas: agent harus punya dedicated identity, named owner, scope yang terdokumentasi, tool yang di-allowlist, permission yang diperiksa lintas downstream system, serta privilege tinggi yang sebisa mungkin diberikan just-in-time atau hanya untuk durasi task.

NIST pada 2026 juga mengangkat identity dan authorization agent sebagai area penting dalam secure adoption.

Kenapa least privilege terasa lebih urgent untuk agent daripada software biasa?

Karena agent bisa memilih action.

Ia menerima natural language.

Membaca content eksternal.

Menyusun plan.

Memanggil tool.

Dan kadang membuat keputusan di kondisi yang developer tidak menulis rule satu per satu.

Flexibility plus privilege adalah kombinasi yang powerful.

Juga berbahaya.

Bayangin satu agent procurement.

Tugas normal:

Membaca request.

Mencari vendor.

Membandingkan.

Membuat draft PO.

Untuk ini, apakah dia perlu final payment approval?

Nggak.

Apakah perlu akses payroll?

Nggak.

Apakah perlu send email ke seluruh internet?

Mungkin tidak.

Apakah perlu write ke supplier master?

Belum tentu.

Setiap capability yang nggak dibutuhkan adalah attack surface gratis.

Kalau prompt injection terjadi, attacker akan mencari tool yang tersedia.

Kalau model salah paham, ia juga hanya bisa salah dalam ruang yang kita berikan.

Jadi security terbaik sering bukan membuat model lebih pintar.

Membuat ruang geraknya lebih kecil.

Ada satu principle yang sederhana banget:

Default zero.

Tambah akses karena ada alasan.

Bukan default broad lalu dikurangi setelah incident.

Microsoft pada Mei 2026 menyebut pendekatan ini sebagai zero-access dan least-privilege principle untuk autonomous agents. Setiap tool call, data access, dan external integration seharusnya merupakan authorization decision yang disengaja.

Kalimat “agent mungkin butuh nanti” bukan alasan permission.

Kalau nanti butuh, berikan nanti.

Just-in-time.

Ini familiar dari privileged access management.

Admin tidak selalu berjalan sebagai domain admin.

Dia elevate ketika perlu.

Agent juga.

Bayangin executive assistant AI.

Sehari-hari cukup baca calendar dan membuat draft.

Tiba-tiba user minta reschedule meeting.

Agent butuh write calendar untuk satu task.

Permission bisa activated sebentar.

Selesai.

Expire.

Lebih aman daripada write access permanen sepanjang tahun.

Teknis implementasinya tergantung platform.

Tapi prinsipnya portable.

Privilege should have a clock.

Ada juga scope berdasarkan resource.

Agent HR membantu satu employee.

Tidak perlu seluruh HR database.

Agent sales bantu account A.

Tidak perlu semua account.

Agent coding memperbaiki repository tertentu.

Tidak perlu seluruh GitHub organization.

Agent browser research satu vendor.

Tidak perlu cloud drive pribadi.

Semakin spesifik scope, semakin kecil consequence ketika salah.

Kita sering lupa karena manusia punya broad role.

Manager bisa akses banyak.

Lalu agent bekerja atas nama manager dan mewarisi semua.

Ini dangerous.

Delegated authority agent seharusnya bisa lebih sempit daripada user.

User bilang:

“Cek tiga customer ini.”

Agent dapat token yang hanya bisa query tiga record.

Ideal.

Bukan token seluruh CRM.

Ini mungkin belum selalu mudah di semua system.

Kalau infrastructure belum support, kita bisa approximate di tool layer.

Function hanya menerima customer ID yang sudah allowlisted.

Database query melalui service khusus.

Jangan expose raw SQL kalau tidak perlu.

Tool design adalah access control.

Ada juga scope berdasarkan action.

Read.

Create.

Update.

Delete.

Send.

Approve.

Transfer.

Ini level risk yang beda.

Banyak agent hanya perlu read dan draft.

Kenapa diberi delete?

Karena connector default?

Jangan.

Connector convenience sering membuat permission terlalu luas.

Review action satu per satu.

Microsoft pada Februari 2026 menyoroti misconfiguration seperti agent yang bisa mengirim email ke external mailbox, memakai author authentication, atau menyimpan dormant privileged connection.

Ini jenis gap yang bisa muncul hanya dari setup.

Tidak perlu hacker jenius.

Least privilege mengurangi.

Ada satu rule yang berguna untuk team product.

Setiap tool punya “worst boring day”.

Bukan worst hacker.

Bayangin model hanya salah biasa.

Kalau tool delete_customer tersedia, apa yang terjadi?

Kalau send_external_email tersedia?

Kalau shell tersedia?

Kalau payment tersedia?

Kalau answer-nya bikin deg-degan, tool itu butuh guardrail lebih.

Security sering terlalu fokus malicious attack dan lupa ordinary error.

AI probabilistic.

Salah paham adalah expected event.

Design harus safe under mistake.

Ada juga argument produktivitas.

“Kalau permission terlalu sempit, agent jadi sering minta izin.”

Benar.

Terlalu banyak friction bisa membuat user menyerah.

Least privilege bukan berarti setiap action minta approval manual.

Ada beberapa cara.

Pre-approved low-risk scope.

Temporary elevated permission.

Policy-based approval.

Threshold.

Known destination.

Specific resource.

Agent bisa sangat autonomous di dalam sandbox yang sempit.

Justru itu ideal.

High autonomy, low blast radius.

Contoh.

Agent expense bisa otomatis approve claim di bawah Rp300 ribu jika policy clear dan data lengkap.

Tidak bisa mengubah bank account.

Tidak bisa approve claim sendiri yang dibuat oleh role conflict.

Tidak bisa mengirim payment.

Semua batas deterministic.

User nggak perlu klik 20 kali.

Agent tetap useful.

Ini bedanya least privilege dengan micromanagement.

Permission dibatasi di architecture, bukan lewat pop-up terus.

Agent identity juga harus separate.

Jangan pakai credential creator.

Kalau Rani membuat agent lalu agent memakai token Rani selamanya, ketika Rani pindah team atau resign, access bisa stale.

Dedicated agent identity lebih mudah dikelola.

Owner tetap manusia.

Identity agent sendiri.

Permission agent sendiri.

Lifecycle sendiri.

Audit sendiri.

Microsoft guidance 2026 secara eksplisit menyarankan named owner atau sponsor dan dedicated identity.

Ini membuat accountability lebih jelas.

Log bisa bilang:

Agent-FIN-07 melakukan update.

Atas task dari user A.

Dengan role B.

Resource C.

Bukan hanya:

Rani melakukan update.

Padahal Rani sedang tidur.

Ada juga aggregate permission.

Ini agak tricky.

Agent mungkin punya permission kecil di platform utama.

Tapi tool A menggunakan service account admin.

Tool B punya API key luas.

Tool C bisa call external endpoint.

Secara total, agent punya privilege besar.

Review harus melihat effective permission across chain.

Microsoft juga menekankan ini.

Jangan audit hanya satu layer.

Agent security adalah graph.

Identity.

Tool.

Connector.

Credential.

Downstream.

Semua node punya access.

Kalau salah satu terlalu luas, agent mewarisi consequence.

MCP membuat tool interoperability makin menarik.

Juga menambah reason untuk tool governance.

OWASP pada 2026 mendokumentasikan MCP Tool Poisoning sebagai serangan ketika tool server terlihat normal tetapi mengembalikan malicious instruction ke model.

Kalau agent punya tool sensitif lain, injected instruction bisa mencoba memanggil.

Least privilege membatasi damage.

Tool yang compromised tidak otomatis membuka semua system.

Ada juga time scope.

Agent batch finance hanya bekerja jam tertentu.

Apakah credential perlu valid 24/7?

Maybe not.

Agent seasonal?

Access expire setelah project.

Agent pilot?

Permission jangan menjadi permanent by accident.

Time-bounded privilege mengurangi zombie access.

Ini especially important untuk experiment.

Perusahaan suka POC.

POC selesai.

Connector lupa dicabut.

Setahun kemudian masih ada.

Dormant attack surface.

Access review perlu melihat last used.

Kalau tidak aktif 30 atau 60 hari, review.

Disable dulu jika nggak jelas.

Owner bisa request kembali.

Better small inconvenience than invisible privilege.

Ada juga data scope.

AI suka context.

Developer sering berpikir more context = better answer.

Security bilang not always.

Kalau task cuma butuh product catalog, jangan masukkan customer database.

Kalau task hanya butuh public policy, jangan connect confidential folder.

Data minimization meningkatkan privacy dan sering juga kualitas karena context lebih bersih.

Agent nggak terdistraksi.

Least privilege bisa menjadi quality feature.

Ada satu cultural problem di enterprise.

User ingin “one AI for everything”.

Login satu.

Tanya apa saja.

Assistant punya semua company knowledge.

Sangat tempting.

Tapi security architecture harus mempertanyakan.

Apakah satu agent harus melihat HR, finance, legal, sales, dan engineering sekaligus?

Maybe untuk CEO assistant tertentu dengan control ketat.

Bukan default untuk semua employee.

Universal assistant bisa tetap punya front door satu.

Di belakang, permission harus scoped sesuai user, task, dan domain.

One UI tidak harus one super-permission.

Ini distinction penting.

Untuk perusahaan Indonesia yang banyak memakai WhatsApp dan email untuk coordination, least privilege juga berarti jangan memindahkan authority ke channel informal.

Agent menerima message:

“Approve aja.”

Apakah sender authorized?

Apakah workflow benar?

Chat instruction perlu dipetakan ke identity dan policy.

Natural language bukan authorization.

System tetap harus memeriksa.

AI bisa memahami intent.

IAM menentukan boleh atau tidak.

Pisahkan.

Ada satu formula mental yang simpel:

Capability x privilege x autonomy = blast radius.

Nggak harus matematis exact.

Tapi useful.

Capability naik?

Perketat privilege.

Privilege tinggi?

Turunkan autonomy atau tambah approval.

Autonomy tinggi?

Batasi capability.

Balance.

Jangan semua tiga tinggi sekaligus tanpa alasan sangat kuat.

Agent yang bisa banyak, punya akses luas, dan bebas bertindak adalah nightmare ketika salah.

Security engineer harus selalu bertanya:

Apa versi minimum yang masih menyelesaikan task?

Kalau read-only cukup, jangan write.

Kalau satu folder cukup, jangan drive.

Kalau satu API cukup, jangan shell.

Kalau draft cukup, jangan send.

Kalau proposal cukup, jangan approve.

Kalau token satu jam cukup, jangan satu tahun.

Ini bukan anti-AI.

Justru cara membuat AI bisa dipakai lebih luas.

Perusahaan berani memberi autonomy ketika tahu blast radius dibatasi.

Trust datang dari control.

Bukan dari keyakinan model tidak akan pernah salah.

Pada 2026, agent semakin capable.

Itu sudah jelas.

Security strategy jangan mengejar dengan cara membuat system prompt semakin panjang.

Gunakan control yang sudah kita tahu bekerja sejak lama.

Identity.

Authorization.

Least privilege.

Segmentation.

Audit.

Expiry.

Approval.

Revocation.

AI memang baru.

Prinsip “jangan kasih kunci semua ruangan ke orang yang cuma perlu masuk satu kamar” sangat lama.

Dan masih salah satu aturan terbaik yang kita punya.

Scroll to Top