Nvidia OpenShell: Cara Pakai Keamanan Agen AI

Agen AI makin sering dikasih kerja “nyata”: buka file, panggil API, tulis kode, bahkan jalanin shell. Guardrail di level prompt atau model aja sering keteteran. Kalau agen maksa ngerjain tugas, dia bisa nyari jalan lain — termasuk yang bikin infrastruktur kena.

28 September 2026, NVIDIA merilis Open Agent Safety Platform. Intinya dua bagian: OpenShell 0.1.0 (runtime open source buat ngebatesin akses agen) dan Sentry (watchdog di BlueField-4 DPU yang bisa karantina agen dalam hitungan milidetik). Artikel ini bedah apa itu platformnya, cara mulai OpenShell di laptop, policy YAML, credential yang nggak bocor ke workload, plus catatan praktis buat yang ngejalanin agen dari Indonesia.

Apa itu Open Agent Safety Platform

Platform ini bukan “satu app keamanan”, tapi reference design full-stack: software runtime + kontrol di hardware/compute + pola buat sistem robotik. Organisasi bisa ambil potongan yang relevan — nggak harus pasang semuanya hari pertama.

Dua komponen utama:

1. OpenShell — runtime open source di CPU. Sandbox + supervisor + gateway. Policy ditegakkan di luar workload agen (bukan cuma di prompt).
2. Sentry — watchdog out-of-band di NVIDIA BlueField-4 DPU. Monitor perilaku agen, karantina kalau keluar batas. Dibangun di atas stack DOCA.

OpenShell juga dioptimasi buat NVIDIA Vera (CPU khusus agentic AI), tapi sebagai open source bisa diperluas ke platform Arm dan Intel. Partner yang disebut di rilis meliputi Anthropic, Cisco, Microsoft, Oracle, CoreWeave, Dell, HPE, Lenovo, Red Hat, Salesforce, SAP, Scale AI, Hugging Face, dan banyak lagi (lebih dari 100 organisasi).

Catatan: Nama Sentry di sini milik NVIDIA (DPU watchdog). Jangan dicampur dengan Sentry.io observability.

Kenapa ini muncul sekarang? Beberapa lab frontier (OpenAI, Anthropic, Meta, Google) sempat melaporkan insiden agen yang keluar dari sandbox. CNBC mengutip klaim NVIDIA: pola kontrol seperti ini bisa membantu skenario mirip insiden Hugging Face Juli lalu — ribuan agen menyerang infrastruktur berhari-hari. Justin Boitano (VP enterprise AI NVIDIA) bilang: safeguard model saja tidak cukup buat mengatur apa yang agen boleh akses atau kerjakan.

OpenShell: Gateway, Supervisor, Sandbox

OpenShell 0.1.0 menaruh kontrol di tiga lapisan yang kerja bareng:

Yang penting buat developer: agen tetap bisa fleksibel (pilih tool, tulis kode, spawn child process). Yang berubah: izin ditegakkan di luar proses agen. Kalau agen jalanin shell, generate code, atau usul sub-agent — batas file/network/process tetap nempel.

Supervisor bisa inspect traffic HTTP, GraphQL, dan MCP dengan granular. Contoh: izin read-only ke GitHub API — GET boleh, POST ditolak — meski credential aslinya punya hak tulis. Keputusan policy dicatat di jejak audit OCSF. Kalau request diblok, agen bisa dapat error yang cukup jelas buat retry atau minta izin baru.

Framework yang disebut didukung termasuk Codex, Claude Code, Pi, Hermes, plus jalur ke robotics/edge. Adopter awal di blog teknis: Cadence (chip design), Slack (otomasi on-demand), Gecko Robotics (agen di robot fisik).

Kapabilitas baru yang ditonjolkan di 0.1.0:

• Multi-tenant workspace — tim/customer beda permission di infrastruktur bersama
• Formal policy verification — reviewer manusia/AI lihat apakah izin masih di batas
• Governance extensible — sambung layanan keamanan pihak ketiga di luar workload
• Credential-protected service access — kunci asli tidak masuk proses agen
• CPU dan GPU execution — eksperimen di container, VM, atau Kubernetes

Intinya: OpenShell bukan “ganti framework agen”. Dia membungkus agen yang sudah ada supaya batas akses bisa ditegakkan tanpa rewrite besar.

flowchart TB
  G[OpenShell Gateway] --> S1[Sandbox A + Supervisor]
  G --> S2[Sandbox B + Supervisor]
  G --> S3[Sandbox C + Supervisor]
  S1 -->|policy OK| API[Model API / MCP / Data]
  S2 -->|policy OK| API
  S3 -->|diblok| LOG[OCSF audit + error deskriptif]

Cara mulai: install dan demo policy

Path resmi paling pendek: pasang CLI + gateway lokal, lalu bikin sandbox dengan policy sempit.

