jai - AI एजेंट्स के लिए आसान isolation टूल

 (jai.scs.stanford.edu)
3 पॉइंट द्वारा GN⁺ 2026-03-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux वातावरण में AI एजेंट्स को isolated execution में चलाने वाला हल्का टूल, जो जटिल container सेटअप के बिना एक ही कमांड से सुरक्षित execution boundary देता है
  • AI टूल्स के वास्तविक file system तक पहुँचकर डेटा मिटाने या नुकसान पहुँचाने की घटनाएँ लगातार सामने आने से, सुरक्षित execution environment की ज़रूरत उभरकर सामने आई है
  • home directory को copy-on-write overlay से सुरक्षित रखता है और /tmp·/var/tmp को अलग करके मूल फ़ाइलों में बदलाव रोकता है
  • Casual·Strict·Bare तीन isolation modes देता है, जिससे सुरक्षा स्तर और access scope चुना जा सकता है
  • Stanford की research team द्वारा विकसित open source project, जो AI टूल्स को अधिक सुरक्षित तरीके से इस्तेमाल करने के लिए व्यावहारिक सुरक्षा उपाय देता है

AI एजेंट isolation के लिए हल्का टूल jai

  • jai Linux वातावरण में AI एजेंट्स को आसानी से containment में रखने के लिए बनाया गया टूल है
    • जटिल container या VM सेटअप के बिना, एक ही कमांड से सुरक्षित execution boundary देता है
    • coding assistance या script execution जैसे मौजूदा workflow में तुरंत लागू किया जा सकता है

  • वास्तविक समस्या के उदाहरण

    • कई users ने AI टूल्स का उपयोग करते समय फ़ाइल नुकसान और directory deletion की घटनाएँ रिपोर्ट की हैं
      • Nick Davidov ने बताया कि 15 साल की पारिवारिक तस्वीरें terminal command से हट गईं
      • Anthropic का Claude Code home directory हटाने के कारण development projects खो बैठा
      • Cursor ने work tree खाली कर दिया, और रिपोर्ट के अनुसार “सब कुछ गायब हो गया”
      • एक Reddit user ने कहा कि Antigravity ने पूरा D drive हटा दिया
      • एक अन्य Cursor user ने 100GB फ़ाइलें हट जाने की रिपोर्ट की
    • ये घटनाएँ दिखाती हैं कि AI टूल्स को वास्तविक account access देने पर security gap पैदा होता है

  • jai की मुख्य विशेषताएँ

    • execution account और home directory के बीच boundary अपने-आप सेट करता है
      • working directory पर पूरा read/write access बना रहता है
      • home directory को copy-on-write overlay से सुरक्षित रखा जाता है, इसलिए मूल फ़ाइलें नहीं बदलतीं
      • /tmp और /var/tmp को अलग स्वतंत्र space में रखा जाता है, बाकी फ़ाइलों को read-only तक सीमित किया जाता है
    • कमांड के आगे सिर्फ jai लगाने से isolated execution संभव है
      • उदाहरण: jai codex, jai claude, या सिर्फ jai से shell चलाना
    • Dockerfile या image build process के बिना तुरंत इस्तेमाल किया जा सकता है
      • जटिल bwrap flags सेट करने या script लिखने की ज़रूरत नहीं

  • isolation mode का चयन

    • Casual / Strict / Bare तीन modes उपलब्ध हैं
      • Casual: home directory को copy-on-write से सुरक्षित रखता है, अधिकांश फ़ाइलें पढ़ी जा सकती हैं
      • Strict: अलग jai user के रूप में चलता है, खाली home directory के साथ मज़बूत isolation देता है
      • Bare: home directory खाली रहता है, लेकिन user UID वही रहता है
    • हर mode में confidentiality, integrity, और NFS support अलग है
      • Strict mode सबसे मज़बूत isolation देता है, लेकिन NFS home को support नहीं करता

  • वैकल्पिक टूल्स से तुलना

    • Docker
      • image-आधारित environment reproduction के लिए उपयुक्त है, लेकिन host tools के अस्थायी sandboxing के लिए भारी है
      • home directory overlay सुविधा नहीं है
    • bubblewrap
      • शक्तिशाली namespace sandbox है, लेकिन file system configuration खुद तय करनी पड़ती है
      • jai इस जटिलता को हटाता है
    • chroot
      • यह security isolation का साधन नहीं है, और mount·PID namespace·privilege separation जैसी सुविधाएँ न होने के कारण Linux में भी sandboxing के लिए अनुशंसित नहीं है

  • सुरक्षा सीमाएँ

    • jai पूर्ण सुरक्षा की गारंटी नहीं देता
      • “casual sandbox” के रूप में यह नुकसान की सीमा घटाता है, लेकिन हर हमले को नहीं रोकता
      • Casual mode में confidentiality protection कमज़ोर है, और Strict mode भी container या VM स्तर के isolation जैसा नहीं है
      • multi-tenant environment या high-risk स्थितियों में container या virtual machine के उपयोग की सिफारिश की जाती है

  • प्रोजेक्ट पृष्ठभूमि

    • Stanford Secure Computer Systems(SCS) research group और Future of Digital Currency Initiative(FDCI) ने मिलकर इसे विकसित किया
    • यह मुफ़्त open source software के रूप में उपलब्ध है और users को AI का और सुरक्षित उपयोग करने में मदद करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-29
