NVIDIA OpenShell: Sandbox Agen AI dengan Policy di Level Kernel

NVIDIA merilis OpenShell, runtime untuk menjalankan banyak agen AI dengan pembatasan akses di tingkat kernel. Proyek ini berlisensi Apache 2.0, tersedia di GitHub sejak versi 0.1.x, dan bisa dipasang lewat installer satu baris. Pendekatannya berbeda dari sandbox biasa: setiap akses file, syscall, dan koneksi jaringan diperiksa terhadap policy, sementara kredensial asli tidak pernah sampai ke agen. Perubahan policy diperiksa dengan verifikasi formal sebelum diterapkan, sehingga akses baru yang berisiko menunggu review manusia.

TL;DR

• OpenShell adalah runtime sandbox untuk agen AI, berlisensi Apache 2.0 dan dikembangkan NVIDIA di GitHub.
• Policy ditegakkan di tingkat kernel untuk akses file, syscall, dan koneksi jaringan, bukan hanya di lapisan aplikasi.
• Agen tidak pernah menerima kredensial asli; OpenShell menyisipkannya hanya untuk request ke endpoint yang disetujui.
• Butuh Linux, macOS Apple Silicon, atau Windows dengan WSL 2, plus Docker, Podman, atau virtualisasi host.

Apa yang membuat OpenShell berbeda dari container biasa?

Perbedaannya ada di tiga lapisan: penegakan policy di kernel, penyembunyian kredensial, dan verifikasi formal sebelum perubahan policy disetujui. Container biasa membatasi proses, tetapi tidak memeriksa setiap koneksi jaringan terhadap daftar tujuan yang diizinkan, dan tidak memeriksa apakah perubahan konfigurasi membuka akses berbahaya.

Setiap agen berjalan di sandbox terisolasi. Kontrol kernel membatasi file yang bisa diakses dan syscall yang bisa dipanggil, dan setiap koneksi jaringan melewati pemeriksaan policy sebelum keluar dari sandbox. Agen tidak pernah melihat kredensial asli, karena OpenShell menambahkan kredensial itu hanya pada request yang menuju endpoint yang sudah disetujui.

Lapisan kedua adalah verifikasi formal. Sebelum perubahan policy disetujui, OpenShell memeriksa konsekuensi perubahan itu dan menandai akses baru yang berisiko, misalnya menjangkau host baru dengan kredensial atau memanggil metode API baru. Temuan seperti itu menunggu review manusia, bukan diterapkan otomatis.

Arsitekturnya terdiri dari tiga bagian: gateway sebagai bidang kendali, supervisor, dan sandbox itu sendiri. Gateway mengatur sandbox, policy, dan akses. Untuk instalasi Kubernetes, gateway dipasang lewat Helm, dan CNI yang dipakai wajib menegakkan NetworkPolicy. Kalau CNI tidak menegakkan NetworkPolicy, sebagian jaminan jaringan di lapisan cluster tidak berlaku.

Bagaimana cara mulai memakai OpenShell?

Pasang lewat installer resmi, lalu buat sandbox pertama dengan perintah openshell sandbox create. Installer menyiapkan CLI dan gateway lokal, dan image sandbox default adalah Ubuntu minimal tanpa agen terpasang.

Prasyaratnya Linux, macOS di Apple Silicon, atau Windows dengan WSL 2 yang masih berstatus eksperimental. Di sisi runtime, dibutuhkan Docker, Podman, atau virtualisasi host. Karena image default belum memuat agen, langkah berikutnya adalah mengikuti tutorial menjalankan agen pertama, yang memakai OpenCode dengan model gratis dari OpenRouter dan memperlihatkan cara menyetujui akses baru saat agen membutuhkannya.

Untuk aplikasi yang perlu terhubung ke gateway, tersedia SDK di empat bahasa. SDK tidak memasang CLI, jadi keduanya dipasang terpisah. Sebaiknya versi SDK dan gateway disamakan untuk menghindari perbedaan perilaku.

Bahasa	Cara pasang	Catatan
Python	uv add openshell	Paket tersedia di PyPI
TypeScript	npm install @nvidia/openshell-sdk	Didistribusikan lewat GitHub Packages
Go	go get github.com/NVIDIA/OpenShell/sdk/go	Ambil versi terbaru dari repositori
Rust	cargo add openshell-sdk	Dari repositori dengan tag rilis tertentu

