Lingkungan uji eksekusi untuk agen AI: arsitektur, risiko, dan pola dunia nyata.

Beranda » Ular sanca » Lingkungan uji eksekusi untuk agen AI: arsitektur, risiko, dan pola dunia nyata.

Dengan membiarkan agen AI menjalankan kode, mengakses file, membuka browser, dan mengakses API, mereka berubah dari sekadar fitur pelengkapan otomatis yang canggih menjadi sesuatu yang jauh lebih mirip dengan seorang insinyur junior yang memiliki akses root pada suatu mesin. Kekuatan ekstra itulah yang membuat mereka terasa ajaib – dan juga mengapa mereka bisa berbahaya. Agen yang tidak selaras atau sekadar bermasalah dapat menghapus basis data, membocorkan kunci API ke internet, atau menyebarkan build yang rusak ke lingkungan produksi tanpa benar-benar "memahami" apa yang salah.

Pertanyaan sebenarnya bukan lagi “seberapa akurat model tersebut?” tetapi “apa yang dapat dicapai model tersebut ketika salah, tertipu, atau terlalu percaya diri?”. Lingkungan eksekusi terisolasi (sandbox) untuk agen adalah solusi rekayasa: lingkungan yang ruang lingkupnya sangat terbatas di mana agen dapat membaca dan menulis kode, menjalankan shell, meluncurkan server, atau membuka browser, sementara Anda mengontrol secara ketat sistem file, jaringan, kredensial, dan siklus hidup. Alih-alih mempercayai modelnya, Anda membatasi radius dampaknya.

Mengapa agen pengkodean membutuhkan lingkungan eksekusi khusus?

Agen pengkodean modern seperti Claude Code, LangChain Deep Agents, sandbox pengkodean Docker, dan alat serupa lainnya tidak lagi berperilaku seperti chatbot sederhana dengan akses file. Mereka membaca seluruh repositori, mengedit file, menjalankan perintah shell, memanipulasi Git, memulai build Docker, berkomunikasi dengan API eksternal, dan bahkan mengoperasikan lingkungan mirip desktop lengkap melalui browser. Dokumentasi vendor sangat eksplisit tentang hal ini: Claude Code disajikan sebagai asisten pengembangan tangkas yang dapat memeriksa basis kode Anda, melakukan pengeditan, dan menjalankan perintah; LangChain Deep Agents memperlakukan backend sandbox sebagai tempat mereka mengeksekusi perintah shell, mengelola sistem file, dan mendelegasikan pekerjaan ke sub-agen untuk isolasi.

Kumpulan kemampuan inilah yang membuat agen-agen ini berguna – dan sekaligus berisiko secara operasional. Setelah model dapat dijalankan pytestUntuk menginstal paket npm, membuka branch, atau men-debug kegagalan build, hanya dengan beberapa panggilan alat saja sudah bisa dilakukan modifikasi skrip deployment, push image yang rusak, mengubah konfigurasi CI, atau mengeksfiltrasi token melalui permintaan HTTP. Panduan keamanan agen dari OpenAI sendiri dan pekerjaan NIST tentang pembajakan agen sama-sama menekankan injeksi prompt: instruksi berbahaya yang tersembunyi dalam file, halaman web, atau log dapat secara diam-diam mengarahkan agen ke tindakan yang tidak pernah Anda izinkan.

Banyak tim memulai dengan alur "meminta persetujuan" yang sederhana untuk setiap perintah, dan dengan cepat menyadari bahwa alur tersebut tidak dapat diterapkan dalam skala besar. Anthropic telah secara terbuka menyatakan bahwa pengguna menyetujui 93% dari permintaan izin Claude Code; sandbox Claude milik Docker bahkan meluncurkan Claude Code dengan --skip-permissions Secara default, lebih mengutamakan isolasi saat runtime daripada banyaknya dialog. Orang-orang akan mengalami kelelahan persetujuan, terutama saat menjalankan banyak agen secara paralel dan beralih konteks di antara banyak perintah. Pada titik itu, dialog konfirmasi menjadi sekadar formalitas, bukan kontrol yang andal.

Lingkungan sandbox eksekusi menggeser model keamanan dari "percaya pada pengguna untuk membaca setiap perintah" menjadi "menganggap beberapa perintah akan salah atau bersifat antagonis, dan membatasi kerusakan yang dapat ditimbulkannya". Lingkungan sandbox menjadi batasan ketat mengenai file, proses, jaringan, dan rahasia apa yang dapat diakses oleh agen, bahkan ketika agen tersebut dimanipulasi melalui injeksi perintah atau sekadar membuat kesalahan.

