AI agent bukan lagi barang baru di enterprise. Mereka menjadwalkan rapat, mengakses data, menjalankan workflow, menulis kode, dan mengambil keputusan secara real time. Produktivitas meningkat jauh melampaui batas kemampuan manusia.

Sampai suatu saat tim keamanan bertanya:

“Wait… siapa yang menyetujui aksi ini?”

Pertanyaan sederhana yang dulu selalu ada jawaban, sekarang tidak bisa dijawab dengan mudah.

AI Agent Mematahkan Model Akses Tradisional

Masalahnya bukan karena agent itu jahat. Masalahnya adalah AI agent bukan manusia, dan bukan pula service account. Mereka adalah entitas baru yang sama sekali tidak sesuai dengan model IAM yang kita gunakan selama 20 tahun terakhir.

Setelah agent diizinkan berjalan, mereka tidak berhenti. Mereka beroperasi 24/7, berintegrasi dengan sistem baru, menumpuk izin dari waktu ke waktu, dan perlahan menjadi entitas yang memiliki akses lebih luas dari siapapun di perusahaan.

Ini adalah access drift pada steroid.

Agent tidak hanya mengotomatisasi aksi manusia. Mereka memperluas akses manusia. Seorang user yang tidak boleh mengakses data tertentu, bisa meminta agent untuk melakukannya. Secara teknis akses itu sah – agent punya izin. Tapi secara konteks, itu adalah celah keamanan yang tidak terdeteksi oleh IAM tradisional.

3 Tipe AI Agent Dan Resikonya

Tidak semua agent memiliki resiko yang sama. Ada hierarki resiko yang harus anda pahami.

Personal Agent (User-Owned)

Agent milik individu karyawan, beroperasi di dalam batas izin user tersebut. Jika user kehilangan akses, agent juga kehilangan akses.

• Resiko: Rendah
• Blast radius: Hanya user tersebut
• Pengawasan: Mudah

Third-Party Agent (Vendor-Owned)

Agent yang tertanam di platform SaaS yang anda gunakan. Contoh: fitur AI di CRM, kolaborasi tool, atau platform keamanan.

• Resiko: Sedang
• Akuntabilitas: Ada di vendor
• Resiko utama: Supply chain

Organizational Agent (Shared)

Ini adalah bom waktu yang hampir semua perusahaan miliki tapi tidak sadari. Agent yang dibagikan antar tim, berjalan di background, memiliki izin luas lintas sistem, dan tidak memiliki owner yang jelas.

Ini adalah tipe agent dengan resiko tertinggi. Ketika sesuatu salah, tidak ada yang bertanggung jawab. Tidak ada yang tahu persis apa yang bisa dilakukan agent ini, dan tidak ada yang berani mematikannya.

Masalah Authorization Bypass Yang Tidak Ada Yang Bicarakan

Ini adalah resiko paling berbahaya dan paling sedikit dipahami:

AI agent bukan hanya mengeksekusi perintah. Mereka menjadi perantara akses.

Alih-alih user berinteraksi langsung dengan sistem, user berbicara ke agent, dan agent yang berbicara ke sistem. Agent menggunakan kredensial sendiri, token sendiri, dan izin sendiri.

Hasilnya:

• Akses secara teknis sah
• Tidak ada alert di SIEM
• Tidak ada log yang menunjukkan user melakukan aksi tersebut
• User tidak pernah memiliki izin untuk melakukan aksi itu

Ini adalah authorization bypass yang sempurna. Dan itu terjadi setiap hari di ribuan perusahaan saat ini.

Apa Yang Harus Berubah

Mengamankan AI agent tidak bisa dilakukan dengan patch IAM lama. Anda perlu memikirkan ulang seluruh model resiko.

1. Setiap agent HARUS memiliki owner

Tidak ada pengecualian. Tanpa owner yang jelas, agent tidak boleh berjalan.

2. Petakan hubungan User, Agent, dan Sistem

Jangan hanya tahu apa yang bisa diakses agent. Ketahui siapa saja yang bisa memanggil agent tersebut, dan dengan wewenang apa.

3. Izin agent harus kadaluarsa

Jangan berikan izin permanen. Setiap 30 hari harus ada review ulang.

4. Semua aksi agent harus bisa diaudit

Setiap aksi yang diambil agent harus ada jejak yang jelas: siapa yang meminta, kapan, dan apa hasilnya.

Penutup

AI agent adalah peningkatan produktivitas terbesar sejak internet. Tapi mereka juga adalah ancaman keamanan terbesar yang pernah kita hadapi.

Masalahnya bukan teknologinya. Masalahnya adalah kita masih menggunakan aturan keamanan tahun 2005 untuk mengatur teknologi tahun 2026.

Sampai kita berani memikirkan ulang model akses, pertanyaan “siapa yang menyetujui ini?” akan tetap tidak terjawab. Dan suatu hari, ketika insiden terjadi, tidak ada yang bisa disalahkan.

Artikel ini berdasarkan analisis dari Wing Security tentang resiko AI agent di lingkungan enterprise.