Docker sandbox में NanoClaw चलाना

• NanoClaw और Docker के सहयोग से अब हर AI agent को isolated Docker sandbox में एक-लाइन कमांड से चलाया जा सकता है
• हर agent micro VM के भीतर एक स्वतंत्र container में चलता है, और host system तक पहुंच के बिना पूरी तरह isolated environment पाता है
• डुअल security boundary structure के जरिए container escape होने पर भी VM स्तर पर उसे रोका जाता है, जिससे host files, credentials और applications सुरक्षित रहते हैं
• NanoClaw का security model ‘अविश्वास को आधार मानकर किया गया design’ है, जिसमें agents को संभावित malicious actor मानकर नुकसान कम करने वाली संरचना अपनाई गई है
• आगे चलकर context sharing control, persistent agents, granular permission policies, human approval workflows जैसी क्षमताओं का विस्तार कर बड़े agent teams के संचालन को लक्ष्य बनाया गया है

---

Docker sandbox integration overview

• NanoClaw, Docker के सहयोग से एक-लाइन कमांड में sandbox execution को support करता है
  • macOS (Apple Silicon) और Windows (WSL) पर support उपलब्ध है, Linux support जल्द जोड़ा जाएगा
  • install script clone, setup और sandbox configuration को अपने-आप संभालती है
• हर agent micro VM के भीतर एक स्वतंत्र container में चलता है
  • अलग hardware या complex setup की ज़रूरत नहीं होती
  • हर container का अपना kernel और Docker daemon होता है, और host access ब्लॉक रहता है

यह कैसे काम करता है

• Docker sandbox hypervisor-level isolation देता है, साथ ही milliseconds स्तर की तेज startup speed प्रदान करता है
• NanoClaw इस संरचना पर स्वाभाविक रूप से map होता है
  • हर agent के पास स्वतंत्र filesystem, context, tools और session होते हैं
  • उदाहरण: sales agent private messages तक पहुंच नहीं सकता, और support agent CRM data तक नहीं पहुंच सकता
• micro VM layer दूसरी security boundary बनाती है
  • container escape होने पर भी VM की दीवार host system की रक्षा करती है

Security model: अविश्वास-आधारित design

• NanoClaw को इस आधार पर design किया गया है कि AI agents पर भरोसा नहीं किया जा सकता
  • इसमें prompt injection, model malfunction जैसे अप्रत्याशित जोखिमों को ध्यान में रखा गया है
  • agent environment में secrets या credentials न रखने के लिए इसे उसी हिसाब से design किया गया है
• security को agent के बाहर से enforce किया जाता है, यह सही behavior पर निर्भर नहीं करती
• OpenClaw के विपरीत, NanoClaw agents के बीच पूर्ण isolation देता है
  • OpenClaw में एक ही environment साझा होता है, जिससे personal और work data मिल सकते हैं
• यह security engineering principle पर ज़ोर देता है कि agents सहयोगी भी हैं और संभावित attacker भी

आगे की दिशा

• बड़े agent teams को चलाने के लिए नए infrastructure और runtime layer की ज़रूरत बताई गई है
• NanoClaw पहले से कई Slack channels से जुड़कर काम के आधार पर स्वतंत्र agents चला सकता है
• अगले चरण के लिए बताई गई चार मुख्य क्षमताएं
  • Controlled context sharing: team के भीतर स्वतंत्र information sharing और teams के बीच selective sharing
  • Persistent agent creation: एकबारगी sub-agents के बजाय स्थायी ID, environment और data वाले team members जैसे agents
  • Granular permission policies: सिर्फ email पढ़ने की अनुमति, खास repositories तक सीमित access, spending limits जैसी बारीक control
  • Human approval workflow: irreversible actions को मानव समीक्षा के बाद चलाना
• NanoClaw को security-first runtime और orchestration layer के रूप में, और Docker sandbox को enterprise-grade infrastructure foundation के रूप में पेश किया गया है
• लक्ष्य है ऐसा agent execution stack बनाना जो default isolation, controlled collaboration, और organization-level visibility व governance एक साथ दे

NanoClaw overview

• NanoClaw एक open source security runtime और orchestration layer है, जो team-level AI agent operations को support करता है
• GitHub पर project देखा जा सकता है और star देकर समर्थन किया जा सकता है

[GN⁺]

