“Tenang, ini kan agent kita sendiri.”

Seolah kata sendiri otomatis berarti aman.

Padahal banyak insiden teknologi justru berasal dari sistem internal yang salah konfigurasi, terlalu banyak privilege, atau dipercaya terlalu jauh.

AI agent memperbesar problem ini karena ia bukan software pasif.

Ia bisa membaca.

Merencanakan.

Memilih tool.

Mengambil action.

Kalau agent internal diberi trust hanya karena dibuat perusahaan sendiri, kita mengulang kesalahan lama dalam bentuk baru.

Pada Maret 2026, Microsoft merilis guidance Zero Trust for AI dengan tiga prinsip yang sebenarnya familiar: verify explicitly, apply least privilege, dan assume breach.

Yang baru bukan prinsipnya.

Yang baru adalah objeknya.

Zero Trust sekarang perlu diterapkan ke hubungan antara user, agent, model, data, plugin, tool, dan automated decision.

Microsoft bahkan menggambarkan agent yang overprivileged, manipulated, atau misaligned sebagai actor yang bisa bekerja melawan outcome organisasi.

NIST pada Februari 2026 juga membuka concept paper khusus identity dan authorization untuk software serta AI agent, termasuk bagaimana prinsip Zero Trust dapat diterapkan pada authorization agent.

Kenapa “milik sendiri” bukan security boundary?

Karena agent internal tetap bisa membaca input eksternal.

Email.

Website.

PDF.

Customer ticket.

GitHub issue.

Supplier document.

Data tersebut bisa salah atau malicious.

Kalau agent dipercaya karena origin internal, input external bisa memanfaatkan trust itu.

Ini seperti employee internal yang menerima phishing.

Employee bukan attacker.

Tapi credential-nya bisa digunakan attacker.

Agent juga.

Ia bisa menjadi jalan masuk bagi instruction yang tidak seharusnya punya authority.

Zero Trust bilang: jangan otomatis percaya berdasarkan location atau ownership.

Verify setiap access sesuai context.

Agent ada di network internal?

So what.

Apakah action ini sesuai role?

User?

Task?

Risk?

Itu yang penting.

Prinsip pertama: verify explicitly.

Untuk manusia, kita biasa verifikasi user identity, device, location, risk, MFA.

Untuk agent, pertanyaan bertambah.

Agent mana?

Owner siapa?

Version apa?

Sedang bertindak atas nama siapa?

Task apa?

Tool apa yang ingin dipanggil?

Resource apa?

Apakah context berubah?

NIST menyoroti kebutuhan identification, authentication, authorization, auditing, dan non-repudiation untuk agent.

Artinya agent perlu first-class identity.

Jangan semua activity terlihat seperti user manusia.

Kalau agent finance berjalan otomatis jam 02.00, log harus bilang agent finance.

Bukan akun “admin.finance”.

Attribution jelas.

Prinsip kedua: least privilege.

Ini mungkin paling important.

Agent internal tidak perlu akses luas hanya karena trusted.

Mulai zero access.

Tambah yang dibutuhkan.

Microsoft pada Mei dan Juli 2026 menekankan permission agent sebaiknya eksplisit, scoped, dan jika memungkinkan dibatasi per task atau per waktu.

Agent hanya butuh read?

Jangan write.

Butuh satu folder?

Jangan drive.

Butuh satu API?

Jangan shell.

Butuh draft?

Jangan send.

Konsepnya sederhana.

Implementasinya kadang ribet.

Tapi security memang banyak menang dari detail.

Ada satu analogi kantor yang gampang.

Karyawan finance adalah orang internal.

Tetap tidak otomatis punya akses HR medical record.

Developer internal.

Tetap tidak otomatis boleh membaca payroll.

Kenapa agent internal harus beda?

Zero Trust memperlakukan internal sebagai environment yang tetap butuh policy.

Trust tidak diwariskan dari logo perusahaan.

Prinsip ketiga: assume breach.

Ini sering terdengar pesimis.

Sebenarnya realistis.

Anggap suatu saat agent akan dipengaruhi prompt injection.