Ada juga paket skills untuk agen coding: npx skills add NVIDIA/OpenShell. Skills itu mengajari agen memakai CLI OpenShell, menulis policy sandbox, dan men-debug gateway serta routing inference, tanpa perlu checkout source.

Apakah OpenShell mengirim data ke NVIDIA?

Secara default OpenShell mengumpulkan telemetri anonim, tetapi cakupannya dibatasi pada kategori operasional dan jumlah. Data seperti nama sandbox, hostname, path file, prompt, kredensial, nama provider atau model, dan konten pengguna tidak dikumpulkan.

Telemetri bisa dimatikan dengan mengatur OPENSHELL_TELEMETRY_ENABLED=false pada gateway, atau server.telemetryEnabled=false untuk instalasi Helm. Untuk yang ingin lebih ketat, telemetri bisa dikeluarkan sepenuhnya saat kompilasi. Laporan tren penggunaan juga dipublikasikan di repositori, jadi klaim soal cakupan data bisa diperiksa sendiri.

Yang perlu diperhatikan justru sisi lain: OpenShell otomatis mengambil dan berinteraksi dengan materi eksternal. Materi yang diambil tidak didistribusikan bersama perangkat lunak dan tunduk pada ketentuan serta lisensi masing-masing. Karena itu, penanggung jawab tetap bertanggung jawab memeriksa lisensi, keamanan, dan kelayakan materi yang diambil agen.

Untuk tim yang menjalankan agen dengan akses ke repositori internal, kombinasi policy kernel dan kredensial yang disisipkan per endpoint mengurangi risiko kunci bocor ke prompt atau log. Kuncinya tetap tidak terlihat oleh agen, dan hanya muncul pada request yang tujuannya sudah disetujui.

Kapan OpenShell layak dipertimbangkan?

Saat agen perlu akses nyata ke file, paket, API, dan kredensial, tetapi akses itu tidak boleh tanpa batas. Kalau agen hanya membaca satu direktori dan tidak pernah memanggil API eksternal, sandbox terpisah dengan policy ketat mungkin sudah cukup tanpa lapisan tambahan.

Kebutuhan OpenShell naik ketika jumlah agen bertambah dan masing-masing punya izin berbeda. Policy per agen lebih mudah diaudit daripada sekumpulan skrip yang menyalakan dan mematikan akses secara manual. Verifikasi formal menambah satu lapis lagi: perubahan izin tidak langsung berlaku hanya karena seseorang menambahkan satu baris konfigurasi.

Yang perlu dihitung adalah biaya operasionalnya. Ada gateway yang harus dijalankan, ada sandbox image yang harus dirawat, dan ada proses review untuk perubahan policy. Untuk satu agen di laptop pengembang, biaya itu mungkin berlebihan. Untuk armada agen yang menyentuh data produksi, biaya itu justru bagian dari kontrol.

Status 0.1.x menandakan proyek ini masih di tahap awal, meski sudah punya jadwal rilis yang stabil, primitif isolasi baru, dan permukaan ekstensi yang lebih luas. Untuk beban kerja kritis, uji dulu di lingkungan terpisah dan catat perilaku gateway saat policy berubah.

Yang perlu diperiksa sebelum menjalankan di produksi

Sebelum dipakai untuk beban kerja nyata, tiga hal perlu dipastikan: dukungan runtime di host, penegakan NetworkPolicy di cluster, dan cara kredensial disimpan di sisi gateway. Ketiganya menentukan apakah policy yang ditulis benar-benar berlaku di lapisan yang dijanjikan.

Di host, pilihan runtime menentukan isolasi yang tersedia. Docker, Podman, dan virtualisasi host memberi tingkat pemisahan yang berbeda, dan dokumentasi menyediakan support matrix per platform. Untuk macOS, dukungan terbatas pada Apple Silicon. Untuk Windows, jalurnya WSL 2 dan masih berstatus eksperimental, jadi tidak cocok untuk beban kerja yang butuh kestabilan penuh.

• Pastikan runtime container atau virtualisasi tersedia dan versinya didukung.
• Di Kubernetes, verifikasi CNI benar-benar menegakkan NetworkPolicy sebelum mengandalkan pembatasan jaringan.
• Tentukan siapa yang berwenang menyetujui perubahan policy dan bagaimana jejaknya dicatat.
• Putuskan sejak awal apakah telemetri dimatikan lewat variabel lingkungan atau lewat konfigurasi Helm.