Hacker News की टिप्पणियाँ

• यह छोटी-सी डिटेल लग सकती है, लेकिन अगर कुछ नए design decisions पूरे उद्योग में फैलें, तो इससे क्रांतिकारी बदलाव आ सकता है
  Karpathy ने जैसा कहा, Slack·Discord जैसे integrations को सीधे implement करने के बजाय “integration कैसे लिखना है” इसके लिए skill (spec) देना ही मुख्य बात है
  इसे “Claude native development” कहा जा सकता है, और लगता है कि ecosystem मौजूदा “batteries-included” framework की जगह “fork and customize” मॉडल की ओर बढ़ेगा
  हालांकि test·verification·security जैसे specs को कैसे distribute किया जाए, यह अभी भी एक बड़ा unresolved challenge है
  यह भी जिज्ञासा है कि क्या OS स्तर पर भी ऐसा बदलाव हो सकता है। अगर हर instance की अपनी मजबूत immune system हो, तो यह हमलों के प्रति अधिक resilient heterogeneous ecosystem बन सकता है

  • हर user को वही काम बार-बार करना पड़ेगा, इसलिए efficiency घट सकती है। मुझे लगता है कि एक बार implement करके सबके साथ share करना बेहतर है
  • open source की ताकत collaboration और verification process में है। जैसे LLM शुरुआत में बहुत bugs बनाते हैं, इंसान भी वैसा ही करते हैं। मेरी नज़र में validated base पर customize करना बेहतर है
  • हो सकता है हम ऐसे दौर में पहुँचें जहाँ code की बजाय Markdown spec files देकर features implement किए जाएँ

• security tools या sandboxing की बात करते समय threat model को साफ़-साफ़ बताना ज़रूरी है
  यह जोखिम भरा है कि AI agent secret data वाले host पर arbitrary code चला सकता है
  उदाहरण के लिए, mailbox delete होना, calendar leak होना, या गलत पैसे transfer होना—ये सिर्फ sandbox से नहीं रुकेंगे
  इसलिए sandboxing के अलावा task-wise और tool-wise granular permission control भी चाहिए। जैसे: “यह request सिर्फ Gmail read कर सकती है, write·delete नहीं”

  • पूरी तरह सहमत। इसके साथ tools के बीच data flow tracking (IFC) और authority attenuation (ocap) भी चाहिए। उदाहरण के लिए “मूल mail thread के बाहर data भेजना मना है” जैसी policies express होनी चाहिए
  • “Don’t Trust AI Agents” पोस्ट में जैसा कहा गया, AI agents को default distrust मानकर design करना चाहिए। malfunction या prompt injection को मानकर damage को minimum करने वाली structure चाहिए
  • मैंने policy-control केंद्रित agent framework smith-core और gateway smith-gateway बनाया है। लेकिन ऐसी security design discussions पर community में लगभग ध्यान ही नहीं दिया जाता
  • मैंने एक दिलचस्प लेख देखा था; OpenClaw Sandbox में कहा गया है कि permissions binary होते हैं, लेकिन LLM का behavior probabilistic होता है, इसलिए दोनों concepts मूल रूप से टकराते हैं
  • असल में IAM, WIF, Macaroons, Service Accounts जैसे मौजूदा permission systems पहले से मौजूद हैं। security team से पूछें तो कंपनी के भीतर भी उपयोगी solutions मिल सकते हैं

• NanoClaw पसंद आया। OpenClaw बहुत complex था, लेकिन NanoClaw कहीं ज़्यादा concise है
  यह पहला project है जहाँ Claude Code को configuration interface की तरह इस्तेमाल किया गया है, और feature जोड़ना भी मज़ेदार है तथा यह अच्छी तरह काम करता है

  • मेरा OpenClaw instance हाल ही में टूट गया। update ने OpenRouter integration खराब कर दिया, और code ज़रूरत से ज़्यादा complex है
    security model भी मेरे rootless Kubernetes environment से मेल नहीं खाता, इसलिए हर बार समस्या आती है
    इसलिए मैं Nullclaw पर चला गया। Zig सीखते हुए debug कर सकता हूँ, इसलिए learning के लिहाज़ से भी यह दिलचस्प है
  • जिज्ञासा है कि NanoClaw में Claude के साथ कौन-से ऐसे workflows हैं जिन्हें आसानी से बनाना मुश्किल है

