Menjalankan NanoClaw di sandbox Docker

• Berkat kolaborasi NanoClaw dan Docker, kini setiap agen AI dapat dijalankan di sandbox Docker yang terisolasi dengan satu baris perintah
• Setiap agen berjalan di kontainer independen di dalam micro VM, dengan lingkungan yang sepenuhnya terisolasi tanpa akses ke sistem host
• Melalui struktur batas keamanan ganda, meski terjadi container escape, akses tetap diblokir di lapisan VM sehingga file, kredensial, dan aplikasi host tetap terlindungi
• Model keamanan NanoClaw mengadopsi "desain berbasis ketidakpercayaan", dengan menganggap agen sebagai pihak yang berpotensi berbahaya dan meminimalkan dampak kerusakan
• Ke depan, pengembang menargetkan perluasan fitur untuk operasi tim agen dalam skala besar seperti kontrol berbagi konteks, agen persisten, kebijakan izin terperinci, dan proses persetujuan manusia

---

Gambaran umum integrasi sandbox Docker

• NanoClaw mendukung menjalankan sandbox dengan satu baris perintah melalui kolaborasi dengan Docker
  • Didukung di macOS (Apple Silicon) dan Windows (WSL), dengan Linux akan segera menyusul
  • Skrip instalasi otomatis menangani clone, konfigurasi, dan penyiapan sandbox
• Setiap agen berjalan di kontainer independen di dalam micro VM
  • Tidak memerlukan perangkat keras tambahan atau konfigurasi yang rumit
  • Setiap kontainer memiliki kernel dan daemon Docker sendiri, dan akses ke host diblokir

Cara kerjanya

• Sandbox Docker menyediakan isolasi tingkat hypervisor dengan waktu mulai cepat dalam hitungan milidetik
• NanoClaw dipetakan secara alami ke struktur ini
  • Setiap agen memiliki filesystem, konteks, alat, dan sesi yang terpisah
  • Contoh: agen penjualan tidak dapat mengakses pesan pribadi, dan agen dukungan tidak dapat mengakses data CRM
• Lapisan micro VM membentuk batas keamanan kedua
  • Bahkan jika terjadi container escape, dinding VM akan menahannya sehingga sistem host tetap terlindungi

Model keamanan: desain berbasis ketidakpercayaan

• NanoClaw dirancang dengan asumsi tidak mempercayai agen AI
  • Mempertimbangkan risiko tak terduga seperti prompt injection dan malfungsi model
  • Dirancang agar rahasia atau kredensial tidak ditempatkan di lingkungan agen
• Keamanan dipaksakan dari luar agen, bukan bergantung pada perilaku agen yang benar
• Berbeda dengan OpenClaw, NanoClaw menyediakan isolasi penuh antaragen
  • OpenClaw berbagi lingkungan yang sama sehingga data pribadi dan data kerja dapat bercampur
• Pendekatan ini menekankan prinsip rekayasa keamanan yang memandang agen sebagai rekan kolaborasi sekaligus calon penyerang

Arah pengembangan selanjutnya

• Ditekankan perlunya membangun infrastruktur baru dan lapisan runtime untuk mengoperasikan tim agen dalam skala besar
• NanoClaw sudah dapat terhubung ke beberapa channel Slack untuk mengoperasikan agen independen per tugas
• Empat fitur utama yang diajukan untuk tahap berikutnya
  • Berbagi konteks yang terkontrol: memungkinkan berbagi informasi bebas dalam satu tim dan berbagi selektif antartim
  • Pembuatan agen persisten: bukan subagen sekali pakai, melainkan anggota tim dengan ID, lingkungan, dan data yang persisten
  • Kebijakan izin terperinci: kontrol rinci seperti hanya mengizinkan membaca email, membatasi akses ke repositori tertentu, atau menetapkan batas pengeluaran
  • Proses persetujuan manusia: tindakan yang tidak dapat dibatalkan dijalankan setelah peninjauan manusia
• NanoClaw diposisikan sebagai lapisan runtime dan orkestrasi yang berfokus pada keamanan, sementara sandbox Docker menjadi fondasi infrastruktur kelas enterprise
• Tujuannya adalah membangun stack eksekusi agen yang secara bersamaan menyediakan isolasi dasar, kolaborasi terkontrol, serta visibilitas dan tata kelola tingkat organisasi

