AI Agent semakin banyak digunakan untuk mengerjakan tugas yang sebelumnya membutuhkan interaksi langsung dari developer. Agent tidak hanya menghasilkan jawaban berbentuk teks, tetapi juga dapat menulis program, menjalankan Python, mengolah dataset, memanggil command-line tool, menginstal package, membaca file, hingga menjalankan aplikasi secara otomatis.
Kemampuan tersebut membuat AI Agent jauh lebih berguna. Namun, ada konsekuensi keamanan yang tidak boleh diabaikan. Kode yang dihasilkan AI belum tentu aman untuk langsung dijalankan pada sistem utama. Sebuah agent dapat menghasilkan kode yang salah, mengakses file yang seharusnya tidak boleh dibaca, menggunakan resource secara berlebihan, atau menjalankan perintah yang tidak sesuai dengan tujuan awal.
Di sinilah konsep sandbox menjadi penting.
Sandbox adalah lingkungan terisolasi yang digunakan untuk menjalankan kode tanpa memberikan akses penuh kepada program tersebut terhadap sistem utama. Bergantung pada teknologinya, isolasi dapat dilakukan melalui container, namespace Linux, microVM, virtualisasi hardware, application kernel, maupun WebAssembly.
Dalam konteks AI Agent, sandbox berfungsi sebagai lapisan pembatas antara agent dan host system. Agent tetap bisa mendapatkan kemampuan menjalankan kode, tetapi developer dapat menentukan apa yang boleh dilakukan dan apa yang harus diblokir.
Ada banyak teknologi yang dapat digunakan untuk kebutuhan ini. Beberapa memang dirancang khusus untuk AI Agent, sedangkan lainnya merupakan teknologi infrastruktur yang dapat digunakan untuk membangun execution environment sendiri.
Artikel ini membahas tujuh pilihan yang menarik untuk kebutuhan tersebut, mulai dari E2B yang berfokus pada agentic workloads hingga Docker, gVisor, Firecracker, WebAssembly, Bearly, dan Piston.
Mengapa AI Agent Membutuhkan Sandbox?
AI Agent memiliki karakteristik berbeda dibandingkan aplikasi biasa. Dalam aplikasi tradisional, developer biasanya menentukan kode yang akan dieksekusi.
Pada AI Agent, sebagian kode atau perintah dapat dibuat secara dinamis berdasarkan prompt, data, hasil tool sebelumnya, dan kondisi lingkungan.
Misalnya, developer memberikan instruksi:
“Analisis file CSV ini, buat grafik, kemudian jalankan script Python untuk mencari anomali.”
Agent kemudian dapat membuat kode Python, menjalankan library tertentu, membaca file, menghasilkan grafik, dan mengembalikan hasil.
Masalahnya adalah kita tidak selalu mengetahui bentuk kode yang akan dibuat agent sebelumnya.
Kode yang terlihat sederhana seperti:
import os
print(os.listdir("/"))
bisa menjadi masalah apabila dijalankan dengan permission terlalu besar. Begitu pula kode yang melakukan koneksi internet, membuat proses dalam jumlah besar, membaca environment variable, atau menggunakan filesystem host.
Karena itu, jangan memberikan agent akses lebih besar daripada yang diperlukan.
Prinsip tersebut dikenal sebagai least privilege. Sandbox menjadi salah satu cara praktis untuk menerapkan prinsip tersebut.
Apa yang Harus Dibatasi?
Sandbox yang baik untuk AI Agent sebaiknya tidak hanya membatasi proses eksekusi. Ada beberapa lapisan yang perlu diperhatikan.
Pertama adalah CPU dan memory. Tanpa pembatasan, kode dengan infinite loop atau penggunaan memory berlebihan dapat mengganggu workload lain. Docker, misalnya, menyediakan konfigurasi untuk membatasi memory dan CPU container.
Kedua adalah network access. Tidak semua kode yang dibuat agent membutuhkan internet. Docker bahkan menyediakan network driver none yang membuat container tidak memiliki koneksi jaringan eksternal dan hanya memiliki loopback interface.
Ketiga adalah filesystem. Agent sebaiknya hanya melihat file yang memang diperlukan untuk tugasnya.
Keempat adalah permission. Hindari menjalankan sandbox sebagai root jika tidak diperlukan.
Kelima adalah timeout. Program yang tidak pernah berhenti harus dihentikan secara otomatis.
Keenam adalah secret management. API key, token cloud, credential database, dan secret lainnya sebaiknya tidak otomatis diwariskan ke environment sandbox.
Dengan pendekatan tersebut, sandbox bukan sekadar tempat menjalankan program, tetapi menjadi bagian dari arsitektur keamanan AI Agent.
1. E2B
E2B merupakan salah satu platform yang memang sangat dekat dengan kebutuhan AI Agent. Platform ini menyediakan isolated environment untuk menjalankan kode agent di dalam cloud sandbox.
Arsitektur E2B menggunakan Firecracker microVM, sehingga setiap sandbox mendapatkan lingkungan virtual tersendiri. Dokumentasi E2B menjelaskan bahwa setiap sandbox berjalan pada microVM dengan kernel sendiri dan tidak berbagi kernel, filesystem, atau memory dengan sandbox customer lainnya.
Hal ini membuat E2B menarik untuk aplikasi yang membutuhkan eksekusi kode AI-generated secara dinamis.
Apa yang Membuat E2B Menarik?
E2B dirancang dengan konsep bahwa setiap agent mendapatkan sebuah machine untuk bekerja.
Sandbox dapat digunakan untuk menjalankan command, membaca dan menulis file, menggunakan shell, menjalankan code interpreter, serta melakukan pekerjaan yang membutuhkan environment Linux.
E2B juga mendukung penggunaan snapshot sehingga environment dapat dipersiapkan terlebih dahulu dan kemudian digunakan kembali ketika sandbox baru dibuat.
Pada dokumentasi E2B sebelumnya, sandbox dalam region yang sama disebut dapat dimulai dalam waktu kurang dari 200 ms.
Untuk AI Agent, kecepatan startup seperti ini penting karena agent dapat melakukan banyak execution step dalam satu workflow.
Cocok untuk Apa?
E2B sangat cocok untuk:
- AI coding agent.
- Code interpreter.
- Data analysis agent.
- Agent yang menjalankan shell command.
- Agent yang membuat atau menguji aplikasi.
- Eksperimen AI-generated code.
- Workflow yang membutuhkan isolated Linux environment.
E2B juga menawarkan opsi BYOC dan self-hosting untuk skenario tertentu, sehingga organisasi dapat menjalankan runtime di lingkungan cloud mereka sendiri.
Kelebihan utama E2B adalah developer tidak perlu membangun seluruh infrastruktur sandbox dari nol.
Hal yang Perlu Diperhatikan
E2B merupakan layanan yang lebih spesifik dibandingkan Docker. Jika kebutuhan Anda hanya menjalankan beberapa script internal yang sudah dipercaya, Docker mungkin sudah cukup.
Namun, jika targetnya adalah membangun AI Agent yang memang harus menjalankan kode secara dinamis, E2B menjadi opsi yang sangat relevan.
2. Bearly Code Interpreter
Bearly memiliki fitur Code Interpreter yang memungkinkan Python dijalankan dalam protected environment. Dokumentasinya menyebutkan bahwa fitur tersebut dapat digunakan untuk analisis data, visualisasi, pemrosesan file, dan menghasilkan file output.
Dalam ekosistem AI Agent, pendekatan seperti ini berguna ketika agent perlu melakukan komputasi nyata daripada hanya menghasilkan kode.
Misalnya, agent menerima file CSV.
Daripada sekadar mengatakan:
“Gunakan pandas untuk menghitung rata-rata.”
agent dapat menjalankan Python, membaca dataset, menghitung statistik, membuat grafik, kemudian mengembalikan hasil.
Fitur Code Interpreter
Bearly menyediakan sejumlah library Python untuk kebutuhan data science, termasuk pandas, NumPy, SciPy, scikit-learn, Matplotlib, Plotly, OpenCV, dan beberapa library lainnya.
Environment tersebut juga dapat digunakan untuk:
- Analisis CSV.
- Analisis Excel.
- Membuat grafik.
- Perhitungan matematika.
- Pemrosesan gambar.
- Konversi file.
- Eksperimen Python.
Ada integrasi BearlyInterpreterTool di LangChain yang memungkinkan Python code dieksekusi melalui sandbox dan digunakan sebagai tool dalam agent.
Kapan Bearly Menarik?
Bearly lebih cocok apabila kebutuhan Anda berpusat pada Python, data analysis, dan code interpreter daripada menyediakan full Linux machine untuk agent.
Misalnya:
User
↓
AI Agent
↓
Code Interpreter
↓
Python Sandbox
↓
Dataset
↓
Result
Model dapat meminta tool untuk menjalankan kode, sementara execution environment dipisahkan dari percakapan utama.
Kekurangannya
Dokumentasi Bearly menyebut Code Interpreter memiliki resource dan runtime yang terbatas sehingga lebih ditujukan untuk tugas kecil hingga menengah. Untuk dataset sangat besar atau workload komputasi panjang, dedicated development environment lebih sesuai.
Jadi, Bearly bukan berarti solusi universal untuk semua tipe AI Agent.
3. Docker
Docker mungkin merupakan nama yang paling familiar dalam daftar ini.
Berbeda dari E2B yang menyediakan sandbox sebagai layanan, Docker adalah platform container yang dapat digunakan sebagai building block untuk membuat sandbox sendiri.
Container memberikan environment terisolasi untuk aplikasi. Developer dapat menentukan image, filesystem, network, CPU, memory, environment variable, dan berbagai konfigurasi lainnya.
Mengapa Docker Cocok untuk AI Agent?
Bayangkan AI Agent Anda memiliki tool:
execute_python(code)
Daripada menjalankan Python secara langsung pada server utama, aplikasi dapat:
- Membuat container.
- Memasukkan kode.
- Menjalankan kode.
- Mengambil stdout/stderr.
- Mengambil hasil atau file.
- Menghapus container.
Dengan pola tersebut, agent tidak langsung bekerja di environment aplikasi utama.
Docker menyediakan kontrol resource seperti memory dan CPU. Secara default, container tidak otomatis mendapatkan batas resource yang ketat, sehingga developer perlu mengaturnya sendiri.
Network Isolation
Network juga sangat penting.
Docker menyediakan --network none untuk membuat container tanpa koneksi network eksternal.
Ini sangat berguna untuk sandbox AI Agent yang hanya membutuhkan komputasi lokal.
Sebaliknya, jika agent memang harus mengambil data dari API tertentu, network dapat dibuka secara lebih terbatas sesuai kebutuhan arsitektur.
Hindari penggunaan host networking untuk sandbox yang tidak dipercaya karena mode tersebut menghilangkan isolasi network antara container dan host.
Kelebihan Docker
- Open source.
- Ekosistem sangat besar.
- Bisa dijalankan lokal maupun cloud.
- Mendukung banyak bahasa.
- Resource limit tersedia.
- Network dapat dikontrol.
- Mudah diintegrasikan dengan CI/CD.
- Dapat dikombinasikan dengan Kubernetes.
Tetapi Docker Bukan Magic Shield
Ini bagian yang sering disalahpahami.
Container isolation tidak sama dengan virtual machine isolation.
Docker sangat berguna, tetapi konfigurasi yang salah dapat meningkatkan risiko. Misalnya memberikan privileged mode, memasang filesystem host secara sembarangan, menggunakan host network, atau memberikan credential yang tidak diperlukan.
Karena itu, Docker sebaiknya dianggap sebagai fondasi sandbox, bukan konfigurasi keamanan otomatis.
4. gVisor
gVisor merupakan teknologi sandbox open source dari Google yang dirancang untuk menjalankan workload tidak terpercaya dengan lapisan isolasi tambahan.
gVisor menarik karena pendekatannya berbeda dari container biasa.
Menurut dokumentasi resminya, gVisor bukan hypervisor VM biasa dan bukan sekadar syscall filter. gVisor menggunakan application kernel bernama Sentry untuk menangani system call workload.
Dengan kata sederhana, gVisor berada di antara aplikasi dan kernel host.
AI Agent
↓
Container
↓
gVisor Sentry
↓
Host Kernel
↓
Hardware
Tujuannya adalah mengurangi exposure langsung workload terhadap kernel host.
Mengapa gVisor Relevan untuk AI Agent?
AI Agent dapat menghasilkan kode yang tidak selalu dapat dipercaya.
gVisor secara eksplisit menyebut penggunaan untuk menjalankan LLM-generated code, user-uploaded code, dan third-party code sebagai salah satu use case.
Karena gVisor kompatibel dengan ekosistem container, teknologi ini dapat digunakan bersama Docker dan Kubernetes.
Defense in Depth
gVisor menggunakan beberapa lapisan isolasi.
Workload tidak langsung berinteraksi dengan host kernel seperti container biasa. Sentry menangani system call tertentu dan terdapat komponen Gofer untuk operasi filesystem.
gVisor juga menggunakan namespace, capability restriction, seccomp-bpf, serta mekanisme isolasi lainnya.
Apakah gVisor 100 Persen Aman?
Tidak ada sandbox yang dapat disebut 100 persen aman.
Dokumentasi gVisor sendiri menjelaskan bahwa sandbox bukan pengganti arsitektur keamanan secara keseluruhan. Hardware side-channel dan kelemahan pada komponen lain di luar boundary sandbox tetap dapat menjadi risiko.
Selain itu, gVisor memiliki performance overhead tertentu. Dokumentasi production guide menyarankan mempertimbangkan attack surface dan kebutuhan workload sebelum menerapkan sandbox ke seluruh aplikasi.
Karena itu, gVisor paling menarik untuk organisasi yang sudah menggunakan container tetapi membutuhkan lapisan isolasi tambahan.
5. Firecracker
Firecracker adalah teknologi microVM open source yang dikembangkan oleh AWS.
Firecracker menggunakan Linux KVM untuk menjalankan microVM. Konsepnya adalah menggabungkan isolasi virtual machine dengan efisiensi dan fleksibilitas workload berbasis container.
Firecracker terkenal karena menjadi bagian dari teknologi serverless AWS, termasuk AWS Lambda dan AWS Fargate.
Mengapa Firecracker Menarik untuk AI Agent?
AI Agent membutuhkan execution environment yang:
- Terisolasi.
- Cepat dibuat.
- Bisa dihancurkan setelah digunakan.
- Dapat diberi resource tertentu.
- Bisa menjalankan Linux.
- Cocok untuk multi-tenant workloads.
MicroVM sangat cocok dengan model tersebut.
Misalnya setiap session AI Agent mendapatkan:
Agent Session A → MicroVM A
Agent Session B → MicroVM B
Agent Session C → MicroVM C
Dengan demikian, environment antar-session dapat dipisahkan.
Security Boundary
Firecracker menggunakan beberapa lapisan keamanan.
KVM menyediakan virtualization boundary. Firecracker juga menggunakan seccomp, cgroups, namespaces, dan Jailer untuk menambah defense-in-depth.
Firecracker sendiri memiliki desain minimalis dengan perangkat virtual yang dibatasi. Tujuannya antara lain mengurangi attack surface dan memory footprint.
Firecracker Bukan Platform Siap Pakai
Ini perbedaan penting.
Firecracker lebih tepat disebut building block infrastruktur daripada layanan sandbox siap pakai seperti E2B.
Jika Anda memilih Firecracker secara langsung, Anda masih harus membangun:
- orchestration,
- image management,
- lifecycle management,
- networking,
- storage,
- authentication,
- API,
- logging,
- monitoring,
- scheduling,
- cleanup.
Karena itu, Firecracker lebih cocok untuk perusahaan atau developer yang memang membutuhkan kontrol penuh terhadap infrastruktur execution environment.
E2B sendiri menggunakan Firecracker sebagai fondasi microVM-nya.
Perhatian pada Security Update
Firecracker tetap harus dipelihara.
Sebagai contoh, repository resmi Firecracker mencatat security advisory pada 2026 terkait Jailer dan arbitrary host file overwrite pada versi tertentu yang kemudian diperbaiki melalui versi patched.
Artinya, menggunakan teknologi virtualisasi tidak berarti bebas dari kewajiban patching.
6. WebAssembly Runtime seperti Wasmtime dan Wasmer
WebAssembly atau WASM menawarkan pendekatan sandbox yang berbeda.
Alih-alih memberikan AI Agent sebuah Linux machine penuh, kode dapat dikompilasi atau dijalankan dalam WebAssembly runtime.
Wasmtime, misalnya, menjadikan sandboxing sebagai salah satu tujuan utama WebAssembly.
Dokumentasi Wasmtime menjelaskan bahwa WebAssembly memiliki memory isolation dan tidak memberikan akses langsung ke system call atau I/O host. Interaksi dengan dunia luar dilakukan melalui interface yang diberikan secara eksplisit.
Mengapa WASM Menarik?
Bayangkan agent memiliki kode:
AI Agent
↓
Generate Program
↓
Compile to WASM
↓
WASM Runtime
↓
Result
Program tersebut tidak otomatis mendapatkan akses ke seluruh filesystem dan network.
Developer dapat memberikan capability tertentu sesuai kebutuhan.
Contohnya:
Filesystem → DENY
Network → DENY
Clock → ALLOW
Stdout → ALLOW
Temporary storage → ALLOW
Pendekatan seperti ini sangat menarik untuk least privilege.
Capability-Based Security
Wasmtime menggunakan model capability untuk WASI filesystem. Artinya program hanya mendapatkan akses terhadap file atau direktori yang memang diberikan kepadanya.
Hal tersebut sangat relevan untuk AI Agent karena kita tidak ingin kode yang dibuat model tiba-tiba mendapatkan akses ke:
/etc
/home/user
~/.ssh
.env
database credentials
cloud credentials
tanpa alasan.
Kekurangannya
WASM bukan pengganti universal untuk container atau VM.
Program yang membutuhkan environment Linux lengkap, binary native tertentu, kernel feature tertentu, atau dependency yang tidak tersedia dalam WASM mungkin memerlukan effort tambahan.
Namun untuk workload yang cocok, WASM dapat memberikan sandbox yang ringan dan sangat terkontrol.
7. Piston
Piston adalah high-performance general-purpose code execution engine dari Engineer Man.
Project ini memang dibuat untuk menjalankan untrusted dan potentially malicious code dengan berbagai mekanisme isolasi.
Piston menarik untuk AI Agent karena menyediakan API untuk mengeksekusi kode dalam berbagai bahasa pemrograman.
Daftar runtime yang tersedia mencakup Python, JavaScript, C, C++, Java, Go, Rust, PHP, Ruby, Kotlin, Swift, dan banyak bahasa lainnya.
Bagaimana Piston Mengisolasi Kode?
Piston menggunakan Isolate di dalam Docker sebagai mekanisme utama sandboxing.
Project tersebut menggunakan kombinasi:
- Linux namespaces.
- chroot.
- unprivileged users.
- cgroups.
- process limits.
- memory limits.
- execution timeout.
Network outbound juga dinonaktifkan secara default pada execution environment Piston.
Resource Limit
Ini salah satu aspek Piston yang sangat relevan untuk AI Agent.
Execution API Piston menyediakan parameter untuk mengatur timeout dan batas CPU maupun memory.
Dokumentasi repository menyebut default runtime execution sekitar 3 detik, sementara compile stage dapat memiliki timeout yang berbeda.
Piston juga membatasi jumlah proses dan output untuk membantu mencegah abuse seperti fork bomb dan output berlebihan.
Cocok untuk AI Agent Multi-Bahasa
Piston sangat menarik apabila agent Anda dapat berpindah bahasa.
Misalnya agent diminta:
“Buat implementasi algoritma ini dalam Python.”
Kemudian:
“Sekarang buat versi C++.”
Kemudian:
“Bandingkan performanya dengan Rust.”
Execution engine dapat menyediakan runtime berbeda untuk masing-masing bahasa.
Catatan Penting soal Public API
Ada perubahan penting yang perlu diketahui.
Menurut repository resmi Piston, public API Piston tidak lagi tersedia secara bebas untuk publik sejak 15 Februari 2026 dan aksesnya menggunakan mekanisme authorization/whitelist tertentu. Namun Piston tetap open source sehingga developer dapat menjalankan instance sendiri.
Jadi, jangan memasukkan asumsi lama bahwa public Piston API selalu tersedia gratis tanpa pembatasan.
Untuk aplikasi production, self-hosting Piston dapat menjadi opsi apabila Anda siap mengelola infrastructure dan security-nya sendiri.
Bagaimana Memilih Sandbox untuk AI Agent?
Tidak semua AI Agent membutuhkan jenis sandbox yang sama.
Pilihan teknologi sebaiknya mengikuti jenis kode yang dijalankan dan seberapa besar kontrol yang dibutuhkan.
Jika Ingin Cepat Membuat AI Agent
E2B lebih praktis karena infrastructure sandbox sudah disediakan dan memang dirancang untuk agentic workloads.
Anda dapat fokus pada agent, tool, prompt, dan workflow tanpa membangun microVM orchestration sendiri.
Jika Membutuhkan Python Code Interpreter
Bearly cocok untuk kebutuhan yang berpusat pada Python, data analysis, file processing, dan visualization.
Ini ideal untuk agent yang lebih mirip data analyst daripada autonomous software engineer.
Jika Ingin Self-Hosted
Docker adalah titik awal yang sangat fleksibel.
Developer dapat menjalankannya pada laptop, server sendiri, VM, maupun cloud.
Namun konfigurasi security harus dibuat secara disiplin.
Jika Membutuhkan Isolation Tambahan untuk Container
gVisor dapat menjadi pilihan ketika Docker atau Kubernetes sudah digunakan tetapi workload yang tidak dipercaya membutuhkan isolation layer tambahan.
Jika Membangun Infrastruktur Sandbox Skala Besar
Firecracker cocok sebagai building block untuk membangun execution infrastructure berbasis microVM.
Namun kebutuhan engineering-nya jauh lebih besar dibandingkan menggunakan layanan sandbox siap pakai.
Jika Workload Cocok dengan WASM
WebAssembly menarik untuk workload yang membutuhkan sandbox ringan dengan capability yang sangat terkontrol.
Jika AI Agent Mendukung Banyak Bahasa
Piston cocok untuk use case code execution multi-language, khususnya jika Anda ingin menyediakan API execution engine sendiri.
Praktik Keamanan yang Sebaiknya Diterapkan
Memilih sandbox saja belum cukup.
Ada beberapa konfigurasi yang sebaiknya menjadi standar ketika membangun AI Agent yang dapat menjalankan kode.
1. Matikan Internet Jika Tidak Dibutuhkan
Ini merupakan salah satu aturan paling penting.
Jika agent hanya perlu melakukan kalkulasi lokal, tidak ada alasan memberikan akses internet.
Network yang terbuka dapat memungkinkan kode mengirim data ke server eksternal atau mengambil payload yang tidak diinginkan.
Docker menyediakan --network none, sementara platform seperti E2B menyediakan pengaturan egress sesuai arsitekturnya.
2. Gunakan Timeout
Jangan biarkan agent menjalankan program tanpa batas.
Gunakan batas waktu:
Execution timeout = 5 detik
atau angka lain yang sesuai dengan workload.
Untuk pekerjaan yang membutuhkan waktu lebih lama, gunakan job queue dan worker terpisah daripada membiarkan satu request HTTP terbuka tanpa batas.
3. Batasi CPU dan Memory
Gunakan resource limit.
Contohnya:
CPU = 1 vCPU
Memory = 512 MB
Disk = 1 GB
Angka tersebut hanya contoh dan harus disesuaikan dengan kebutuhan aplikasi.
Docker menyediakan CPU dan memory constraints, sedangkan Piston juga memiliki batas CPU dan memory pada execution environment-nya.
4. Jangan Berikan Secret Host
Hindari memasukkan:
AWS_SECRET_ACCESS_KEY
DATABASE_PASSWORD
OPENAI_API_KEY
GITHUB_TOKEN
SSH_PRIVATE_KEY
ke environment sandbox tanpa kebutuhan yang jelas.
Jika agent memang harus menggunakan API tertentu, lebih aman menggunakan secret broker atau mekanisme credential yang membatasi scope dan lifetime.
5. Batasi Filesystem
Jangan mount seluruh filesystem host.
Gunakan direktori sementara khusus untuk setiap execution.
Misalnya:
/workspace/job-123
setelah job selesai:
delete job-123
6. Jalankan dengan User Non-Root
Jika workload tidak membutuhkan root, jangan menjalankannya sebagai root.
Least privilege harus diterapkan sampai execution layer.
7. Pisahkan Session
Jika ada banyak user, sebaiknya setiap execution atau session memiliki sandbox sendiri.
Jangan membiarkan data dari:
User A
terlihat oleh:
User B
E2B, misalnya, menggunakan satu microVM untuk setiap sandbox sehingga state antar-sandbox dapat dipisahkan.
8. Bersihkan Environment
Setelah execution selesai, bersihkan:
- Temporary files.
- Process.
- Network connection.
- Environment variable.
- Session state.
- Credentials.
- Mounted files.
Untuk workload yang sangat sensitif, disposable sandbox sering lebih aman daripada sandbox yang terus digunakan ulang.
Tabel Perbandingan 7 Software Sandbox
Setiap teknologi memiliki posisi yang berbeda. Ada yang berfungsi sebagai platform siap pakai, ada yang menjadi runtime, dan ada pula yang lebih tepat disebut infrastructure building block.
| Software | Jenis Teknologi | Fokus Utama | Isolasi | Bahasa/Runtime | Deployment | Cocok untuk AI Agent | Catatan |
|---|---|---|---|---|---|---|---|
| E2B | Cloud sandbox / microVM | AI Agent & code execution | Firecracker microVM | Linux workload | Cloud, BYOC, self-hosted runtime | Sangat cocok | Praktis untuk agentic workloads |
| Bearly | Code Interpreter | Python & data analysis | Protected execution environment | Python | Cloud/app | Cocok | Lebih fokus pada code interpreter |
| Docker | Container | General-purpose isolation | Container / namespaces | Banyak bahasa | Local, server, cloud | Sangat fleksibel | Konfigurasi security menjadi tanggung jawab developer |
| gVisor | Application kernel sandbox | Container hardening | Sentry + Linux isolation | Linux containers | Docker, Kubernetes | Cocok | Ada performance overhead |
| Firecracker | MicroVM | Secure multi-tenant workloads | KVM microVM | Linux | Self-hosted infrastructure | Sangat cocok | Membutuhkan engineering lebih besar |
| WebAssembly | WASM runtime | Lightweight sandbox | WASM memory/capability isolation | Bahasa yang mendukung WASM | Local/server/cloud | Cocok untuk workload tertentu | Tidak semua Linux workload mudah dipindahkan |
| Piston | Code execution engine | Multi-language execution | Isolate + Docker + Linux isolation | Banyak bahasa | Self-hosted / API | Cocok | Public API memiliki pembatasan akses sejak 2026 |
Jika kebutuhan Anda adalah AI Agent yang harus langsung bisa menjalankan kode tanpa membangun seluruh infrastructure, E2B merupakan salah satu pendekatan yang paling dekat dengan kebutuhan tersebut. E2B menggunakan Firecracker microVM dan menyediakan API untuk execution, filesystem, lifecycle, network, serta observability.
Jika Anda ingin membangun sendiri, kombinasi Docker, gVisor, Firecracker, atau WebAssembly memberikan tingkat kontrol yang lebih besar. Piston juga menarik untuk execution engine multi-bahasa, sementara Bearly lebih spesifik untuk workflow Python dan data analysis.
Pada akhirnya, sandbox terbaik bukan hanya yang memiliki isolasi paling kuat, tetapi yang sesuai dengan threat model, jenis workload, biaya, kebutuhan latency, dan kemampuan tim dalam mengelolanya.
Untuk prototype AI Agent sederhana, container yang dikonfigurasi dengan resource limit, filesystem terbatas, non-root user, dan network yang dibatasi mungkin sudah memadai.
Untuk platform multi-tenant yang menjalankan kode AI-generated secara masif, pendekatan berbasis microVM seperti Firecracker atau platform yang menggunakannya dapat memberikan boundary isolasi yang lebih kuat.
Sementara itu, WebAssembly dapat menjadi pilihan menarik ketika workload dapat dikompilasi ke WASM dan developer menginginkan sandbox yang ringan dengan permission berbasis capability.
Yang paling penting, jangan menganggap sandbox sebagai satu-satunya lapisan keamanan. AI Agent sebaiknya tetap dibatasi dengan least privilege, network policy, resource quota, timeout, secret isolation, logging, dan monitoring.
Dengan kombinasi tersebut, kemampuan agent untuk menjalankan kode dapat dimanfaatkan tanpa harus memberikan akses penuh kepada kode yang dihasilkan model terhadap sistem utama.