Hacker News की राय

  • .claude/settings.json में नीचे दिया गया सेटिंग जोड़ना होगा

    {
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["."],
      "denyRead": ["~/"],
      "allowWrite": ["."],
      "denyWrite": ["/"]
    }
  }
}

    बाहरी डायरेक्टरी एक्सेस की अनुमति देनी हो तो allowRead हिस्से को बदलना होगा
    यह फीचर 10 दिन पहले जोड़ा गया नया sandbox विकल्प है

    • देखा गया है कि claude कभी-कभी current directory को लेकर भ्रमित हो जाता है या rm -rf * जैसे कमांड चला देता है
      शुक्र है कि दोनों चीज़ें एक साथ नहीं हुईं, लेकिन सिर्फ कल्पना से ही डर लगता है
      sandbox का विचार अच्छा है, लेकिन असरदार होने के लिए इसे low level पर enforce होना चाहिए
      claude खुद AI द्वारा बनाया गया एक बहुत बड़ा प्रोग्राम है, इसलिए इंसानों द्वारा सीधे लिखी गई 3000 लाइनों से कम की security layer जोड़ना एक सार्थक defense हो सकता है
    • claude-code के भविष्य के version इस setting name को चुपचाप बदल या हटा भी सकते हैं
      इसलिए लोग अलग sandboxing software को पसंद कर सकते हैं
    • GPU इस्तेमाल करने देना लेकिन / delete होने से रोकने वाला मज़ाकिया config example भी साझा किया गया
      /dev/nvidia* device access की अनुमति देने वाली configuration है, यानी data leak का जोखिम स्वीकार करने वाली व्यंग्यात्मक setting
    • दशकों से परखे गए मौजूदा security tools पहले से मौजूद हैं
      claude को सीमित permissions वाले user के रूप में चलाने पर isolation अपने आप child process तक inherit हो जाता है
    • Linux(Arch) और macOS(Tahoe) पर sandbox फीचर सही से काम नहीं कर रहा था
      संबंधित issue खुला हुआ है
      bubblewrap और seatbelt अपने आप में ठीक काम करते हैं, लेकिन claude-code के जरिए चलाने पर वे disabled जैसे लगते हैं

  • यह देखकर हैरानी होती है कि लोग इतनी आसानी से AI agents को अपने personal computer पर install कर रहे हैं
    दशकों तक system security की रक्षा की गई, और अब अचानक unpredictable software को सारी permissions दे दी गई हैं

    • पहले भी build tools अपने आप dependencies खींच लाते थे और warnings को नज़रअंदाज़ किया जाता था, और अब supply chain attacks बार-बार हो रहे हैं
      अल्पकालिक सुविधा को दीर्घकालिक security पर प्राथमिकता दी जा रही है
    • असल में ऐसा जोखिम उठाने वाले लोग और security को प्राथमिकता देने वाले लोग दो अलग समूह हैं
    • कंपनी के environment में access पहले से सीमित होता है, इसलिए यह personal PC पर ज़्यादा संवेदनशील मुद्दा है
      मेरे remote development VM में केवल वही data है जिसे Claude देख ले तो भी कोई दिक्कत नहीं
    • Docker के शुरुआती दिनों में भी माहौल यही था कि “बस image download कर लो!”
      लेकिन industry ने जल्दी ही security risk को समझ लिया और प्रतिक्रिया दी

  • साधारण Unix permission separation भी काफी है
    दो user account रखें, और सिर्फ वही folder group में बाँधें जिन्हें AI के साथ share करना है
    संबंधित ब्लॉग पोस्ट देखें

  • homepage पर लिखा है “अंधविश्वास बंद करो”, लेकिन install method curl | bash की जगह manual build है

    • tar file को सीधे extract करके makepkg -i से install करना कहीं ज़्यादा सुरक्षित है
      PKGFILE लगभग 30 lines का छोटा है, और build function भी सिर्फ 7 lines का है
      इसके मुकाबले rustup(910 lines), claude(158 lines), opencode(460 lines) जैसी scripts कहीं अधिक जटिल हैं
    • इसके उलट curl | tar | makepkg को एक ही line में जोड़ना अविश्वसनीय तरीका है

  • यह project अच्छी तरह design किया गया है, और मेरे तरीके से थोड़ा अधिक सुरक्षित और सुविधाजनक लगता है
    मैं agent को isolate करने के लिए अलग user account बनाता हूँ
    लेकिन कभी-कभी permissions उलझ जाती हैं, इसलिए उन्हें script से ठीक करता हूँ
    आखिरकार सबसे पक्का तरीका है इसे पूरी तरह अलग laptop दे देना
    physical रूप से अलग machine जितनी सुरक्षित कोई चीज़ नहीं

    • लेकिन बाहरी services से बात करने के लिए API keys देनी पड़ती हैं, इसलिए उनके leak होने का जोखिम रहता है
      agent में security penetration testing जैसी क्षमता होती है, इसलिए सिर्फ user separation से पूरी तसल्ली नहीं होती
    • मैं भी फिलहाल user separation वाला तरीका ही इस्तेमाल कर रहा हूँ
      container इस्तेमाल करने पर agent खुद container बनाने की कोशिश में भ्रमित हो जाता है

  • साइट “vibe-coded” लगती है, इसलिए quality कमज़ोर दिखती है, लेकिन असली tool को Stanford के professor ने खुद implement किया है
    FAQ link देखें

    • लेखक होने के नाते मैं खुद कहूँ तो, web design में अच्छा नहीं हूँ लेकिन operating systems expert हूँ
      documentation की सामग्री मैंने ठीक से सुधार दी है, इसलिए उस पर भरोसा किया जा सकता है
      साइट को AI के बनाए रूप में ही छोड़ देना कुछ हद तक विडंबनापूर्ण है
    • लेखक David Mazieres हैं, जो 2000 के शुरुआती वर्षों से user-level filesystem research करते आए हैं
      वे Stanford Secure Computer Systems group का नेतृत्व करते हैं
    • jai एक high-risk tool है, लेकिन website साधारण है, इसलिए उसका vibe-coded होना ठीक है
    • फिर भी व्यक्तिगत रूप से मुझे संक्षिप्त HTML page ज़्यादा बेहतर लगता है

  • अगर agent को project directory में write permission मिल जाए तो persistent exploit संभव हो सकता है, यह चिंता की बात है
    .pyc, .venv, .git/hooks जैसी files के जरिए sandbox के बाहर execution हो सकता है
    ChatGPT conversation में भी ऐसी कमजोरी की पुष्टि हुई
    इसलिए सबसे सुरक्षित तरीका git patch आधारित file transfer है
    sandbox में बदली गई files में से केवल git में committed items को बाहर export किया जाना चाहिए

    • .git/ directory को read-only बनाने का option जोड़ना अच्छा होगा
      jai -D से CWD को overlay बनाया जा सकता है, लेकिन changes merge करना मुश्किल हो जाता है
    • मैं तो code को पूरी तरह sandbox (VM स्तर) के अंदर ही run करता हूँ
      agent अलग git worktree branch में काम करता है, और review के बाद ही merge किया जाता है
      इससे review-आधारित security flow बनाए रखा जा सकता है
    • git hook को कभी अनुमति नहीं देनी चाहिए

  • एक आसान विकल्प के रूप में agent को अलग user account से ssh पर चलाया जाता है
    project directory को bind mount करके access नियंत्रित किया जाता है
    यह VSCode की ssh remote सुविधा के साथ अच्छी तरह काम करता है

    • मैं भी 6 महीनों से dedicated account इस्तेमाल कर रहा हूँ, और बस accessible directories को manage करना होता है
      यह जटिल security systems की तुलना में कहीं अधिक सरल और प्रभावी isolation तरीका है

  • असल में rm -rf से भी अधिक सूक्ष्म समस्याएँ होती हैं
    claude-code ने SVG save करने के लिए /public/blog/ folder बना दिया, जिससे Apache routing टूट गई थी
    यह deletion या permission की समस्या नहीं थी, लेकिन अनचाहे व्यवहार के कारण blog ने 404 देना शुरू कर दिया
    jai ऐसी बड़ी गलतियों को रोक सकता है, लेकिन इस तरह की बारीक समस्याएँ अब भी कठिन हैं

  • शानदार project है, लेकिन शीर्षक थोड़ा कमज़ोर है
    current directory पर पूरा access, बाकी सब पर read-only, और home directory को copy-on-write के रूप में संभालने वाली यह संरचना मुझे पसंद आई
    ऐसा approach AI agents का default security model होना चाहिए

    • साइट पर शीर्षक नहीं है, इसलिए “jai - filesystem containment for AI agents” जैसा नाम अधिक उपयुक्त लग सकता है