Ada juga argumen dasar dari sudut pandang pengalaman pengembang: agen membutuhkan ruang yang cukup untuk benar-benar bekerja. Jika Anda terlalu membatasi ruang lingkup pengujian (sandbox), perintah sederhana seperti pembuatan atau pengujian akan terus-menerus gagal karena kesalahan izin yang tidak jelas. Sistem terbaik, seperti yang diterapkan oleh Cursor di macOS/Linux/Windows atau oleh Cloudflare, Heroku, dan Google Cloud untuk beban kerja yang dihosting, bertujuan untuk memberikan agen nuansa "komputer sungguhan" di dalam perimeter yang ketat.

Apa yang sebenarnya diisolasi oleh lingkungan uji eksekusi untuk agen?

Lingkungan sandbox agen yang tepat bukanlah sekadar "tempat lain untuk menjalankan kode" – melainkan sekumpulan batasan eksplisit yang menentukan radius dampaknya. Anda dapat memikirkan lima batasan utama yang muncul berulang kali di platform terkemuka seperti Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B, atau Daytona.

Pertama, batasan sistem file: agen hanya boleh melihat ruang kerja yang Anda bagikan secara sengaja. Dokumentasi LangChain menggambarkan sandbox sebagai penghalang yang menjauhkan agen dari file host; model sandbox Docker sangat jelas menyatakan bahwa microVM hanya melihat direktori proyek yang dipasang secara eksplisit. Apa pun di luar pohon tersebut tidak terlihat atau hanya dapat dibaca, sehingga agen tidak dapat dengan mudah membaca file host. ~/.ssh atau menulis ulang konfigurasi sistem.

Kedua, batasan proses dan kernel: beban kerja agen tidak boleh berbagi kernel host mentah atau tabel proses. Arsitektur sandbox Docker mengisolasi setiap lingkungan di lingkungannya masing-masing. microVM dan kernel LinuxFirecracker (yang digunakan secara tersembunyi oleh beberapa penyedia) memperlakukan batas VM tersebut sebagai lapisan isolasi pertama, kemudian menambahkan seccomp, namespace, cgroup, dan pembatasan seperti penjara di atasnya. GKE Agent Sandbox milik Google mencapai efek serupa di dalam Kubernetes menggunakan gVisor: lapisan "penjaga" mencegat panggilan sistem dan memediasi akses ke node yang mendasarinya.

Ketiga, batasan jaringan: tanpa kebijakan jaringan, agen yang diisolasi (sandboxed) tetaplah mesin penguras data. Sebagian besar platform serius sekarang mengirimkan produk dengan fitur "tolak semua lalu lintas keluar" secara default. Docker Sandbox, misalnya, memblokir HTTP/HTTPS hingga diizinkan secara eksplisit, memutus TCP/UDP/ICMP mentah, dan melarang lalu lintas ke rentang IP pribadi dan localhost kecuali Anda mengkonfigurasi pengecualian. Cloudflare, Google, dan lainnya mendesain sandbox mereka sehingga panggilan keluar melewati proxy yang dapat diprogram di mana Anda dapat menyuntikkan otentikasi, memfilter tujuan, dan mengaudit penggunaan.

Keempat, batasan kredensial: pengungkapan rahasia mentah di dalam sandbox harus dianggap sebagai upaya terakhir, bukan sebagai pilihan utama. Desain Docker mengarahkan panggilan HTTP melalui proxy sisi host yang dapat melampirkan token atau kunci API ke permintaan tanpa pernah menempatkan nilai mentah tersebut di dalam VM. Cloudflare Sandboxes juga menyuntikkan kredensial pada lapisan jaringan, bukan melalui variabel lingkungan. Dengan begitu, meskipun injeksi yang dilakukan secara langsung meyakinkan agen untuk "mencetak semua variabel lingkungan", tidak ada informasi berharga yang dapat dicuri.

Kelima, batasan siklus hidup: ruang kerja agen jarang hanya ada untuk satu perintah; mereka membutuhkan semantik eksplisit untuk memulai, menjeda, mengambil snapshot, membuat salinan (fork), dan menghentikan (teardown). E2B mengekspos sistem file terisolasi, perintah latar belakang, dan volume yang dapat bertahan lebih lama dari masa pakai sandbox tunggal. Freestyle berfokus pada pengaktifan, penangguhan, dan pengaktifan kembali VM yang sangat cepat dengan pembuatan snapshot dan percabangan status dalam memori. Daytona menambahkan sandbox berbasis snapshot plus kebijakan penghentian otomatis, pengarsipan otomatis, dan penghapusan otomatis sehingga Anda dapat menjaga beberapa lingkungan tetap berumur panjang dan memperlakukan lingkungan lain sebagai lingkungan sekali pakai.