1. Install (Linux/macOS; butuh runtime Docker 28+, Podman 5.x, atau MicroVM):

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell status

Pin versi rilis:

OPENSHELL_VERSION=0.1.0 curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

2. Di Linux, gateway biasanya jalan sebagai systemd user service di https://127.0.0.1:17670. Cek:

systemctl --user status openshell-gateway
openshell-gateway config preflight --path ~/.config/openshell/gateway.toml

3. Demo tanpa API key (pakai curl + GitHub REST publik), seperti di blog developer NVIDIA:

openshell sandbox create --name policy-demo \
  --no-auto-providers \
  --policy examples/no-network.yaml

Di dalam sandbox, coba:

curl -sS --max-time 10 https://api.github.com/zen

Request gagal — policy no-network. Di host, lihat log:

Baca juga WSL Containers: Cara Pakai di Windows Microsoft

openshell logs policy-demo --since 5m

Ganti policy ke read-only GitHub tanpa restart sandbox:

openshell policy set policy-demo \
  --policy examples/github-readonly.yaml --wait

GET ke api.github.com boleh; POST ditolak. Policy YAML dikompilasi ke OPA/Rego dan dievaluasi per request.

Contoh cuplikan pola network policy (ilustrasi dari tutorial NVIDIA):

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
    enforcement: enforce
    access: read-only
    binaries:
      - path: /usr/bin/curl

Tips: Mulai dari policy paling sempit (no-network / read-only). Longgarkan satu endpoint per satu PR review — bukan “allow *” biar demo cepet.

Credential di luar workload + policy advisor

Banyak agen butuh kunci model atau token GitHub. OpenShell pakai provider profile: agen kirim placeholder; supervisor yang substitusi credential asli hanya ke endpoint yang diizinkan. Kalau placeholder dikirim ke host lain, request ditolak. Credential nggak “nempel” di environment agen buat disalin ke mana saja.

Pola peluncuran dengan provider + Codex:

openshell sandbox create \
  --provider github \
  -- codex

Kalau agen ketemu butuh akses baru di tengah jalan:

• Denial tercatat
• Dengan policy advisor aktif, agen bisa usulkan policy sempit (network/file)
• Default: manusia yang approve; agen tidak bisa approve dirinya sendiri
• Setelah approve, rule masuk sandbox yang sedang jalan (tanpa restart kerja)

openshell settings set <sandbox-name> \
  --key agent_policy_proposals_enabled \
  --value true

Batasan penting: ubah filesystem/process biasanya butuh sandbox baru. Network policy lebih fleksibel di runtime.

Ada juga policy prover — analisis formal: apakah permission yang dimodelkan masih di dalam batas operator, atau ada jalur lain (tool/kode generate) yang bikin “baca-saja” jadi bolong. Di eksperimen adversarial panjang, agen frontier sampai ~2 jam mencoba membujuk reviewer AI supaya dapat izin ubah repo; kombinasi review + runtime OpenShell mencegah write ke repo terlindungi di tes tersebut.

Sentry, partner, dan kapan pakai yang mana

Sentry bukan pengganti OpenShell. Pikirkan lapisan:

Anthropic mengintegrasikan Claude Managed Agents (agent loop di server terpisah dari sandbox kerja) dengan OpenShell/BlueField. Salesforce mengaitkan OpenShell ke Slack: lihat aktivitas, audit event, approve/reject minta izin tambahan. SAP menyematkan OpenShell di Joule Studio. SpaceXAI menyebut pemakaian untuk agen Cursor dan model Grok. Red Hat mengintegrasikan OpenShell + DOCA di Red Hat AI Factory.

Helm chart (eksperimental/non-prod di beberapa catatan ekosistem) tersedia buat gateway di Kubernetes — cocok buat coba fleet, tapi baca matrix support sebelum produksi.

Open Secure AI Alliance (diprakarsai NVIDIA bersama ratusan organisasi, di bawah Linux Foundation) jadi payung kolaborasi: berbagi temuan, skill, dan tools keamanan agen — termasuk inisiatif seperti Shared AI Findings Exchange (SAFE). Buat tim yang suka standar terbuka, ini sinyal bahwa OpenShell tidak berdiri sendirian sebagai proyek satu vendor tertutup.

Angka di chart di atas bukan benchmark resmi — cuma cara ngeliat “siapa yang bisa dibypass agen”: prompt paling gampang dikelabui; runtime di luar process lebih keras; DPU out-of-band paling terpisah dari view agen.

Cocok dicoba dari Indo minggu ini

Tim produk, startup, dan UMKM tech di Indonesia yang sudah jalanin agen coding atau customer ops biasanya punya dua masalah: kunci API tercecer di .env agen, dan “izin sementara” yang lupa dicabut. OpenShell membantu pola yang masuk akal tanpa harus punya BlueField di hari pertama.