• Docker sandbox, Apple के container framework जैसा है
  macOS पर यह Docker की तुलना में कहीं ज़्यादा हल्का native runtime लगता है
  लेकिन Linux पर मैं hypervisor इस्तेमाल नहीं करना चाहता। सिर्फ Linux namespace से भी पर्याप्त isolation मिल सकती है
  समझ नहीं आता कि OpenClaw या NanoClaw ठीक से configured official Docker image क्यों नहीं देते

  • मैं macOS पर Apple Container और बाकी OS पर Podman इस्तेमाल करता हूँ
    Container में थोड़ा network bug है, लेकिन फिर भी यह काफ़ी worthwhile है। सिर्फ DNS setting ठीक करनी पड़ती है
    Claude Code या Node.js को host पर install नहीं करना पड़ता, यह बात मुझे पसंद है

• container है या नहीं, उससे ज़्यादा अहम बात यह है कि आप करना क्या चाहते हैं
  जब तक tokens को किसी उपयोगी काम में लगाने का तरीका नहीं मिलता, runtime secondary है
  security के नज़रिए से सिर्फ LLM को container में डाल देना काफ़ी नहीं है। असली बात है किस जानकारी तक उसकी पहुँच है
  अगर agent को सारे data की access है, वही असली जोखिम है

  • Docker sandbox में MicroVM को अतिरिक्त isolation layer की तरह इस्तेमाल किया जाता है। यह सिर्फ साधारण container नहीं है

• बारीक permissions और policy control ही मुख्य बात है
  सवाल सिर्फ यह नहीं कि कौन-सा tool इस्तेमाल किया जा सकता है, बल्कि यह भी कि क्या किया जा सकता है
  उदाहरण: सिर्फ email पढ़ना, केवल खास repository तक पहुँचना, spending limit तय करना आदि
  सिर्फ Docker sandboxing के भरोसे messaging account जैसे sensitive assets LLM को सौंपना अभी भी असहज लगता है

• Docker sandbox हर agent के लिए dedicated MicroVM और Docker daemon चलाता है, और साथ में flexible egress proxy भी सेट करता है
  मैंने इसे reverse engineer किया था; implementation काफ़ी दिलचस्प है

• NanoClaw कोई ready-to-use finished product नहीं है
  coding agent के ज़रिए iMessage जैसी functionalities आपको खुद जोड़नी होंगी
  यानी एक तरह से Claude compiler की भूमिका निभा रहा है

  • पहले ऐसा समय था जब compiler द्वारा बनाई गई assembly को लोग खुद देख लेते थे
    coding agents अभी भी कुछ उसी स्तर पर हैं। हाल की यह बात कि “coding agents बहुत बेहतर हो गए हैं”, कुछ बढ़ा-चढ़ाकर कही गई लगती है
    अब भी Claude से बार-बार कहना पड़ता है, “यह अभी हल नहीं हुआ, फिर से करो”

• मैं “claws” जैसे एक मिलते-जुलते idea पर काम कर रहा हूँ
  messaging app integration की बजाय end-to-end encrypted TUI देने का तरीका है
  wingthing.ai / GitHub repository देखें
  मैं Docker support के approach पर सोच रहा हूँ, इसलिए इस project को भी देखने वाला हूँ

• Nano/Open-Claw का साफ़ use case क्या है, यह जानना चाहता हूँ। क्या यह मेरी digital life को मेरी जगह manage करता है?

  • असल में यह काफ़ी simple है। या तो LLM cronjob है, या Telegram·email जैसे chat connectors हैं। पहला सामान्य cron से, और दूसरा manual code या Gemini Gems से भी किया जा सकता है
  • email summary, schedule reminders, briefing documents जैसी repetitive knowledge work को automate करने में यह उपयोगी है
  • इसे to-do app से जोड़कर bot के ज़रिए message से manage कराया जा सकता है। इससे productivity बढ़ती है
  • मैं NanoClaw को diet·workout coach की तरह इस्तेमाल करता हूँ। यह goal tracking, meal planning, grocery list और workout log तक संभालता है
    मैंने इसे Apple Container पर migrate किया और LanceDB आधारित long-term memory feature भी जोड़ा। अब वही बात बार-बार दोहरानी नहीं पड़ती