Setelah Anda melihat kelima sumbu ini – sistem file, proses, jaringan, kredensial, dan siklus hidup – Anda dapat membaca halaman produk sandbox apa pun sebagai serangkaian pertimbangan untung rugi. Kontainer kernel bersama dengan host mount yang besar tetapi aturan egress yang ketat sangat berbeda dari microVM tanpa host mount tetapi jaringan yang lebih permisif. Bagi agen pengkodean yang perlu menginstal dependensi, menjalankan browser, atau membuat image Docker, batasan gaya VM yang lebih kuat cenderung menjadi pilihan default yang lebih aman.

Penggunaan sandbox pada macOS, Linux, dan Windows untuk agen pengkodean lokal.

Pada laptop pengembang, Anda tidak selalu dapat menjalankan sandbox microVM yang berat, sehingga tim harus berinovasi dengan isolasi bawaan sistem operasi. Pengembangan Cursor baru-baru ini pada sandbox lokal adalah contoh yang baik dari penyesuaian terhadap kekhususan macOS, Linux, dan Windows sambil mempertahankan API terpadu untuk lapisan agen.

Di macOS, beberapa opsi dievaluasi: App Sandbox, kontainer generik, VM penuh, dan teknologi yang sudah lama ada tetapi "usang" yang disebut Seatbelt. App Sandbox akan mengharuskan penandatanganan setiap biner yang mungkin dieksekusi oleh agen, yang secara dramatis meningkatkan kompleksitas dan bahkan memberikan kepercayaan transisi pada biner yang dihasilkan. Kontainer Linux akan memaksa pengguna macOS untuk menggunakan biner khusus Linux, dan VM lengkap memiliki latensi boot dan overhead memori yang tidak dapat diterima untuk alur pengkodean interaktif.

Sabuk pengaman, diakses melalui sandbox-exec, pada akhirnya menjadi pilihan pragmatis meskipun usianya sudah tua. Fitur ini memungkinkan Anda menjalankan perintah di bawah profil sandbox yang membatasi seluruh pohon proses dengan bahasa kebijakan yang terperinci: Anda dapat memasukkan atau memblokir syscall tertentu dan membatasi izin baca/tulis ke file atau direktori yang ditargetkan. Cursor menghasilkan kebijakan ini secara dinamis saat runtime berdasarkan pengaturan ruang kerja dan admin ditambah pengguna. .cursorignore, sehingga jalur yang diabaikan menjadi terlarang di dalam sandbox.

Pada Linux, kernel mengekspos primitif yang tepat – seccomp untuk penyaringan syscall dan Landlock untuk pembatasan sistem file – tetapi menyerahkan komposisi ke ruang pengguna. Daripada bergantung pada wrapper OSS yang sudah ada yang tidak mendukung pengabaian khusus repositori seperti .cursorignoreCursor memilih untuk mengatur Landlock dan seccomp secara langsung. Seccomp melarang panggilan sistem yang berbahaya; Landlock memberlakukan aturan baca/tulis berbasis jalur, bahkan membiarkannya menimpa ruang kerja pengguna sehingga file yang diabaikan sepenuhnya tidak dapat diakses atau diganti dengan salinan yang dilindungi yang tidak dapat dibaca atau dimodifikasi oleh proses yang diisolasi.

Salah satu hal yang perlu diperhatikan pada Linux adalah performa: memasang ulang atau menulis ulang semua file yang diabaikan adalah bagian paling lambat dari pengaturan sandbox. Penyaringan tunda ala macOS yang dapat melihat jalur file persis pada saat syscall akan menyederhanakan hal ini, tetapi seccomp-bpf Linux tidak mempermudah inspeksi jalur tersebut, sehingga ada pertimbangan teknis yang nyata antara isolasi yang ketat dan kecepatan startup.

Di Windows, membangun sandbox asli yang benar-benar setara tetap lebih sulit karena sebagian besar primitif isolasi dioptimalkan untuk browser dan bukan untuk alat pengembangan tujuan umum. Saat ini Cursor menjalankan sandbox Linux di dalam WSL2 untuk pengguna Windows, pada dasarnya memanfaatkan isolasi Linux sampai tersedia fitur yang lebih canggih. Mereka bekerja sama dengan Microsoft untuk mengekspos kemampuan yang tepat sehingga, seiring waktu, agen Windows dapat menikmati sandboxing asli kelas satu tanpa WSL sebagai penopang.

Kesamaan di antara pendekatan-pendekatan khusus sistem operasi ini adalah API sandbox terpadu di atasnya. Dari sudut pandang agen, ini hanyalah "alat antarmuka" dengan kemampuan dan aturan yang jelas. Di balik layar, isolasi berbasis Seatbelt, Landlock/seccomp, atau WSL2 menerapkan aturan tersebut secara berbeda untuk setiap platform.

Mengajari agen untuk memahami dan menghormati lingkungan sandbox.

