Sebuah alat otomatisasi yang dibangun di atas Safari MCP menutup tab dasbor pengembang saat sedang dibaca. Insiden ini mengungkap celah tersembunyi pada guard yang seharusnya mencegah agen berbasis AI menyentuh tab mana pun yang bukan miliknya, dan ini menunjukkan mengapa kategori “safe-by-default” dapat menjadi liabilitas.

Guard yang bekerja—sampai akhirnya tidak

Alat tersebut menandai setiap tab yang dibuatnya dengan pengidentifikasi internal. Sebelum agen mengeluarkan perintah apa pun, guard akan memeriksa penanda tersebut; jika penanda tidak ada, guard akan menolak untuk bertindak. Dalam praktiknya, guard berhasil menghentikan agen agar tidak membaca halaman yang tidak dibukanya—tepat seperti yang dirancang.

Saat mengisi sebuah formulir, halaman tersebut dialihkan ke domain yang berbeda. Pengalihan tersebut menghapus penanda, sehingga tab menjadi tidak berlabel. Guard mendeteksi penanda yang hilang dan melaporkan, “Saya tidak dapat memverifikasi kepemilikan, jadi saya tidak akan membaca tab ini.” Pada titik itu, pemeriksaan keamanan berperilaku sesuai rencana.

Kode pembersihan yang melampaui batas

Berikutnya muncul rutinitas pembersihan manual yang dimaksudkan untuk menutup tab yatim piatu (orphaned tabs)—yaitu tab yang tidak memiliki penanda. Rutinitas tersebut meminta alat untuk “menutup sebuah tab” tanpa terlebih dahulu mengonfirmasi kepemilikan. Karena guard tidak dapat membuktikan bahwa tab tersebut adalah miliknya, alat tersebut beralih ke tindakan default: “tutup tab saat ini.” Tab saat ini adalah dasbor yang sedang dibaca oleh pengembang, bukan tab yatim piatu.

Hasilnya adalah operasi destruktif yang dipicu oleh jalur keamanan yang seharusnya menjadi jalan buntu.

Tiga lapisan yang menganggap “tidak ada kepemilikan” sebagai izin

  1. Kategorisasi perintah – Daftar yang mengelompokkan perintah menempatkan close_tab di bawah kategori luas “tab management”. Pengembang berasumsi bahwa semua hal dalam kategori tersebut tidak berbahaya karena perintah lain (seperti “list tabs”) hanya membaca informasi. Tidak ada catatan eksplisit yang menandai close_tab sebagai perintah destruktif, sehingga ia mewarisi persepsi keamanan dari perintah-perintah di sekitarnya.
  2. Kebijakan tingkat ekstensi – Ekstensi Safari yang memediasi semua tindakan browser mengizinkan operasi apa pun ketika sesi tidak memiliki kepemilikan atas apa pun. Aturan tersebut berfungsi untuk tindakan read-only, tetapi juga membuka pintu bagi close_tab untuk dieksekusi tanpa pemeriksaan asal-usul (provenance check).
  3. Ketidakcocokan logika – Rutinitas pembersihan memeriksa bendera (flag) kepemilikan pada satu tab, tetapi kemudian memanggil fungsi tutup pada tab yang dilaporkan browser sebagai “current” (saat ini). Ketidakcocokan ini membuat kegagalan guard dalam menemukan penanda justru melewati perintah tutup dan mengalihkannya ke target yang salah.

Setiap lapisan berasumsi bahwa “tidak ada kepemilikan yang tercatat” berarti “aman untuk bertindak,” dan secara bersama-sama mereka menghasilkan perintah penutupan tab yang berjalan tanpa bukti legitimasi apa pun.

Perbaikan: bukti kepemilikan wajib untuk tindakan destruktif

Logika yang direvisi memisahkan jalur read-only dari jalur destruktif. Sekarang, sebelum perintah close_tab dapat dieksekusi, alat tersebut harus menyertakan penanda yang valid untuk tab target. Jika penanda hilang, perintah tersebut akan memunculkan error alih-alih beralih ke tab saat ini. Guard tidak lagi beralih ke cabang generik “lakukan sesuatu.”

Perubahan ini menghilangkan kondisi ambigu di mana penanda yang hilang dapat diartikan sebagai “tidak ada yang perlu dilakukan” atau “lanjutkan dan bertindak.” Dengan memaksakan kegagalan eksplisit, alat ini melindungi pekerjaan pengguna dari kehilangan yang tidak disengaja.

Apa yang harus diperhatikan pengembang

  • Jangan biarkan nama kategori menentukan keamanan – Label seperti “tab management” tidak memberikan informasi apa pun tentang dampak dari setiap perintah di dalamnya. Catat biaya (cost) dari setiap operasi (baca vs. hancurkan) di samping perintah itu sendiri.
  • Kondisi guard harus sesuai dengan tingkat keparahan tindakan – Pemeriksaan yang memadai untuk permintaan baca tidaklah cukup untuk perintah yang dapat menghapus data. Bangun alur validasi (validation pipelines) yang terpisah untuk setiap kelas dampak.
  • Hindari fallback implisit – Ketika guard tidak dapat memverifikasi kepemilikan, respons paling aman adalah membatalkan (abort), bukan memilih target default. Tindakan default adalah sumber umum bug eskalasi hak istimewa (privilege-escalation).
  • Audit asumsi kedekatan (adjacency) – Tinjau daftar atau menu apa pun di mana perintah-perintah diletakkan berdampingan. Perintah yang tampak tidak berbahaya dapat mewarisi kepercayaan yang diberikan pada perintah di sekitarnya jika kode tidak mengevaluasi ulang keamanan secara eksplisit.

Kesimpulan

Hilangnya guard kepemilikan bukanlah sebuah bug; itu adalah celah desain. Perlakukan setiap perintah destruktif sebagai domain keamanan terpisah yang menuntut bukti otoritas yang eksplisit, dan jangan pernah membiarkan “tidak ada penanda” diinterpretasikan sebagai “lanjutkan.” Hanya dengan cara itulah alat otomatisasi dapat melindungi tab yang seharusnya mereka kelola.