Atau model salah.

Atau connector compromise.

Atau credential leak.

Atau data poisoning.

Kalau itu terjadi, apa consequence?

Design harus membuat jawabannya terbatas.

Microsoft pada 2026 menyebut prompt injection, data poisoning, lateral movement, dan overprivileged agent sebagai risk yang perlu ditangani dengan layered defense.

Assume breach berarti kita nggak menghabiskan seluruh energi mencoba membuat model mustahil salah.

Kita juga membuat system aman ketika model salah.

Contoh.

Agent membaca email supplier.

Di email ada malicious instruction.

Model termakan.

Ia mencoba mengirim file internal ke domain luar.

Zero Trust control bisa block karena agent tidak punya external send permission atau DLP mengenali data sensitif.

Model kalah.

Sistem tetap menang.

Ini architecture yang matang.

Bandingkan dengan prompt:

“Jangan pernah kirim data rahasia.”

Bagus sebagai guidance.

Tapi bukan enforcement.

Security jangan hanya tinggal di instruction layer.

Ada juga network segmentation.

Agent yang mengakses public web tidak otomatis perlu akses production network.

Browser agent research bisa ditempatkan di environment isolated.

Agent coding bisa punya sandbox.

Agent testing tidak perlu production credential.

Zero Trust mengurangi implicit trust antarzone.

Cloud modern sudah lama melakukan micro-segmentation.

Agent juga butuh.

Semakin banyak connector, semakin penting.

Ada satu hidden problem: tool trust.

Agent internal mungkin memanggil plugin atau MCP server pihak ketiga.

Siapa yang review?

Tool itu update?

Credential apa?

Data ke mana?

OWASP pada 2026 mendokumentasikan MCP tool poisoning sebagai risiko ketika tool server yang tampaknya legitimate memberikan instruction malicious ke agent.

Jadi Zero Trust tidak berhenti pada agent identity.

Tool juga harus dianggap bagian security boundary.

Allowlist.

Version.

Owner.

Permission.

Monitoring.

Third-party supply chain.

Kalau agent milik sendiri tetapi tool-nya tidak, system tetap punya external dependency.

Bahkan tool internal pun bisa compromise.

Again, verify.

Ada juga data aggregation risk.

Satu agent mungkin punya akses ke dua dataset yang secara terpisah aman.

Ketika digabung, hasilnya sensitif.

NIST concept paper 2026 secara spesifik menanyakan bagaimana authorization harus bekerja ketika agent mengagregasi data dari resource berbeda.

Ini problem baru yang menarik.

User boleh lihat dataset A.

Boleh lihat B.

Apakah boleh mendapatkan inferensi C dari kombinasi keduanya?

Tidak selalu.

AI kuat karena bisa menghubungkan.

Security harus memahami derived data.

Contoh HR.

Manager boleh lihat attendance team.

Boleh lihat performance score.

Kalau agent menggabungkan lalu membuat daftar “employee paling mungkin resign”, itu insight baru yang sensitif.

Permission source belum otomatis memberi permission terhadap semua inference.

Governance perlu policy pada use case.

Zero Trust untuk AI bukan hanya access file.

Juga access meaning.

Ada juga memory.

Agent internal mungkin menyimpan context lama.

User pindah role.

Permission berubah.

Memory masih membawa informasi dari role lama.

Apa yang terjadi?

Long-lived context harus dibatasi dan governed.

Microsoft pada 2026 menyarankan menyimpan hanya yang perlu, menerapkan data classification, dan membatasi memory jangka panjang.

Zero Trust berarti trust terus dievaluasi.

Bukan sekali pada saat agent dibuat.

Agent lifecycle juga penting.

Created.

Approved.

Changed.

Suspended.

Retired.

Setiap perubahan tool, data source, dan deployment environment bisa mengubah risk.

Microsoft guidance 2026 menyarankan re-review access ketika workflow atau data scope berubah material.

Ini mirip change management software.

Agent tidak boleh lolos review satu kali lalu bebas tumbuh.

Ada satu cultural problem di perusahaan.