Lingkungan uji (sandbox) hanya bermanfaat jika agen dapat mengantisipasi apa yang akan berhasil di dalamnya dan kapan perlu meningkatkan hak akses atau keluar dari lingkungan tersebut. Kedengarannya memang sudah jelas, tetapi dalam praktiknya hal itu membutuhkan iterasi desain prompt dan alat yang cukup mendalam bagi vendor yang mengirimkan agen pengkodean.

Langkah pertama yang diambil banyak tim adalah memperbaiki deskripsi alat, terutama untuk eksekusi shell. Alih-alih alat "jalankan_perintah_shell" generik, deskripsi tersebut secara eksplisit menyatakan sumber daya apa yang dapat diakses: apakah perintah tersebut memiliki akses sistem file, akses Git, akses jaringan, atau lingkungan yang sepenuhnya offline tergantung pada konfigurasi pengguna. Deskripsi tersebut juga mendokumentasikan bagaimana agen dapat meminta hak akses yang lebih tinggi (misalnya, untuk mengakses internet publik) bila diperlukan. Pekerjaan rekayasa cepat ini cenderung sangat empiris: tim menjalankan alur penerapan umum, mengamati di mana model salah memprediksi kemampuan, menyesuaikan deskripsi alat, dan mengulanginya.

Kemudian, tolok ukur internal seperti “Cursor Bench” atau rangkaian evaluasi serupa digunakan untuk membandingkan kinerja agen dengan dan tanpa sandboxing. Salah satu mode kegagalan awal yang sangat konsisten adalah: agen akan secara membabi buta mencoba kembali perintah terminal yang sama yang gagal berulang kali, alih-alih menyadari bahwa ia menemui batasan sandbox. Tanpa sinyal yang jelas tentang mengapa perintah tersebut gagal, model tidak dapat mempelajari polanya.

Solusinya adalah menampilkan kesalahan sandbox secara eksplisit dalam output alat, seringkali disertai petunjuk tentang apa yang harus dilakukan selanjutnya. Ketika sebuah perintah diblokir karena aturan sistem file atau jaringan, alat shell mulai menyertakan penjelasan singkat seperti "diblokir oleh sandbox: akses jaringan keluar dinonaktifkan untuk sesi ini" dan, dalam beberapa kasus, petunjuk bahwa agen dapat meminta hak akses yang lebih tinggi. Setelah perubahan ini, agen menjadi jauh lebih tangguh: mereka berhenti mengulang perintah yang tidak ada harapan dan menyesuaikan rencana mereka atau meminta kemampuan yang dibutuhkan.

Evaluasi offline memang bermanfaat, tetapi hanya memberikan sebagian gambaran saja. Untuk benar-benar mengetahui apakah sandboxing menurunkan pengalaman pengguna, tim telah meluncurkan dukungan sandbox secara bertahap di lingkungan produksi dan mengamati tingkat kesalahan, waktu penyelesaian, dan saluran umpan balik. Dalam praktiknya, vendor melaporkan bahwa sebagian besar kueri pada platform yang kompatibel sekarang berjalan sepenuhnya di dalam sandbox – dengan pelanggan perusahaan seperti NVIDIA termasuk di antara pengguna awal – dan bahwa agen yang di-sandbox sebenarnya berhenti untuk persetujuan sekitar 40% lebih jarang dalam alur kerja nyata, menghemat waktu berjam-jam peninjauan manual sekaligus mengurangi risiko.

Ke depan, ada banyak minat pada "agen sandbox asli" – model yang dilatih langsung berdasarkan batasan lingkungannya. Alih-alih memperlakukan shell, browser, atau sistem file sebagai alat abstrak, agen-agen ini akan memahami bahwa mereka hidup dalam lingkungan runtime yang terbatas, dapat menulis skrip dan program yang berumur panjang, dan harus menghormati kondisi batas seperti "tidak ada jaringan keluar" atau "ruang kerja hanya dapat dibaca". Pelatihan tersebut dapat membuat mereka jauh lebih baik dalam merencanakan rangkaian tindakan yang aman dan efisien tanpa harus berbenturan dengan batasan yang tidak terlihat.

Layanan sandbox cloud: Cloudflare, Google Cloud, Heroku, dan lainnya.

Di luar laptop pengembang, gelombang besar penyedia infrastruktur berlomba-lomba menawarkan sandbox yang dihosting dan disesuaikan secara khusus untuk agen AI. Tujuan mereka sama – isolasi, kontrol, dan kinerja – tetapi pertimbangan untung ruginya terlihat sedikit berbeda pada skala cloud.