Gambaran umum NanoClaw

• NanoClaw adalah lapisan runtime dan orkestrasi keamanan open source untuk mendukung pengoperasian agen AI berbasis tim
• Proyeknya dapat dilihat di GitHub dan didukung dengan memberikan star

[GN⁺]

Komentar Hacker News

• Ini tampak seperti detail kecil, tetapi beberapa keputusan desain baru bisa membawa perubahan besar jika menyebar ke seluruh industri
  Seperti yang disebut Karpathy, kuncinya adalah menyediakan skill (spec) tentang “cara menulis integrasi”, alih-alih mengimplementasikan langsung integrasi seperti Slack atau Discord
  Ini bisa disebut “Claude native development”, dan ekosistem tampaknya dapat bergeser dari framework “batteries-included” lama ke pendekatan “fork and customize”
  Namun, masih banyak tantangan yang perlu diselesaikan, seperti bagaimana mendistribusikan spec untuk pengujian, verifikasi, dan keamanan
  Saya juga penasaran apakah perubahan seperti ini bisa terjadi di level OS. Jika tiap instance memiliki sistem imun yang kuat, ekosistem yang heterogen mungkin akan lebih tahan terhadap serangan

  • Karena setiap pengguna harus mengulang pekerjaan yang sama, efisiensinya tampak buruk. Menurut saya lebih baik sekali diimplementasikan lalu dibagikan ke semua orang
  • Kekuatan open source ada pada kolaborasi dan proses verifikasi. Sama seperti LLM yang awalnya banyak menghasilkan bug, manusia juga begitu. Saya lebih memilih melakukan kustomisasi di atas fondasi yang sudah tervalidasi
  • Bisa jadi kita akan hidup di dunia tempat fitur diimplementasikan dengan saling bertukar file spec Markdown, bukan kode

• Saat membahas alat keamanan atau sandboxing, kita wajib menjelaskan threat model
  Risikonya adalah agen AI dapat mengeksekusi kode arbitrer di host yang menyimpan data rahasia
  Misalnya, menghapus kotak masuk, membocorkan kalender, atau melakukan transfer yang salah tidak bisa dicegah hanya dengan sandbox
  Jadi selain sandboxing, dibutuhkan juga kontrol izin yang terperinci per tugas dan per alat. Contoh: “permintaan ini hanya boleh membaca Gmail, dan tidak boleh menulis atau menghapus”

  • Sangat setuju. Selain itu, kita juga butuh pelacakan aliran data antartool (IFC) dan pelemahan hak akses (ocap). Misalnya, harus bisa mengekspresikan kebijakan seperti “dilarang mengirim data ke luar thread email asal”
  • Seperti yang dibahas dalam tulisan “Don’t Trust AI Agents”, agen AI harus dirancang dengan asumsi tidak dapat dipercaya. Kita perlu struktur yang meminimalkan dampak dengan mengasumsikan malfungsi atau prompt injection
  • Saya membuat framework agen berfokus pada kontrol kebijakan smith-core dan gateway smith-gateway. Namun, diskusi desain keamanan seperti ini hampir tidak mendapat perhatian dari komunitas
  • Saya melihat tulisan menarik yang menyebutkan di OpenClaw Sandbox bahwa izin itu biner, sedangkan perilaku LLM bersifat probabilistik, jadi kedua konsep ini pada dasarnya berbenturan
  • Sebenarnya, sistem perizinan yang sudah ada seperti IAM, WIF, Macaroons, dan Service Accounts sudah tersedia. Jika bertanya ke tim keamanan, kemungkinan ada solusi yang juga bisa dipakai di perusahaan Anda

• Saya suka NanoClaw. OpenClaw terlalu rumit, sedangkan NanoClaw jauh lebih ringkas
  Ini proyek pertama yang memakai Claude Code sebagai antarmuka konfigurasi, dan menambahkan fitur terasa menyenangkan serta berjalan dengan baik

  • Instance OpenClaw saya baru-baru ini rusak. Update merusak integrasi OpenRouter, dan kodenya terlalu kompleks
    Model keamanannya juga tidak cocok dengan lingkungan Kubernetes rootless saya, jadi selalu menimbulkan masalah
    Karena itu saya pindah ke Nullclaw. Saya juga bisa belajar bahasa Zig sambil debugging, jadi menarik dari sisi pembelajaran
  • Saya penasaran workflow seperti apa yang tidak mudah dibuat hanya dengan Claude di Nanoclaw