Tim product sering melihat security sebagai pihak yang datang belakangan.

Mereka membangun agent dengan admin credential supaya POC cepat.

Demo berhasil.

Management suka.

Lalu security bilang privilege terlalu luas.

Semua frustrasi.

Lebih sehat desain Zero Trust dari pilot.

Dedicated identity.

Small scope.

Audit.

Safe test data.

Kalau nanti scale, foundation sudah ada.

POC tidak boleh menggunakan shortcut yang impossible dibuang.

Karena pilot punya kebiasaan buruk menjadi production.

“Cuma sementara” adalah salah satu kalimat paling panjang umurnya di IT.

Zero Trust juga bukan berarti setiap action harus minta human approval.

Itu misconception.

Agent low-risk bisa autonomous.

Yang penting environment dan permission sempit.

Misalnya agent merangkum public news.

Autonomy tinggi.

Risk rendah.

Agent bisa jalan sendiri.

Agent yang mengubah payroll?

Autonomy rendah atau approval ketat.

Ini risk-based.

Zero Trust bukan no trust.

Ia adalah no implicit trust.

Trust diberikan per action berdasarkan evidence.

Bahkan agent milik sendiri harus membuktikan authority.

Ada benefit productivity.

Kalau security architecture jelas, team bisa bergerak lebih cepat.

Approved connector.

Identity pattern.

Tool template.

Logging default.

JIT privilege.

Developer nggak perlu debate ulang.

Paved road.

Zero Trust yang mature justru mengurangi friction dibanding review manual ad hoc.

Semua tahu aturan.

Ada satu contoh kecil.

Agent customer service ingin refund.

Policy bilang:

Di bawah Rp100 ribu, jika order memenuhi criteria, agent boleh auto-refund.

Di atas itu, human approval.

Agent tidak punya ability mengubah rekening payout.

Semua logged.

Ini Zero Trust yang tidak terasa ribet ke customer.

Customer bahkan mungkin nggak tahu.

Resolution cepat.

Control tetap.

Perusahaan Indonesia juga perlu menyesuaikan dengan ecosystem yang campur.

Cloud.

On-prem.

SaaS.

WhatsApp.

Legacy.

API.

Agent mungkin berdiri di atas semuanya.

Jangan gunakan network internal sebagai tanda trust.

Legacy system justru sering punya auth lemah.

Agent yang bisa masuk ke sana perlu extra boundary.

Mungkin proxy.

Read-only API.

Service layer.

Jangan expose database langsung.

Zero Trust memaksa architecture lebih rapi.

Ada satu pertanyaan yang bisa dipakai untuk mengecek maturity.

Kalau agent ini dibajak oleh prompt injection selama 10 menit, apa yang bisa dilakukan?

Kalau jawabannya:

“Ya, technically semua yang bisa dilakukan user owner-nya,”

risk besar.

Kalau jawabannya:

“Hanya bisa membaca repository X, membuat draft issue, tidak bisa push code, token expire 30 menit,”

jauh lebih sehat.

Assume breach membuat pertanyaan ini normal.

Bukan paranoid.

Agent internal tidak perlu dicurigai sebagai musuh.

Tapi jangan diberi trust sebagai hadiah karena dibuat oleh tim kita.

Security tidak menilai niat.

Security menilai kemungkinan dan consequence.

Milik sendiri berarti kita punya tanggung jawab lebih besar untuk mengatur.

Bukan alasan untuk santai.

Zero Trust untuk AI agent pada akhirnya hanya membawa prinsip lama ke actor baru:

kenali siapa yang bertindak, verifikasi authority, beri akses minimum, catat action, dan desain seolah suatu hari sesuatu akan salah.

Karena sesuatu memang akan salah.

Yang menentukan apakah itu sekadar error kecil atau incident besar adalah seberapa banyak trust yang kita berikan tanpa perlu.

Dan itu sebabnya kata “internal” sebaiknya tidak pernah menjadi sinonim otomatis untuk “trusted”.

Zero Trust bukan sikap curiga. Ia cara membuat kepercayaan punya batas yang jelas dan bisa diuji.