Cloudflare Sandboxes, yang dibangun di atas Cloudflare Containers dan kini tersedia secara umum, bertujuan untuk terlihat dan terasa seperti lingkungan pengembangan lengkap untuk agen. Setiap sandbox adalah ruang kerja terisolasi dan persisten yang dapat Anda akses berdasarkan namanya. Jika sedang tidur, ia akan aktif sesuai permintaan; jika sedang tidak aktif, ia akan secara otomatis ditangguhkan untuk menghemat daya komputasi dan dilanjutkan pada permintaan berikutnya. Pengembang (atau agen) dapat berinteraksi dengannya melalui metode bertipe seperti exec, gitCheckout, writeFile, dan masih banyak lagi, menggunakan SDK JavaScript/TypeScript.

Salah satu masalah cloud yang paling rumit adalah otentikasi yang aman dari dalam sandbox agen. Agen sering kali perlu mengakses layanan privat, tetapi Anda tidak ingin kredensial mentah tersimpan begitu saja di variabel lingkungan. Cloudflare menyuntikkan kredensial pada lapisan proksi jaringan, memetakan permintaan keluar berdasarkan host ke logika khusus yang melampirkan token dari penyimpanan yang aman. Proses sandbox tidak pernah melihat rahasia sebenarnya, tetapi panggilan tetap diautentikasi. Desain ini mendukung injeksi kredensial dinamis yang sadar identitas dan bekerja dengan baik dengan binding Workers.

Untuk alur kerja yang banyak menggunakan terminal, Cloudflare menambahkan pengalaman PTY (pseudo-terminal) lengkap yang terhubung melalui WebSocket dan xterm.js. Agen dan manusia dapat membuka sesi shell langsung, menginterupsi proses, menyambungkan kembali nanti, dan memutar ulang output sebelumnya. Setiap PTY memiliki direktori kerja dan lingkungannya sendiri, dan output di-buffer di server sehingga klien yang menyambungkan kembali dapat mengejar log yang terlewat.

Selain akses shell mentah, Cloudflare juga menawarkan "konteks eksekusi kode" yang persisten untuk bahasa seperti Python, JavaScript, dan TypeScript. Berbeda dengan banyak snippet runner yang mengeksekusi setiap fragmen secara terpisah, konteks ini mempertahankan variabel, impor, dan status di seluruh panggilan, mirip dengan notebook Jupyter. Agen dapat memuat data dalam satu panggilan, mengubahnya dalam panggilan lain, dan merender grafik atau tabel HTML tanpa harus terus-menerus mengurai dan mengimpor ulang semuanya.

Untuk tugas pengembangan web, sandbox Cloudflare mendukung proses latar belakang, pemeriksaan kesehatan, dan URL pratinjau langsung. Seorang agen dapat memulai npm run dev Sebagai pekerjaan latar belakang, pantau log hingga server siap, lalu buka port di balik URL pratinjau publik. Metode seperti waitForPort() or waitForLog() biarkan agen mengatur urutan tindakan berdasarkan sinyal kesiapan nyata, bukan berdasarkan asumsi yang naif. sleep(2s) tebakan.

Alur kerja berbasis peristiwa mendapatkan dorongan dari primitif pemantauan file yang didukung oleh mekanisme inotify Linux. Agen dapat berlangganan perubahan di bawah /workspace/src dan secara otomatis menjalankan ulang pengujian atau build ketika file TypeScript dimodifikasi. Ini adalah siklus umpan balik yang sama yang diandalkan oleh pengembang manusia, tetapi dibuat secara native oleh agen melalui API seperti sandbox.watch() dan aliran peristiwa yang dikirim server.

Untuk melengkapi siklus hidup, Cloudflare meluncurkan snapshot sejati – pengambilan status tingkat VM yang dapat dipulihkan dalam hitungan detik dari penyimpanan R2. Snapshot menyimpan status sistem file, konfigurasi OS, dependensi yang terinstal, dan file data; versi mendatang juga akan memulihkan status memori aktif untuk melanjutkan secara instan. Agen (atau orchestrator) dapat memicu snapshot secara terprogram untuk titik pemeriksaan atau skenario penyebaran, kemudian membuat beberapa sandbox dari snapshot yang sama untuk mengeksplorasi hipotesis paralel secara terisolasi.

Dari segi harga, Cloudflare beralih ke model "CPU aktif saja": Anda ditagih berdasarkan siklus CPU yang benar-benar digunakan, bukan waktu idle saat agen menunggu LLM. Dikombinasikan dengan batasan konkurensi yang besar untuk instance "lite" dan yang lebih besar, hal ini memungkinkan untuk menjalankan sejumlah besar agen tanpa membuang uang untuk kontainer yang tidak aktif.

Sebaliknya, GKE Agent Sandbox dari Google Cloud terintegrasi secara mendalam dengan Kubernetes dan gVisor. Idenya adalah untuk memungkinkan Anda menjalankan beban kerja agen dalam pod terisolasi di dalam kluster Anda sendiri. Anda membuat kluster GKE (Autopilot dapat mengaktifkan gVisor secara otomatis, sementara kluster Standar memerlukan kelas runtime eksplisit dan kumpulan node yang diaktifkan gVisor), kemudian menyebarkan pengontrol Agent Sandbox melalui manifest versi.