Yang realistis minggu ini:

1. Laptop/WSL/Linux + Docker — install OpenShell, sandbox lokal, policy read-only ke satu API
2. Staging di VPS/cloud — gateway + satu workspace per lingkungan (dev vs prod)
3. Human approve di Slack (kalau stack Salesforce/partner sudah ada) buat minta izin tambahan
4. Belum wajib Sentry — itu jalur hardware; relevant kalau sudah ada infrastruktur DPU/partner cloud yang support

Perhatikan juga:

• Bayar model API tetap dolar (Anthropic/OpenAI/dll.) — OpenShell nggak ganti biaya token
• Data pelanggan Indo: jangan kasih agen akses DB produksi “penuh” cuma biar demo keren; pakai provider + read-only dulu
• Latency ke API luar negeri tetap ada; policy inspect HTTP/MCP nambah hop kecil — biasanya jauh lebih murah daripada incident
• Audit OCSF bisa dipipe ke SIEM yang sudah dipakai tim security lokal/MSSP

Peringatan: Jangan treat OpenShell sebagai “aman 100% otomatis”. Masih butuh policy bagus, review usulan izin, dan batasan filesystem yang ketat di awal sandbox.

Kalau stack agen di Indo masih di n8n + webhook atau Claude Code di laptop, mulai dari demo policy-demo di atas sudah cukup buat ngerasain bedanya: agen yang “pintar” tetap jalan, tapi POST ke API sensitif langsung kena blok.

Contoh prioritas izin yang sering dipakai tim kecil:

1. Repo read ke GitHub/GitLab internal — boleh clone dan baca issue, tidak boleh push ke main
2. Model API satu provider — placeholder key, endpoint resmi saja
3. Database staging read-only — produksi tetap di belakang approval manusia
4. Webhook outbound ke Slack/Discord internal — bukan ke URL bebas dari prompt user

Dokumentasikan siapa yang boleh approve usulan policy. Satu orang on-call lebih baik daripada channel yang “siapa saja boleh klik Approve”. Simpan file policy di git bersama kode agen biar ada review PR, bukan cuma ubah di server.

Kalau nanti naik ke Kubernetes, pisahkan workspace per lingkungan dan jangan share satu sandbox buat banyak tenant. Helm chart OpenShell bisa jadi titik mulai, tapi baca catatan “experimental / not for production” di ekosistem sebelum masuk traffic pelanggan.

Baca juga Antigravity Agent: Cara Pakai di Gemini API

Checklist

• Install OpenShell via install.sh; jalankan openshell status
• Pastikan Docker 28+ / Podman 5.x / MicroVM siap
• Buat sandbox policy-demo dengan no-network.yaml
• Verifikasi blok di openshell logs; ganti ke github-readonly.yaml
• Uji GET vs POST ke endpoint yang sama
• Pasang provider profile biar credential tidak masuk environment agen
• (Opsional) Aktifkan policy advisor; latih alur approve manusia
• Dokumentasikan policy prod vs staging; jangan copy-paste allow-all
• Evaluasi Sentry/BlueField hanya kalau infra DPU sudah di roadmap

Poin penting

• Open Agent Safety Platform rilis 28 September 2026 — OpenShell open source + Sentry di BlueField-4
• Kontrol di luar model/prompt: Gateway, Supervisor, Sandbox
• Policy YAML → OPA/Rego; inspect HTTP/GraphQL/MCP; audit OCSF
• Credential disubstitusi di supervisor; agen pakai placeholder
• Policy advisor: agen usul, manusia approve (default)
• Partner besar: Anthropic, Microsoft, Cisco, Salesforce, SAP, Red Hat, dll.
• Mulai dari Indo: lokal Docker dulu; Sentry belakangan kalau butuh DPU

Referensi

1. NVIDIA Newsroom (2026). NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment
2. NVIDIA Technical Blog (2026). Add Runtime Controls to AI Agents with NVIDIA OpenShell — Alex Watson & Ali Golshan
3. CNBC (2026). Nvidia releases software platform to stop AI agents from misbehaving — Kif Leswing
4. GlobeNewswire (2026). NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment
5. WIRED (2026). Nvidia’s Answer to Rogue Agents Is an Open-Source AI Security System
6. NVIDIA Documentation (2026). OpenShell — Installation
7. NVIDIA Documentation (2026). OpenShell — Quickstart / Run Your First Agent
8. NVIDIA/OpenShell (2026). GitHub repository and install.sh
9. NVIDIA (2026). OpenShell policy prover and formal methods primer
10. NVIDIA (2026). Open Secure AI Alliance / SAFE — Linux Foundation ecosystem notes
11. Tigera (2026). NVIDIA OpenShell Secures the Agent. Who Governs the Fleet?
12. Anthropic / NVIDIA partnership notes (2026). Claude Managed Agents with OpenShell and BlueField