Asisten bisa membaca dokumen yang tepat, lalu mengirim email yang keliru. Akunnya sah, alatnya bekerja, dan tidak ada kata sandi yang dicuri. Masalah muncul ketika informasi melewati batas yang tidak pernah ingin dibuka oleh pengguna.

Persoalan itu menjadi inti publikasi Google Research tentang privasi dan keamanan agen AI pada 5 Oktober 2026. Publikasi tersebut membahas hasil lokakarya di New York pada akhir 2025 yang mempertemukan lebih dari 50 peserta dari akademisi dan industri. Fokusnya adalah bagaimana agen otonom seharusnya menilai apakah suatu tindakan sesuai dengan situasi tempat ia bekerja.

Bagi tim yang menghubungkan agen ke dokumen, email, dan aplikasi bisnis, persoalannya sudah relevan hari ini: izin mengakses informasi tidak otomatis menjadi izin untuk mengirimkannya kepada setiap penerima yang bisa dijangkau.

Apa yang diusulkan riset keamanan kontekstual Google

Laporan lokakarya tersebut bertumpu pada Contextual Integrity, teori yang melihat privasi sebagai aliran informasi yang sesuai dengan konteks. Pertanyaannya mencakup siapa yang membagikan informasi tentang siapa, siapa penerimanya, jenis informasi yang dibagikan, dan aturan yang berlaku pada pertukaran itu.

Google memakai contoh sederhana. Anda mungkin membagikan daftar belanja hadiah kepada asisten, tetapi tetap ingin merahasiakannya dari keluarga dan teman yang akan menerima hadiah tersebut. Informasi tidak harus berupa kata sandi atau rekam medis agar tujuan pengirimannya menjadi penting.

Laporan itu memperluas cara berpikir tersebut ke tindakan agen secara umum. Peneliti mengusulkan mesin kebijakan kontekstual pada lapisan pengawas untuk memeriksa rencana tindakan dan aliran data sebelum dijalankan. Mereka juga membahas pembuatan kebijakan secara dinamis ketika tugas, alat, dan keadaan berubah.

Semua itu masih merupakan arah penelitian. Publikasi ini tidak membuktikan bahwa mesin kebijakan yang tersedia sudah bisa menyelesaikan setiap permintaan ambigu secara andal. Usulan lingkungan evaluasi multiagen dinamis yang disebut “Agent Gym” juga bagian dari agenda riset, bukan pengumuman tolok ukur siap pakai yang menjamin keamanan agen.

Pemanggilan alat yang sah tetap bisa melewati batas

Bayangkan asisten penjualan sedang menyiapkan email perpanjangan kontrak. Ia dapat membaca riwayat dukungan pelanggan dan catatan harga internal. Pengguna memintanya merangkum ketentuan perpanjangan yang telah disepakati untuk dikirim kepada pelanggan.

Catatan harga itu memuat batas diskon yang tidak dipublikasikan. Informasi tersebut membantu asisten memahami negosiasi, tetapi tidak semestinya masuk ke email pelanggan. Memberi akses baca ke catatan dan izin menyusun email belum menentukan perbedaan itu.

Dokumen lampiran juga bisa memuat instruksi agar agen meneruskan seluruh catatan ke alamat lain. Di sini muncul risiko prompt injection: konten yang seharusnya diolah mencoba mengambil alih kewenangan atas tugas. Aplikasi perlu menjaga pemisahan tersebut, sekalipun model menjelaskan langkah berikutnya dengan sangat meyakinkan.

Ini skenario editorial Linmas, bukan insiden yang dilaporkan Google. Contohnya menunjukkan mengapa pemeriksaan format pemanggilan alat saja belum cukup untuk menemukan kegagalan semacam ini.

Tempatkan pemeriksaan pada jalur keluar data