Dua sumber daya kustom inti mendorong model ini: SandboxTemplate ke SandboxWarmPool. SandboxTemplate berfungsi sebagai cetak biru yang dapat digunakan kembali yang menentukan templat pod (citra, port, sumber daya, runtimeClassName: gvisor, dll.) untuk lingkungan eksekusi terisolasi (sandbox), seperti lingkungan Python. SandboxWarmPool Mempertahankan sejumlah pod yang telah dihangatkan sebelumnya agar siap digunakan hampir seketika, menghindari cold start ketika agen membutuhkan lingkungan baru dalam waktu kurang dari satu detik.

A Sandbox Router Layanan tersebut kemudian bertindak sebagai gerbang untuk lalu lintas antara klien dan pod terisolasi ini. Dalam tahap pengembangan, Anda dapat mengarahkan lalu lintas melalui terowongan. kubectl port-forward tanpa mengekspos IP publik. Dalam produksi, Anda biasanya akan menggunakan router dengan ingress dan mTLS yang tepat. Di sisi klien, Google menyediakan pustaka Python "Agentic Sandbox" yang membungkus seluruh siklus hidup: membuat klaim sandbox dari templat, menunggu hingga siap, menjalankan perintah shell, dan membersihkan setelah selesai.

Semua ini pada dasarnya masih "Kubernetes", tetapi dikemas menjadi sebuah narasi yang koheren untuk runtime agen. gVisor memberikan isolasi proses dan syscall, SandboxTemplate menstandarisasi konfigurasi, WarmPool mengatasi latensi startup, dan router plus klien Python membuatnya nyaman untuk aplikasi yang berpusat pada LLM.

Di sisi lain, Heroku bertumpu pada fondasi yang sangat matang: dyno sekali pakai. Selama bertahun-tahun, pengguna Heroku telah menjalankan pekerjaan ad hoc – migrasi, skrip pemeliharaan, tugas admin – di dyno sementara yang dibuat sesuai permintaan dan mati setelah selesai. Heroku menggunakan kembali infrastruktur ini sebagai sandbox eksekusi kode, yang diluncurkan bersamaan dengan penawaran Managed Inference dan Agents mereka. Sebuah agen menulis cuplikan kode Python, Ruby, Node, atau Go; Heroku mengeksekusinya di dalam dyno berumur pendek dan mengalirkan hasilnya kembali, membatasi dampak pada kontainer sementara tersebut.

Anda dapat mengakses sandbox ini baik melalui alat bawaan di API Agen Heroku atau dengan menerapkan server Model Context Protocol (MCP) sumber terbuka. Server MCP mengekspos titik akhir alat yang terstandarisasi, sehingga klien seperti Agentforce, Claude Desktop, atau Cursor dapat memperlakukan sandbox Heroku sebagai backend eksekusi kode jarak jauh yang generik. Setiap server mendukung batasan khusus runtime (seperti max_calls per siklus agen) untuk mencegah agen berputar dalam siklus yang ketat dan mahal.

Deep Agents dari LangChain menambahkan dimensi lain dengan berintegrasi dengan penyedia sandbox pihak ketiga seperti Runloop, Daytona, dan Modal. Polanya sederhana: Deep Agent terus berjalan di mana pun Anda inginkan (lokal atau cloud), tetapi setiap kali perlu menjalankan perintah, membuat file, atau mengeksekusi kode, operasi tersebut diteruskan ke sandbox jarak jauh. Skrip pengaturan dapat memuat variabel lingkungan terlebih dahulu, mengklon repositori, menginstal alat, dan banyak lagi, sehingga setiap agen mendapatkan lingkungan yang bersih dan terkontrol. Manajer konteks kemudian menangani pembuatan dan pembersihan, meskipun dokumentasi sangat menyarankan untuk memantau dasbor penyedia untuk setiap sandbox yang berjalan lama dan terlupakan.

Performa, status, dan percabangan: mengapa kecepatan penting bagi agen

Sandbox yang lambat namun sangat aman akan tetap bisa ditembus dalam praktiknya; keberhasilan atau kegagalan alat pengembang bergantung pada latensi. Agen pengkodean tidak berperilaku seperti pekerjaan batch harian. Mereka menjalankan siklus interaktif: membaca beberapa kode, mengusulkan pengeditan, menjalankan pengujian, menganalisis log, memanggil alat, menunggu manusia, lalu mengulanginya. Dalam sesi nyata, mereka juga menjelajahi berbagai cabang masalah, meninggalkan beberapa jalur dan kembali ke jalur lain nanti.

