Jika agen AI Anda dapat menulis kode, ia dapat menulis kode yang buruk. Jika ia dapat memanggil alat, ia dapat memanggil alat yang salah dengan argumen yang salah. Solusinya bukanlah *prompt* yang lebih cerdas. Ini adalah batasan isolasi antara keluaran model dan mesin yang menjalankannya. CubeSandbox adalah salah satu sistem yang dibangun khusus untuk batasan tersebut, dan penting untuk memahami apa yang dilakukannya, bagaimana perbandingannya dengan pendekatan lain, dan di mana posisinya ketika agen Anda mulai menyentuh API nyata dan data nyata.
TL;DR
CubeSandbox adalah layanan *sandbox* sumber terbuka (open-source) yang terisolasi perangkat keras dari Tencent Cloud untuk menjalankan kode agen AI. Setiap *sandbox* mendapatkan kernel OS tamu sendiri melalui KVM, dimulai dalam sekitar 60ms, dan menggunakan di bawah 5MB *overhead* memori. Ini berlisensi Apache 2.0 dan kompatibel secara *drop-in* dengan SDK E2B.
Pendahuluan
Sistem agensi kini menulis dan mengeksekusi kode dalam produksi. Agen pengodean menghasilkan skrip Python dan menjalankannya. Agen riset mengikis halaman, menguraikannya, dan menyalurkan hasilnya ke langkah lain. Agen data memuat CSV dan menjalankan transformasi yang diputuskan model pada saat *runtime*. Tidak ada kode tersebut yang ditinjau oleh manusia sebelum dijalankan. Itulah masalah inti yang dipecahkan oleh *sandboxing* agen: Anda perlu mengeksekusi instruksi yang tidak tepercaya, yang dihasilkan model, tanpa memberikan *host* Anda, sistem berkas Anda, kredensial Anda, atau jaringan Anda kepada mereka.
Ini menjadi lebih penting seiring dengan agen yang mendapatkan otonomi. Model yang salah mengenai kueri SQL itu menjengkelkan. Model yang salah mengenai rm -rf atau yang mengikuti instruksi yang disuntikkan di dalam halaman web yang di-*scrape* adalah insiden keamanan. *Sandboxing* menarik garis keras: agen dapat melakukan apa pun yang diinginkannya di dalam lingkungan yang sekali pakai dan terisolasi, dan tidak ada yang bocor keluar dari sana.
Ada masalah kedua yang lebih tenang. Agen tidak hanya menjalankan kode; mereka memanggil API dan alat. Sebelum Anda memercayai agen untuk mengakses API pembayaran Anda atau layanan internal Anda dari dalam *sandbox*, Anda perlu tahu bahwa API tersebut berfungsi dengan benar dan bahwa agen memanggilnya sesuai harapan Anda. Di situlah perkakas API mengambil tempat di samping isolasi *runtime*. Platform seperti Apidog memungkinkan Anda melakukan *mock* dan menguji titik akhir yang akan dipanggil agen, sehingga Anda memvalidasi kontrak sebelum sistem otonom mulai menggunakannya dalam eksekusi *sandboxed*. Jika Anda sudah memikirkan arsitektur agen, panduan kami tentang arsitektur AI agensi mencakup bagaimana lapisan eksekusi dan alat ini saling melengkapi.
Sisa artikel ini menjelaskan apa itu CubeSandbox, mengapa agen membutuhkan *sandbox*, bagaimana model isolasi berbeda, dan bagaimana ini terhubung dengan pengujian API yang diandalkan agen Anda.
Apa Itu CubeSandbox?
CubeSandbox adalah sistem *sandbox* keamanan untuk menjalankan kode agen AI, yang di-*open-source* oleh Tencent Cloud di bawah lisensi Apache 2.0 pada April 2026. Slogan GitHub-nya menggambarkannya dengan jelas: “*Sandbox* Instan, Konkuren, Aman & Ringan untuk Agen AI.” Ini bukan hanya SDK. Ini adalah tumpukan *sandbox-as-a-service* lengkap, sebagian besar ditulis dalam Rust, yang dapat Anda gunakan sendiri.
Arsitekturnya dibangun di atas RustVMM dan KVM, lapisan virtualisasi kernel Linux yang sama yang digunakan oleh banyak *hypervisor* *cloud*. Menurut dokumentasi proyek dan pengumuman resmi, sistem ini terbagi menjadi beberapa komponen:
- CubeAPI: *gateway* REST yang mencerminkan antarmuka *sandbox* E2B.
- CubeMaster: *orchestrator* klaster yang menjadwalkan *sandbox* di seluruh *node*.
- CubeHypervisor dan CubeShim: lapisan virtualisasi KVM yang mem-*boot* dan mengelola setiap *microVM*.
- Cubelet dan CubeProxy: agen tingkat *node* yang menjalankan dan mengarahkan ke *sandbox*.
- CubeVS: lapisan jaringan bertenaga eBPF yang memberlakukan isolasi jaringan antar-*sandbox* pada tingkat kernel.
Karakteristik utamanya adalah setiap *sandbox* mendapatkan kernel OS tamu khusus miliknya sendiri. Itu adalah model isolasi yang berbeda dan lebih kuat dibandingkan dengan *container*, yang berbagi kernel *host*. Angka yang diterbitkan Tencent menyatakan *cold start* sekitar 60ms pada konkurensi tunggal (rata-rata 67ms dengan P95 sekitar 90ms di bawah 50 pembuatan konkuren), di bawah 5MB *overhead* memori per instans, dan kemampuan untuk menjalankan ribuan *sandbox* pada satu *host* besar. Materi pers mengutip server 96-vCPU yang mendukung lebih dari 2.000 *sandbox* konkuren. Tencent mengatakan CubeSandbox telah berjalan dalam skala besar di dalam infrastrukturnya sendiri dan bahwa MiniMax telah menggunakannya untuk pelatihan *reinforcement-learning* agensi skala besar di lingkungan heterogen.
Beberapa fitur canggih, seperti *snapshot rollback* tingkat acara untuk *checkpointing* dan pemulihan keadaan *sandbox*, dijelaskan masih dalam pengembangan. Perlakukan item yang berorientasi ke depan sebagai *roadmap*, bukan jaminan yang sudah dikirimkan, dan periksa repositori untuk status saat ini. Metodologi *benchmark* publik di luar angka vendor sendiri terbatas, jadi validasi klaim kinerja terhadap beban kerja Anda sendiri.
Untuk detail kanonis, sumber kebenaran adalah repositori GitHub CubeSandbox dan situs dokumentasi resmi.
Mengapa Agen AI Membutuhkan Sandbox
Penting untuk lebih konkret tentang ancaman, karena “keamanan” terlalu samar untuk dijadikan dasar desain. Ada tiga mode kegagalan yang mendorong tim menuju *sandboxing*.
Kode yang Dihasilkan Berisiko. Model menghasilkan kode yang diyakininya benar. Terkadang tidak. Ia menghapus direktori yang salah, menghabiskan memori dalam perulangan ketat, atau menulis berkas di tempat yang tidak seharusnya. Tidak ada yang bersifat jahat; itu hanya salah, dan kode yang salah dengan akses *host* berbahaya. Agen tidak memiliki konsep *blast radius* kecuali Anda memberikannya.
Panggilan Alat yang Tidak Tepercaya. Agen memanggil alat dan API berdasarkan apa yang diputuskan model saat *runtime*. Jika model diarahkan oleh injeksi *prompt* yang tersembunyi dalam dokumen, halaman web, atau respons alat, ia dapat memanggil alat yang merusak, meneruskan argumen yang dikendalikan penyerang, atau merangkai panggilan dengan cara yang tidak pernah Anda inginkan. Model bukanlah aktor yang tepercaya di sini; ia adalah penafsir dari teks apa pun yang mencapai jendela konteksnya. Kami membahas lebih dalam hal ini dalam artikel kami tentang agen AI sebagai konsumen API baru, yang mencakup mengapa asumsi kepercayaan API tradisional rusak dengan pemanggil otonom.
Eksfiltrasi Data. Ini adalah salah satu yang diremehkan orang. Agen dengan akses jaringan dan akses ke rahasia dapat diubah menjadi saluran eksfiltrasi. Instruksi yang terkontaminasi memerintahkan agen untuk membaca variabel lingkungan yang menyimpan kunci API dan melakukan POST ke titik akhir eksternal. Tanpa penyaringan *egress* dan isolasi kredensial, batasan *sandbox* menjadi tidak berarti karena data keluar begitu saja. Inilah sebabnya CubeSandbox memasangkan isolasi tingkat kernel dengan penyaringan *egress* berbasis eBPF melalui CubeVS; isolasi proses tidak cukup jika jaringan terbuka lebar.
Benang merahnya: Anda tidak dapat mengasumsikan agen akan berperilaku baik, karena perilaku agen sebagian dikendalikan oleh data tidak tepercaya apa pun yang diserapnya. *Sandbox* memungkinkan Anda berhenti mempertimbangkan apakah model itu dapat dipercaya dan mulai mempertimbangkan batasan yang tetap berlaku. Untuk pandangan praktis tentang penyelidikan perilaku ini sebelum mencapai produksi, lihat cara menguji agen AI yang memanggil API.
Cara Kerja Sandbox Agen: Model Isolasi
Tidak semua *sandbox* mengisolasi dengan cara yang sama, dan perbedaannya penting untuk keamanan dan kinerja. Ada empat pendekatan luas yang akan Anda lihat dalam ekosistem agen.
Isolasi Tingkat Proses. Jalankan kode sebagai proses OS terbatas dengan filter seccomp, kapabilitas yang dijatuhkan, *namespace*, dan *cgroup*. Ini adalah opsi paling ringan dan terlemah. Ini berbagi kernel *host*, sehingga *exploit* kernel berarti kompromi *host*. Baik untuk kode yang sebagian besar Anda percayai; lemah untuk keluaran model yang arbitrer.
Kontainer. Kontainer bergaya Docker menambahkan *namespacing* dan batasan sumber daya serta familiar secara operasional. Namun, kontainer berbagi kernel *host* secara desain. Kerentanan *container escape* adalah kelas *bug* yang nyata dan berulang, dan “kode tidak tepercaya dalam kontainer kernel bersama” adalah titik lemah yang diketahui. Banyak tim memulai dari sini karena mudah, lalu mencapai batas isolasi.
MicroVM. Sebuah *microVM* mem-*boot* kernel tamu minimal di dalam virtualisasi perangkat keras (KVM). Kode agen berjalan di kernelnya sendiri, sehingga *exploit* tingkat kernel terkandung pada VM yang dapat dibuang, bukan *host*. Firecracker mempopulerkan model ini untuk beban kerja *serverless*, dan CubeSandbox berada dalam kategori ini, menggunakan RustVMM dan KVM dengan kernel tamu per-*sandbox*. Pertukaran historisnya adalah waktu *startup*; *microVM* lebih lambat untuk di-*boot* daripada *container*. Implementasi modern mengatasi hal itu dengan *snapshotting* dan *pre-provisioning* sumber daya, itulah sebabnya CubeSandbox melaporkan waktu *start* di bawah 100ms.
Kernel Aplikasi. gVisor mengambil jalur yang berbeda: ia mencegat panggilan sistem di *userspace* dan mengimplementasikan antarmuka mirip Linux itu sendiri, sehingga beban kerja tidak pernah berbicara langsung ke kernel *host*. Ini adalah lapisan isolasi yang kuat tanpa VM penuh, dengan beberapa kompatibilitas *syscall* dan *tradeoff* kinerja.
Berikut perbandingan pendekatan-pendekatan ini berdasarkan dimensi yang penting bagi agen:
| Pendekatan | Kekuatan isolasi | Cold start | Overhead | Berbagi kernel | Contoh |
|---|---|---|---|---|---|
| Proses + seccomp | Rendah | Instan | Minimal | Kernel host bersama | Subproses terbatas, nsjail |
| Kontainer | Sedang | ~puluhan ms | Rendah | Kernel host bersama | Docker, containerd |
| MicroVM | Tinggi | ~50–150ms | Rendah–sedang | Kernel tamu khusus | CubeSandbox, Firecracker |
| Kernel Aplikasi | Tinggi | ~puluhan ms | Rendah–sedang | Dicegat di userspace | gVisor |
| API Sandbox Terhosting | Tinggi (terkelola) | Bervariasi | Dikelola untuk Anda | Dikelola untuk Anda | E2B, penawaran terhosting |
Tidak ada pemenang tunggal. Keputusan yang tepat tergantung pada seberapa besar Anda memercayai kode tersebut, seberapa cepat Anda membutuhkan *cold start*, apakah Anda dapat menjalankan KVM, dan apakah Anda ingin mengoperasikan infrastruktur sendiri atau mengonsumsinya sebagai layanan.
CubeSandbox dalam Lanskap
Posisi CubeSandbox spesifik: isolasi tingkat perangkat keras dengan *cold start* yang cukup cepat untuk terasa seperti *container*, yang digunakan sebagai sesuatu yang Anda jalankan daripada layanan yang Anda sewa. Hal itu menempatkannya dalam perbandingan konseptual langsung dengan tiga titik referensi.
Vs. Kontainer. Sebuah *container* berbagi kernel *host*; CubeSandbox memberikan setiap *sandbox* kernelnya sendiri. Untuk kode yang dihasilkan agen secara arbitrer, itulah argumen keamanannya. Biayanya adalah Anda memerlukan *host* Linux x86_64 yang mendukung KVM (server *bare-metal*, VM *cloud* yang mendukung virtualisasi bersarang, atau WSL 2 untuk pekerjaan lokal). Jika platform Anda tidak dapat mengekspos KVM, isolasi berbasis *microVM* tidak tersedia untuk Anda dan pendekatan *userspace* seperti gVisor atau API terhosting mungkin lebih cocok.
Vs. Firecracker. Firecracker adalah *microVM* terkenal untuk *serverless* dan merupakan blok bangunan itu sendiri, bukan produk *sandbox* agen. CubeSandbox juga berbasis KVM/RustVMM tetapi hadir lebih tinggi dalam tumpukan: *orchestrator*, *gateway* API yang kompatibel dengan E2B, dan isolasi jaringan eBPF, sehingga Anda menggunakan layanan *sandbox* agen daripada merakitnya sendiri. Jika Anda menginginkan primitif, Firecracker. Jika Anda menginginkan layanan *sandbox* dengan API yang berorientasi agen, CubeSandbox bertujuan ke arah itu.
Vs. E2B dan Sandbox Terhosting. E2B menyediakan *sandbox* terisolasi sebagai layanan terkelola; Anda memanggil API dan infrastrukturnya menjadi masalah orang lain. Pilihan desain CubeSandbox yang patut diperhatikan adalah kompatibilitas SDK E2B. Dokumentasi menggambarkannya sebagai pengganti *drop-in*: arahkan E2B_API_URL ke instans Cube yang Anda kelola sendiri dan kode yang ada tetap berfungsi. Itu membuat keputusan sebenarnya bukan lagi “*sandbox* mana” melainkan “layanan terkelola versus infrastruktur yang dikelola sendiri,” dengan residensi data, biaya pada skala, dan kepemilikan operasional sebagai faktor penentu. Ini juga secara *native* mendukung OpenAI Python SDK sesuai pengumuman Tencent.
Ringkasan jujurnya: CubeSandbox adalah entri yang kredibel dalam ruang *sandbox* agen dengan tesis yang jelas (isolasi kuat, *start* cepat, di-*host* sendiri, kompatibel dengan E2B). Ini juga baru dan sebagian besar didokumentasikan oleh vendornya, jadi *benchmark* independen masih tipis. Prototipekan terhadap beban kerja Anda dan ukur *cold start*, kepadatan, dan perilaku isolasi sebelum berkomitmen.
Bagaimana Ini Terhubung dengan Pengujian API dan Alat yang Dipanggil Agen Anda
Isolasi *runtime* menjawab “bagaimana jika kodenya buruk.” Ini tidak menjawab “bagaimana jika API yang dipanggil agen buruk, atau agen memanggilnya dengan salah.” Itu adalah masalah yang berbeda, dan Anda membutuhkan keduanya tercakup.
Bayangkan agen yang di-*sandbox* yang memesan perjalanan. Kode berjalan dengan aman di dalam CubeSandbox. Tetapi agen masih memanggil API penerbangan, API pembayaran, dan layanan *itinerary* internal. Jika salah satu di antaranya mengembalikan respons yang salah format, agen mungkin berulang, berhalusinasi pemulihan, atau meneruskan data buruk ke hilir. Jika memanggil API pembayaran dengan kunci *idempotency* yang salah, isolasi tidak akan menyelamatkan Anda; uang tetap bergerak. *Sandbox* melindungi *host* dari agen. Ini tidak melindungi sistem Anda dari agen yang bingung yang melakukan panggilan nyata ke layanan nyata.
Jadi alur kerja yang benar-benar bertahan memiliki dua lapisan yang bekerja sama:
- Mengisolasi eksekusi sehingga kode yang dihasilkan model dan pemanggilan alat tidak dapat membahayakan *host* atau mengeksfiltrasi data. Itu adalah lapisan CubeSandbox.
- Memvalidasi kontrak setiap API dan alat yang dapat dijangkau agen, sebelum dan selama eksekusi *sandboxed*. Itu adalah lapisan perkakas API.
Untuk lapisan kedua, *mock* dependensinya sehingga agen berbicara dengan pengganti terkontrol saat Anda menguji perilaku, lalu uji titik akhir nyata untuk kesesuaian skema, penanganan kesalahan, otentikasi, dan kasus-kasus ekstrem. Dengan Apidog, Anda dapat membangun *mock server* yang mengembalikan respons deterministik dan akurat secara skema, mengarahkan agen yang di-*sandbox* kepadanya, dan melihat bagaimana agen bereaksi terhadap jalur keberhasilan dan kegagalan tanpa menyentuh produksi. Setelah siap, jalankan skenario yang sama terhadap API *live* untuk mengonfirmasi kontrak berlaku. Panduan kami tentang pengujian *sandbox* mencakup praktik umum pengujian terhadap lingkungan yang terisolasi dan terkontrol, yang berlaku langsung di sini.
Penyandingan ini penting karena agen memperbesar *contract drift*. Manusia menyadari ketika respons API terlihat aneh. Agen seringkali tidak; ia menyerap respons dan bertindak berdasarkan itu. Kontrak API yang ketat, yang dilatih dengan *mock* dan pengujian, menjaga pemanggil otonom agar tidak memperparah satu respons buruk menjadi kaskade. Jika agen Anda berbicara *Model Context Protocol*, pengujian server MCP dengan Apidog memperluas disiplin yang sama ke lapisan alat. Dan jika Anda mendesain API untuk konsumen agen, mendesain API untuk agen AI mencakup pola kontrak yang membuat panggilan otonom dapat diprediksi.
Kasus Penggunaan Dunia Nyata
Beberapa pola di mana pendekatan isolasi-plus-kontrak menunjukkan nilainya:
- Agen Pengodean dan Interpreter Kode. Model menulis dan menjalankan kode untuk menjawab pertanyaan, mengubah data, atau menghasilkan grafik. Ini adalah kasus penggunaan *sandbox* kanonis dan yang ditargetkan langsung oleh API yang kompatibel dengan E2B. Kernel per-*sandbox* CubeSandbox penting di sini karena kodenya sepenuhnya arbitrer dan berubah setiap kali dijalankan.
- Platform Agen Multi-tenant. Jika agen banyak pelanggan mengeksekusi kode di infrastruktur bersama, isolasi tingkat *container* antar *tenant* berisiko. Isolasi perangkat keras per *sandbox* memberi Anda batasan *tenancy* yang tetap berlaku meskipun agen salah satu *tenant* bersifat *hostile*. Kepadatan yang dilaporkan (ribuan *sandbox* per *host*) adalah yang membuat itu layak daripada satu VM per *tenant*.
- RL Agen dan Perulangan Pelatihan. Melatih agen dengan *reinforcement learning* berarti menjalankan sejumlah besar *rollout* yang berumur pendek dan tidak tepercaya. Tencent mengutip MiniMax yang menggunakan CubeSandbox untuk hal ini di lingkungan heterogen. *Cold start* yang cepat dan *overhead* per-instans yang rendah adalah perbedaan antara eksekusi pelatihan yang layak dan yang tidak.
- Agen Riset dan Data yang Menggunakan Alat. Agen mengambil konten eksternal, menguraikannya, dan memanggil API hilir. Konten yang diambil tidak tepercaya (risiko *prompt-injection*), sehingga penguraian dan kode yang dihasilkan harus berada dalam *sandbox*, sementara API hilir harus diuji terhadap *mock* terlebih dahulu. Di sinilah penyandingan isolasi dengan pengujian kontrak API paling bermanfaat.
- Eksekusi Plugin atau Ekstensi yang Tidak Tepercaya. Jika pengguna dapat menyediakan alat atau kode yang dijalankan agen Anda, Anda mengeksekusi kode pihak ketiga yang tidak tepercaya secara definisi. Batas *microVM* per eksekusi adalah posisi yang tepat, penalaran yang sama yang digunakan platform *serverless* saat mengadopsi Firecracker.
Kesimpulan
*Sandboxing* agen berhenti menjadi pilihan saat agen mulai mengeksekusi kode dan memanggil alat tanpa tinjauan manusia. CubeSandbox adalah jawaban konkret dan terbuka untuk separuh masalah isolasi tersebut.
Poin-poin Penting:
- CubeSandbox itu nyata dan spesifik: *sandbox* sumber terbuka Apache 2.0 dari Tencent Cloud untuk agen AI, dibangun di atas RustVMM dan KVM, dengan kernel tamu per-*sandbox*.
- Model isolasi adalah intinya: kernel khusus per *sandbox* lebih kuat daripada isolasi *container* untuk kode yang dihasilkan model secara arbitrer, dengan *cold start* yang dilaporkan di bawah 100ms dan *overhead* di bawah 5MB.
- Kompatibilitas E2B menurunkan biaya peralihan: jika Anda menggunakan E2B, jalur *drop-in* yang didokumentasikan membingkai ulang pilihan sebagai terkelola versus di-*host* sendiri, bukan penulisan ulang.
- Perlakukan angka vendor sebagai titik awal: klaim kinerja dan kepadatan sebagian besar berasal dari Tencent; lakukan *benchmark* terhadap beban kerja Anda sendiri, dan periksa repositori untuk fitur mana yang sudah dikirimkan versus yang masih dalam pengembangan.
- Isolasi itu perlu tetapi tidak cukup: *sandbox* melindungi *host* Anda dari agen; ia tidak melindungi API Anda dari agen yang bingung memanggilnya.
- Pasangkan isolasi *runtime* dengan pengujian kontrak API: *mock* dan uji setiap titik akhir yang dapat dijangkau agen agar satu respons buruk tidak menjadi kaskade.
Jika agen Anda memanggil API yang Anda miliki atau bergantung padanya, siapkan lapisan kontrak di samping lapisan isolasi. Unduh Apidog untuk mem-*mock* layanan yang diakses agen *sandboxed* Anda dan mengujinya untuk skema, otentikasi, dan perilaku kesalahan sebelum sistem otonom menggerakkannya dalam produksi.