Tim bisa menerapkan kontrol yang berguna sekarang, sambil menunggu riset kebijakan kontekstual berkembang. Berikut rekomendasi praktis Linmas berdasarkan persoalan yang dibahas laporan tersebut:

  • Pisahkan membaca, menyusun draf, dan mengirim. Tugas yang hanya membutuhkan draf tidak perlu otomatis mendapat kredensial untuk mengirimnya. Berikan kemampuan minimum yang diperlukan pada langkah itu.
  • Periksa tujuan dan isi yang benar-benar akan dikirim. Validasi penerima, lampiran, dan kolom data yang diizinkan pada tahap pengiriman. Pembatasan domain email saja tidak akan mendeteksi harga internal yang terkirim ke pelanggan yang benar.
  • Simpan aturan berwenang di luar konten yang diambil. Dokumen dan respons alat boleh menjadi sumber fakta. Keduanya tidak boleh memberi izin kepada dirinya sendiri untuk mengganti penerima, mengekspor lebih banyak data, atau memanggil alat tambahan.
  • Periksa ulang ketika ada perubahan. Persetujuan atas satu draf harus berlaku untuk draf dan penerima tersebut. Jika salah satunya berubah, atau akses dicabut, aplikasi harus mengevaluasi tindakan kembali sebelum mengirim.

Gunakan pemeriksaan deterministik untuk aturan yang sudah diketahui aplikasi, seperti penerima yang diizinkan, kepemilikan data antar-tenant, dan kolom yang boleh diekspor. Model dapat membantu menafsirkan permintaan ambigu, tetapi tafsirnya tidak boleh mengesampingkan aturan akses yang tegas. Jika konteks yang dibutuhkan belum tersedia, tahan tindakan dan ajukan pertanyaan yang spesifik.

Pembedaan ini juga relevan untuk kontrol lingkungan eksekusi agen AI. Sandbox bisa membatasi layanan yang dapat dijangkau agen. Aplikasi tetap perlu menentukan informasi apa yang pantas masuk ke pesan yang dikirim melalui layanan yang diizinkan.

Menambah dialog konfirmasi saja belum cukup

Google menyoroti kelelahan akibat konfirmasi berulang ketika agen menangani tugas panjang dan mendelegasikan pekerjaan. Rentetan pertanyaan “Izinkan?” yang seragam bisa membuat pengguna makin sulit meninjau keputusan dengan cermat.

Pada contoh perpanjangan kontrak, konfirmasi sebaiknya menampilkan alamat pelanggan, pesan akhir, lampiran, dan informasi sensitif yang terlibat. Perubahan penerima harus terlihat jelas. Meminta pengguna menyetujui “lanjutkan alur kerja” memberi terlalu sedikit informasi untuk menilai tindakannya.

Simpan catatan secukupnya untuk menelusuri keputusan: identitas pelaksana, penerima yang dituju, aturan yang berlaku, referensi persetujuan, dan hasilnya. Hindari menjadikan log audit sebagai tempat penyimpanan kedua untuk seluruh dokumen pelanggan. Terapkan pembatasan akses dan masa retensi pada log itu sendiri.

Uji batasnya, termasuk jalur yang diperbolehkan

Gunakan data pelanggan sintetis di lingkungan pengujian yang berizin. Pastikan asisten dapat menyiapkan ringkasan yang diperbolehkan, sementara upaya menyertakan batas diskon internal atau mengirim ke penerima yang tidak diizinkan dihentikan sebelum pesan keluar. Kemudian ubah penerima setelah persetujuan diberikan dan buktikan bahwa persetujuan lama tidak bisa mengesahkan pengiriman baru.

Sertakan dokumen yang berisi instruksi untuk meneruskan materi di luar kebutuhan tugas. Periksa apakah aplikasi memperlakukannya sebagai konten tidak tepercaya dan kontrol pengiriman tetap berlaku. Penolakan dalam percakapan merupakan bukti yang berguna, tetapi periksa juga catatan pengiriman dan aktivitas alat: pengujian harus membuktikan bahwa tidak ada pesan tanpa izin yang terkirim.

Tinjauan keamanan dengan cakupan jelas dapat menelusuri pemeriksaan tersebut di dalam aplikasi dan menemukan bagian yang belum menegakkan batasnya. Lolos satu skenario tidak membuktikan bahwa semua keluaran model berikutnya aman. Namun, hasilnya memberi uji regresi konkret untuk batas yang dijanjikan sistem.

Mulai dari satu tindakan keluar, misalnya mengirim email atau mengekspor laporan. Tuliskan penerima yang diizinkan, data yang diperlukan, dan kondisi yang harus menghentikannya. Tiga keputusan itu membuat kebutuhan privasi cukup spesifik untuk ditinjau dan diuji.

Sumber diperiksa pada 9 Oktober 2026. Contoh, rekomendasi implementasi, dan ilustrasi cyberpunk merupakan materi editorial Linmas. Ilustrasi tersebut bukan diagram arsitektur resmi Google.