• Sandbox Docker mirip dengan framework container milik Apple
  Di macOS, ini cocok sebagai runtime native yang jauh lebih ringan daripada Docker
  Tetapi di Linux, saya tidak ingin memakai hypervisor. Dengan Linux namespace saja, isolasi sudah cukup
  Saya penasaran kenapa OpenClaw atau NanoClaw tidak menyediakan image Docker resmi yang dikonfigurasi dengan benar

  • Di macOS saya memakai Apple Container, dan di OS lain saya memakai Podman
    Ada sedikit bug jaringan pada Container, tetapi tetap sangat berharga. Cukup perbaiki pengaturan DNS
    Saya juga senang karena tidak perlu memasang Claude Code atau Node.js di host

• Yang lebih penting daripada soal kontainer adalah apa yang ingin dilakukan
  Sampai kita menemukan cara memakai token untuk tugas yang benar-benar berguna, runtime itu sekunder
  Dari sisi keamanan, memasukkan LLM ke dalam kontainer saja tidak cukup. Yang penting adalah cakupan informasi yang bisa diakses
  Jika agen dapat mengakses semua data, itulah risiko yang sebenarnya

  • Sandbox Docker memakai MicroVM sebagai lapisan isolasi tambahan. Jadi ini bukan sekadar kontainer biasa

• Kuncinya adalah izin yang detail dan kontrol kebijakan
  Bukan hanya alat apa yang bisa dipakai, tetapi juga apa yang boleh dilakukan
  Contoh: hanya boleh membaca email, hanya boleh mengakses repositori tertentu, menetapkan batas pengeluaran, dan sebagainya
  Menyerahkan aset sensitif seperti akun messaging ke LLM terasa tidak aman jika hanya mengandalkan sandboxing Docker

• Sandbox Docker menjalankan MicroVM dan daemon Docker khusus untuk setiap agen, lalu menggabungkannya dengan proxy egress yang fleksibel
  Saya sempat melakukan reverse engineering, dan implementasinya cukup menarik

• NanoClaw bukan produk jadi yang bisa langsung dipakai
  Anda harus menambahkan sendiri fitur seperti iMessage melalui coding agent
  Dengan kata lain, Claude bertindak seperti compiler

  • Dulu ada masa ketika orang memeriksa langsung assembly yang dihasilkan compiler
    Coding agent masih di level seperti itu. Klaim belakangan ini bahwa “coding agent sudah jauh lebih baik” terasa berlebihan
    Kita masih harus berulang kali memberi instruksi ke Claude seperti “itu belum selesai, coba lagi”

• Saya sedang mengerjakan ide yang mirip dengan “claws”
  Alih-alih integrasi aplikasi messaging, pendekatannya adalah menyediakan TUI terenkripsi end-to-end
  Lihat wingthing.ai / repositori GitHub
  Saya juga sedang memikirkan cara mendukung Docker, jadi saya akan melihat proyek ini

• Saya penasaran dengan use case Nano/Open-Claw yang jelas. Apakah ini semacam sistem yang mengelola kehidupan digital saya?

  • Sebenarnya sederhana. Ini semacam cron job LLM, atau chat connector seperti Telegram dan email. Yang pertama bisa dilakukan dengan cron biasa, dan yang kedua juga bisa dengan kode manual atau Gemini Gems
  • Ini berguna untuk mengotomatisasi pekerjaan pengetahuan yang berulang, seperti ringkasan email, pengingat jadwal, dan dokumen briefing
  • Bisa juga dihubungkan ke aplikasi to-do lalu dikelola bot lewat pesan. Ini membantu meningkatkan produktivitas
  • Saya memakai NanoClaw sebagai pelatih diet dan olahraga. Ia menangani pengelolaan target, perencanaan menu, daftar belanja, sampai catatan latihan
    Saya memindahkannya ke Apple Container, dan juga menambahkan fitur memori jangka panjang berbasis LanceDB. Sekarang saya tidak perlu mengulang hal yang sama terus-menerus