Untuk kredensial, model yang dipakai berbeda dari sekadar menyimpan secret di environment variable. Agen tidak memegang nilai asli, dan kredensial disisipkan hanya pada request yang menuju endpoint yang disetujui. Konsekuensinya, daftar endpoint yang disetujui menjadi bagian dari permukaan keamanan: endpoint yang terlalu longgar membuat penyisipan kredensial terjadi di tempat yang tidak diinginkan, sedangkan daftar yang terlalu sempit membuat agen gagal pada tugas yang sah.

Untuk audit, catat setiap perubahan policy beserta alasannya. Karena perubahan berisiko menunggu review manusia, antrean review perlu pemilik yang jelas. Tanpa pemilik, perubahan yang seharusnya cepat bisa tertahan, dan tim akan tergoda memberi izin luas supaya pekerjaan jalan. Pola itu menghapus manfaat utama dari pembatasan berlapis.

Referensi teknisnya tersedia lengkap: source dan README ada di repositori GitHub NVIDIA OpenShell, dokumentasi resmi memuat arsitektur, sandbox, policy, provider, dan panduan Kubernetes, sedangkan paket Python ada di PyPI. Untuk mencoba tanpa menyiapkan infrastruktur sendiri, dokumentasi juga menyediakan jalur menjalankan agen pertama dengan model gratis, yang cukup untuk menguji alur persetujuan akses sebelum masuk ke lingkungan internal.

Satu konsekuensi yang perlu dipahami sejak awal: policy yang ketat memindahkan sebagian pekerjaan dari agen ke manusia. Setiap kali agen membutuhkan akses baru, ada keputusan yang harus diambil, dan keputusan itu butuh konteks tentang tugas yang sedang dijalankan. Tim yang menjalankan agen dalam jumlah besar sebaiknya menyiapkan jalur persetujuan yang cepat untuk permintaan rutin, sambil tetap menyisakan review ketat untuk akses yang menyentuh data sensitif atau kredensial produksi.

Untuk lisensi, proyek ini memakai Apache 2.0, sehingga penggunaan komersial dan modifikasi diizinkan dengan kewajiban yang menyertai lisensi tersebut. Yang perlu diperhatikan justru materi eksternal yang diambil agen saat berjalan: materi itu tidak ikut didistribusikan bersama perangkat lunak dan tunduk pada ketentuan masing-masing. Tim yang memakai agen untuk mengambil dokumentasi atau data pihak ketiga tetap bertanggung jawab memeriksa lisensi materi tersebut sebelum menyimpannya atau menggunakannya kembali.

Untuk tim yang belum pernah memakai sandbox dengan policy terverifikasi, langkah paling murah adalah mencoba satu agen dengan daftar endpoint yang sangat pendek, lalu mencatat setiap permintaan akses yang muncul. Catatan itu menjadi bahan untuk menyusun policy awal yang realistis, bukan policy yang dibuat dari perkiraan.

FAQ

Apakah OpenShell gratis?

Ya, proyek ini berlisensi Apache 2.0 dan source-nya tersedia di GitHub. Tidak ada biaya lisensi yang disebut dalam dokumentasi, meski biaya infrastruktur untuk menjalankan gateway dan sandbox tetap ditanggung pengguna.

Platform apa saja yang didukung?

Linux, macOS di Apple Silicon, dan Windows lewat WSL 2 yang masih eksperimental. Di sisi runtime dibutuhkan Docker, Podman, atau virtualisasi host, dan detail per platform ada di support matrix dokumentasi resmi.

Apakah agen bisa melihat kredensial asli?

Tidak. OpenShell menyisipkan kredensial hanya pada request yang menuju endpoint yang disetujui, sehingga agen tidak pernah memegang nilai aslinya. Ini mengurangi risiko kunci bocor lewat prompt, log, atau kesalahan konfigurasi.

Apakah policy bisa diubah tanpa review?

Perubahan policy diperiksa dengan verifikasi formal sebelum diterapkan, dan detailnya ada di dokumentasi policy. Akses baru yang berisiko, seperti host baru dengan kredensial atau metode API baru, ditandai dan menunggu review manusia sebelum berlaku.

Apakah OpenShell butuh Kubernetes?

Tidak wajib. Gateway bisa berjalan lokal bersama CLI. Untuk deployment di cluster, tersedia jalur Helm, dan pada mode itu CNI yang dipakai harus menegakkan NetworkPolicy agar pembatasan jaringan di lapisan cluster berfungsi.