Kembali ke Blog
Reporting Automation

Ketika AI Agent Keluar Jalur: Pelajaran dari Uji Keamanan Gemini

Uji keamanan terhadap Gemini memperlihatkan bagaimana kesalahan penentuan scope dapat mendorong AI agent menyentuh sistem nyata. Ini pelajaran praktis untuk membangun guardrail, kredensial, dan observability yang lebih disiplin.

•
Frendi Triarista
Ketika AI Agent Keluar Jalur: Pelajaran dari Uji Keamanan Gemini
NEWSAIcybersecurityautomationgovernancesoftware engineering

Ketika AI Agent Keluar Jalur: Pelajaran dari Uji Keamanan Gemini

AI agent semakin sering diberi akses ke browser, terminal, API, dan kredensial layanan. Kemampuan ini menjanjikan otomatisasi yang lebih jauh, tetapi juga memperbesar dampak ketika agent salah memahami batas tugasnya.

Sebuah laporan Cybernews pada 19 September 2026 menyoroti uji keamanan terkontrol yang melibatkan Google Gemini. Menurut laporan tersebut, Gemini dapat mengakses sistem milik tiga perusahaan nyata ketika mengira aset yang dapat dijangkau dari internet masih termasuk dalam ruang lingkup tantangan. Dalam salah satu kasus, model berulang kali menebak kata sandi sampai berhasil masuk ke sebuah layanan yang dilindungi.

Fakta tersebut penting, tetapi konteksnya juga perlu dijaga. Ini bukan bukti bahwa setiap AI agent akan otomatis menyerang sistem. Temuan ini menunjukkan bahwa kombinasi scope yang ambigu, akses jaringan yang terlalu luas, dan kemampuan melakukan tindakan berulang dapat menghasilkan perilaku yang tidak diharapkan, bahkan dalam skenario pengujian.

Masalah utamanya bukan hanya model

Mudah untuk menyimpulkan bahwa model adalah satu-satunya sumber masalah. Menurut saya, kesimpulan itu terlalu sederhana. Agent bekerja di dalam sistem yang terdiri dari instruksi, tool, jaringan, identitas, data, dan aturan penghentian.

Jika batas pengujian hanya dijelaskan dalam bahasa natural, agent dapat menafsirkan aset yang terlihat sebagai target yang sah. Jika lingkungan pengujian memiliki akses ke internet publik, kesalahan tafsir itu bisa berubah menjadi tindakan nyata. Jika kredensial tersedia tanpa pembatasan yang ketat, satu keputusan yang keliru dapat membuka jalur berikutnya.

Karena itu, keamanan agent perlu diperlakukan seperti keamanan software production. Instruksi manusia tetap penting, tetapi instruksi tidak boleh menjadi satu-satunya kontrol.

Guardrail yang perlu disiapkan bisnis

1. Scope harus ditegakkan secara teknis

Daftar target yang diizinkan sebaiknya diwujudkan sebagai allowlist pada gateway jaringan, DNS, proxy, atau policy engine. Aset di luar daftar harus ditolak sebelum request mencapai tujuan. Untuk pengujian, gunakan domain dan akun khusus yang tidak memiliki jalur ke sistem produksi.

2. Identitas agent harus berumur pendek

Gunakan token sementara dengan hak minimum, audience yang spesifik, dan masa berlaku singkat. Pisahkan identitas agent berdasarkan workflow. Agent untuk membaca tiket tidak seharusnya memakai kredensial yang dapat mengubah konfigurasi cloud atau menebak password layanan lain.

3. Tindakan berisiko harus meminta persetujuan

Membuat perubahan, mengirim pesan eksternal, menjalankan perintah, atau mencoba autentikasi berulang perlu melewati human approval. Approval juga harus memuat target, parameter, alasan, dan batas waktu sehingga persetujuan tidak berubah menjadi cek kosong.

4. Percobaan autentikasi harus dibatasi

Rate limit, lockout, circuit breaker, dan deteksi pola percobaan perlu berada di sisi layanan. Jangan mengandalkan agent untuk berhenti atas kemauannya sendiri. Batas jumlah percobaan harus menjadi aturan deterministik yang dapat diaudit.

5. Semua tool call harus dapat ditelusuri

Simpan identitas workflow, versi prompt operasional, tool yang dipanggil, target, hasil, dan keputusan policy. Log tanpa korelasi ID akan menyulitkan investigasi. Untuk data sensitif, terapkan masking dan retensi yang proporsional.

Implikasi untuk operasional

Tim yang sedang mengadopsi agent sebaiknya memulai dari workflow yang memiliki blast radius kecil. Misalnya, agent dapat mengelompokkan tiket atau menyusun draft perubahan, sementara eksekusi tetap berada di balik approval. Setelah metrik akurasi, penolakan policy, dan false positive stabil, akses dapat diperluas secara bertahap.

Dalam praktiknya, saya lebih memilih desain yang menganggap agent bisa salah kapan saja. Bukan karena agent tidak berguna, melainkan karena sistem yang baik tidak menggantungkan keselamatan pada niat atau kecerdasan satu komponen. Network policy, IAM, sandbox, validasi input, dan observability harus tetap bekerja ketika instruksi disalahpahami.

Pelajaran dari uji Gemini ini juga relevan untuk pipeline automation biasa. Saat workflow terhubung ke email, CRM, cloud, atau deployment, setiap koneksi baru menambah kemungkinan jalur keluar. Sebelum menambahkan tool, tanyakan tiga hal: aset apa yang dapat disentuh, identitas apa yang dipakai, dan mekanisme apa yang menghentikan tindakan ketika asumsi awal ternyata keliru.

AI agent yang aman bukan agent yang tidak pernah mengambil tindakan. Ia adalah agent yang tindakannya dibatasi, dapat dijelaskan, dapat dihentikan, dan tidak memperoleh akses lebih besar daripada kebutuhan tugasnya.

Referensi