Inilah mengapa platform seperti Freestyle sangat memperhatikan waktu siklus hidup VM di bawah satu detik dan semantik status yang kaya. VM mereka adalah mesin Linux lengkap dengan akses root, layanan systemd, dukungan virtualisasi bertingkat, dan jaringan penuh. Dokumentasi mengklaim penyediaan dalam waktu kurang dari 800 ms dari panggilan API hingga VM berjalan, penangguhan/pengaktifan kembali dalam waktu kurang dari 100 ms, dan kemampuan untuk mengambil snapshot atau membuat salinan VM di tengah eksekusi dengan dampak kinerja minimal. Mereka secara eksplisit menyebutkan status browser sebagai penerima manfaat: jika agen telah mengarahkan browser ke status yang menarik, agen tersebut dapat membuat salinan VM tersebut 20 kali dari snapshot yang sama daripada membuat ulang status tersebut dari awal.

SandboxWarmPool milik Google untuk GKE mengekspresikan ide yang sama dalam istilah Kubernetes: menyimpan kumpulan pod yang sudah di-pre-warm sehingga agen tidak menanggung penalti cold-start penuh untuk setiap eksekusi baru. Ruang kerja berbasis snapshot Daytona ditambah kebijakan penghentian/pengarsipan/penghapusan otomatis menyesuaikan siklus hidup untuk berbagai jenis sesi: lingkungan pengembangan aktif, eksperimen sementara, dan baseline jangka panjang.

Penekanan E2B pada pekerjaan latar belakang, direktori yang dapat dipantau, sistem file terisolasi, dan volume yang dapat digunakan kembali adalah sisi lain dari koin yang sama. Fitur-fitur ini memungkinkan agen untuk tetap menjalankan server pengembangan atau sistem pengujian sambil mengeksplorasi perubahan kode, atau berbagi volume persisten di beberapa lingkungan pengujian sementara dari waktu ke waktu. Tanpa ini, agen akhirnya hanya menjalankan perintah satu kali dan kehilangan konteks, yang akan mengurangi produktivitas.

Salah satu cara yang berguna untuk mengevaluasi lingkungan uji coba (sandbox) untuk pekerjaan agen adalah dengan mengajukan beberapa pertanyaan lugas. Bisakah saya membuat lingkungan baru dalam waktu kurang dari satu detik? Bisakah saya menyimpan dan memulihkan status dengan bersih, termasuk build parsial atau sesi browser? Bisakah saya membuat salinan status untuk eksplorasi paralel? Bisakah saya menyimpan ruang kerja yang berumur panjang namun efisien sumber daya untuk alur "kembali lagi nanti"? Semakin banyak jawaban "ya" yang Anda dapatkan, semakin agen Anda dapat berperilaku seperti insinyur sungguhan, bukan sekadar pelaksana skrip tanpa status.

Rahasia, kebijakan jaringan, dan kepercayaan ruang kerja sebagai bidang kendali yang sebenarnya.

Bahkan dengan isolasi host yang sempurna, mudah untuk membangun sistem yang tidak aman jika Anda mengabaikan rahasia, kebijakan jaringan, dan kepercayaan ruang kerja. Dokumentasi sandbox Docker sangat jujur ​​dalam hal ini. microVM dan daemon Docker pribadinya membentuk batas kepercayaan utama dengan host. Namun, di dalam VM tersebut, agen memiliki kendali penuh tingkat root, dan ruang kerja bersama dipasang dengan hak baca-tulis. Secara default, setiap pengeditan file akan langsung tercermin pada host. Akses keluar jaringan ditolak secara default dan hanya diizinkan melalui aturan eksplisit, dan permintaan HTTP menggunakan proxy sisi host yang dapat menyuntikkan kredensial tanpa mengekspos rahasia mentah ke VM.

Artinya, mengisolasi host hanyalah langkah pertama; Anda masih harus memikirkan apa yang dapat dilakukan agen terhadap ruang kerja dan dunia luar. Dokumentasi Docker secara eksplisit memperingatkan bahwa jika agen mengedit skrip yang nantinya akan dieksekusi oleh manusia – Git hooks, konfigurasi CI, definisi tugas IDE, Makefile target, package.json skrip – kerusakan dapat "melompat" kembali ke host atau sistem CI ketika skrip tersebut dijalankan. Mereka bahkan menyoroti bahwa Git hooks di .git/ jangan muncul di git diff, sehingga memudahkan keberlangsungan logika jahat secara diam-diam.

Penggunaan proksi kredensial sangat ampuh namun membutuhkan ketelitian. Proxy keluar Docker memastikan rahasia tetap berada di luar VM, tetapi tetap memungkinkan agen untuk bertindak menggunakan identitas tersebut terhadap host yang diizinkan. Beberapa alur – seperti menulis variabel lingkungan khusus ke dalam file seperti /etc/sandbox-persistent.sh – langgar batasan ini dengan sengaja menyimpan rahasia di dalam VM, yang hanya aman jika Anda benar-benar mempercayai agen dan sandbox tersebut.

