Setiap platform mengaku serius soal keamanan. Tidak ada yang mengatakannya di laporan pasca-kebocoran data — itulah saat mereka akhirnya menjelaskan arsitekturnya, bukan sekadar kata sifat. Jadi mari langsung ke arsitekturnya. Cara termudah menjelaskan isolasi tenant adalah dengan membahas tiga kesalahan umum yang biasa dilakukan tim, dan apa yang rusak ketika itu terjadi.
Kesalahan pertama: memfilter berdasarkan tenant ID di kode aplikasi
Ini menjadi default karena memang hal paling jelas untuk ditulis: setiap query mendapat klausa WHERE user_id = ? , dan selama setiap developer mengingatnya, setiap permintaan tetap berada di dalam pagarnya sendiri. Kehancurannya baru terlihat belakangan, saat codebase memiliki empat ratus endpoint alih-alih empat. Seseorang menambahkan query pelaporan yang menggabungkan dua tabel dan lupa filter pada tabel kedua. Orang lain membuat alat admin "hanya untuk internal" yang melakukan query tanpa scoping tenant sama sekali, karena saat itu terasa aman. Tidak ada kesalahan ini yang memicu test gagal, karena query tetap mengembalikan baris yang valid — hanya saja baris valid milik tenant yang salah.
Kami tidak bergantung pada setiap query untuk selalu ingat bertanya dengan sopan. Row-level security diberlakukan di lapisan database, sehingga database itu sendiri menolak mengembalikan baris milik tenant lain apa pun yang diminta oleh kode pemanggil. Tidak ada jalur bypass istimewa yang bersembunyi di alur permintaan pula — kebijakan ini berlaku selalu, termasuk pada jalur yang mungkin tergoda kita anggap tepercaya.
Kesalahan kedua: memperlakukan sandbox sebagai optimisasi, bukan batasan
Agent di sini menjalankan kode sungguhan — itulah inti dari produk ini — dan jalan pintas yang menggoda adalah menjalankan kode itu di tempat yang praktis lalu menguncinya "kalau sempat." Kehancuran dalam skenario ini terlihat seperti dependensi yang disusupi tertarik masuk saat build lalu menjangkau internet terbuka, atau proses agent satu tenant membaca file milik workspace yang seharusnya tidak pernah bisa dilihatnya, karena filesystem dibagikan secara default dan dibatasi hanya berdasarkan pengecualian.
Beban kerja agent justru berjalan di lingkungan terisolasi:
- Filesystem yang dikunci ketat.
- Akses keluar jaringan berupa daftar izin, bukan pintu terbuka.
Agent yang mengerjakan build Anda hanya melihat workspace Anda, titik. Kode yang tidak tepercaya — termasuk build dari aplikasi Anda sendiri — dikompilasi di dalam container di mana isolasinya bersifat struktural, bukan sekadar pengaturan yang mungkin lupa diaktifkan seseorang.
Kesalahan ketiga: menyerahkan kredensial ke agent
Ini yang paling halus, dan menurut saya paling banyak mengecoh tim. Jika agent perlu deploy ke host Anda atau posting ke toko Anda, jalan terpendeknya adalah menaruh token OAuth atau SSH key di dalam konteksnya dan membiarkan ia menggunakannya. Itu juga jalan terpendek menuju bencana: instruksi hasil prompt injection, tindakan yang dihalusinasi, kredensial yang berakhir tersimpan di log transkrip di tempat yang seharusnya tidak boleh. Agent tidak perlu berniat jahat agar hal ini bisa salah — ia cukup salah sekali saja, sambil memegang kunci sungguhan.
Karena itu agent tidak pernah memegang kunci. Kredensial yang terhubung disimpan dengan cakupan khusus tenant Anda dan hanya digunakan untuk tindakan yang Anda hubungkan:
- Akun toko
- Token OAuth media sosial
- Kunci deploy
- Akun layanan Google
Ketika agent perlu deploy atau mengunggah, ia meminta platform untuk melakukannya; platform yang memegang kredensial dan menjalankan tindakan tersebut. Agent tidak pernah melihat rahasia yang ia minta untuk digunakan. Dan pada sisi analitik, di mana properti Google terkadang dibagikan di beberapa situs, setiap pengambilan data GA4 difilter berdasarkan hostname sehingga dasbor Anda tidak akan tanpa sengaja menampilkan angka milik orang lain meskipun properti dasarnya mengumpulkan data dari banyak domain.
Apa yang sebenarnya diperiksa sebelum apa pun dirilis
Dua aturan berlaku di seluruh platform ini, dan paling penting persis di sini:
- Agent tidak bisa membelanjakan uang Anda.
- Agent tidak bisa memposting atas nama Anda.
Keduanya membutuhkan klik dari Anda. Artinya, hari terburuk sekalipun bagi komponen otomatis mana pun tetap tidak menyentuh dompet atau reputasi Anda — jangkauan dampaknya dibatasi secara desain, bukan bergantung pada penilaian baik agent. Detail lengkap tentang retensi dan penghapusan data ada di Kebijakan Privasi; permintaan penghapusan berlaku dalam 30 hari.