Cakupan konfigurasi sama pentingnya dengan rahasia. FAQ Docker mencatat bahwa konfigurasi tingkat pengguna seperti ~/.claude or ~/.codex Konfigurasi pada host tidak disalin ke dalam sandbox; hanya konfigurasi lingkup proyek di ruang kerja bersama yang terlihat. Dokumentasi konfigurasi Anthropic menegaskan bahwa pengaturan tingkat proyek – alat, izin, server MCP, hook – menimpa pengaturan tingkat pengguna dan dibagikan di seluruh tim. Dengan kata lain, kebijakan, instruksi, dan plugin apa pun yang Anda lampirkan ke repositori menjadi area permukaan utama yang dilihat agen.

Panduan Skills dari OpenAI menekankan poin-poin serupa dengan kosakata yang sedikit berbeda. Skill (paket alat) dapat menimbulkan risiko eksfiltrasi data yang didorong oleh injeksi perintah. Dokumen tersebut memperingatkan agar tidak mengekspos pasar Skill publik yang tidak terkurasi langsung kepada pengguna akhir, karena file SKILL.md yang berbahaya dapat mengesampingkan kebijakan, memicu tindakan destruktif, atau membocorkan data pribadi. Mereka merekomendasikan untuk memeriksa Skill pengembang, membatasinya pada alur kerja tertentu, menyembunyikan tindakan berdampak tinggi di balik persetujuan tambahan dan pemeriksaan kebijakan, dan memperlakukan Skill sebagai bagian dari model ancaman Anda.

Jika Anda menggabungkan semua bagiannya, bidang kendali "sebenarnya" untuk sandbox agen mencakup empat lapisan. Isolasi host melindungi mesin dan node kluster Anda. Kepercayaan ruang kerja melindungi manusia atau CI di masa mendatang yang akan menjalankan file yang dihasilkan di dalam sandbox. Kebijakan jaringan melindungi sistem eksternal dan sumber data pribadi. Manajemen kredensial melindungi identitas yang digunakan agen untuk bertindak. Desain yang kuat memiliki solusi untuk keempat hal tersebut, bukan hanya yang pertama.

Selain itu, Anda tetap perlu bersikap skeptis terhadap injeksi cepat dan pembajakan agen. NIST, OWASP, dan OpenAI semuanya menjelaskan varian dari pola yang sama: input yang tidak tepercaya – file README, halaman web, file log – menyematkan instruksi berbahaya yang mengalihkan perilaku agen. Generasi yang diperkaya dengan pengambilan data dan penyempurnaan tidak secara ajaib menyelesaikan masalah ini. Sandbox yang dilengkapi dengan baik ditambah kebijakan yang baik tidak dapat mencegah model tertipu, tetapi dapat secara dramatis mengurangi kerugian ketika hal itu terjadi.

Platform cloud dan runtime agen mulai mengimplementasikan pelajaran-pelajaran ini. Proxy rahasia, domain keluar yang diizinkan, konfigurasi lingkup repositori, subagen dengan kemampuan lebih terbatas, alur persetujuan berbasis hook, dan sandbox yang dapat direproduksi semuanya merupakan bagian dari teka-teki yang sama: terima bahwa model dapat salah, dan rancang lingkungan sehingga biaya kesalahan tersebut tetap terbatas.

Baik dalam pengaturan lokal maupun cloud, sandbox eksekusi untuk agen paling baik dipahami sebagai garis yang ditarik dengan hati-hati: ini tidak membuat model lebih pintar, tetapi membuat kesalahannya tidak terlalu fatal dan lebih mudah diamati. Dengan perpaduan yang tepat antara kontrol sistem file, proses, jaringan, rahasia, dan siklus hidup, ditambah pengajaran cerdas kepada agen tentang lingkungannya, Anda dapat membiarkan sistem AI mengklon repositori, menjalankan pengujian, meluncurkan peramban, dan bahkan mengakses sistem yang menyerupai lingkungan produksi – tanpa menyerahkan kunci akses ke semua hal yang Anda pedulikan.

Ini berarti mengisolasi host hanyalah langkah pertama; Anda masih harus memikirkan apa yang dapat dilakukan agen terhadap ruang kerja dan dunia luar, termasuk risiko seperti... eksekusi kode jarak jauh. Dokumentasi Docker secara eksplisit memperingatkan bahwa jika agen mengedit skrip yang nantinya akan dieksekusi oleh manusia – Git hooks, konfigurasi CI, definisi tugas IDE, Makefile target, package.json skrip – kerusakan dapat "melompat" kembali ke host atau sistem CI ketika skrip tersebut dijalankan.