Agent Safehouse – macOS के लिए लोकल एजेंट सैंडबॉक्सिंग टूल

 (agent-safehouse.dev)
16 पॉइंट द्वारा GN⁺ 2026-03-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS native sandbox के ज़रिए लोकल AI एजेंट्स को isolate करने वाला टूल, ताकि वे सिस्टम के बाहर बदलाव न कर सकें
  • सभी एजेंट स्वतंत्र sandbox environments में चलते हैं, इसलिए वे user home directory या दूसरे projects तक नहीं पहुंच सकते
  • Deny-first access model लागू करता है, जिससे केवल स्पष्ट रूप से अनुमति दी गई directories में ही read/write संभव है
  • इंस्टॉलेशन एक ही Bash script से पूरा हो जाता है, और बिना अलग build या dependencies के तुरंत चलाया जा सकता है
  • LLM-आधारित profile generation फीचर के ज़रिए least-privilege sandbox-exec configuration को automate किया जा सकता है

अवलोकन

  • Agent Safehouse एक macOS-विशेष sandboxing system है, जो लोकल में चलने वाले AI agents को system files खराब करने से बचाता है
    • “Go full --yolo. We've got you.” “Move fast, break nothing”
    • LLM की probabilistic प्रकृति से होने वाले अनपेक्षित command execution के जोखिम को रोकता है
  • सभी प्रमुख agents sandbox के भीतर पूरी तरह काम करते हैं और बाहरी सिस्टम पर असर नहीं डालते
  • यह Deny-first access model अपनाता है, जिसमें default रूप से हर access block रहता है और केवल explicitly allowed paths ही accessible होते हैं
    • उदाहरण: ~/my-project में read/write की अनुमति, जबकि ~/.ssh, ~/.aws, ~/other-repos पर access deny

इंस्टॉलेशन और रन

  • इंस्टॉलेशन एक single shell script download से पूरा होता है
    • curl command से script लेकर उसे ~/.local/bin/safehouse में save किया जाता है और execute permission दी जाती है
  • इसके बाद safehouse command से मनचाहा agent चलाया जा सकता है
    • उदाहरण: safehouse claude --dangerously-skip-permissions
  • Safehouse default रूप से current working directory (git root) को read/write permission देता है, और toolchain directories को read-only access देता है

sandbox verification के उदाहरण

  • sensitive files तक पहुंचने पर kernel level पर block हो जाता है
    • safehouse cat ~/.ssh/id_ed25519 चलाने पर “Operation not permitted” error मिलता है
    • दूसरी project directory (~/other-project) दिखाई नहीं देती
    • current project directory सामान्य रूप से accessible रहती है

automation और profile generation

  • shell function जोड़कर सभी agents को default रूप से Safehouse के भीतर चलाया जा सकता है
    • उदाहरण: .zshrc या .bashrc में safe() function define करके claude, codex, amp, gemini commands को अपने-आप sandbox किया जा सकता है
    • sandbox के बिना चलाने के लिए command claude जैसे रूप में call करें
  • LLM-आधारित profile generation फीचर उपलब्ध है
    • Claude, Codex, Gemini जैसे models Safehouse templates का analysis करके least-privilege sandbox-exec profile बनाते हैं
    • home directory और toolchain जानकारी के आधार पर इसे ~/.config/sandbox-exec.profile path में save किया जाता है
    • इसमें current working directory के access permissions और agent-specific shortcut commands शामिल होते हैं

सुरक्षा और उपयोग का महत्व

  • LLM-आधारित लोकल agents को अनजाने में files delete करने या system changes करने से रोकता है
  • macOS kernel-level access control का उपयोग करके default रूप से सुरक्षित execution environment देता है
  • single-script आधार पर इसे developer workflow में आसानी से integrate किया जा सकता है

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

1 टिप्पणियां

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

  • मुझे नहीं लगा था कि मेरा बनाया प्रोजेक्ट इतनी जल्दी सार्वजनिक हो जाएगा
    1️⃣ मैं ऐसे agents को पसंद करता हूँ जो सीधे local पर चलें। container या remote server के बजाय, अपनी बारीकी से सेट की हुई अपनी machine पर उनका चलना मुझे ज़्यादा भरोसेमंद लगता है
    2️⃣ यह असल में sandbox-exec के लिए एक policy generator है। इसमें कोई dependency नहीं है, न ही virtualization। इसके बजाय, मैंने यह पता लगाने में बहुत समय लगाया कि हर agent को auto update, keychain integration, image paste जैसी चीज़ों के लिए न्यूनतम कौन-सी permissions चाहिए। इससे जुड़ी जाँच agent-safehouse.dev/docs/agent-investigations में संकलित है
    3️⃣ पूरे प्रोजेक्ट का इस्तेमाल करना भी ज़रूरी नहीं है। सिर्फ Policy Builder से भी sandbox-exec policy बनाकर उसे dotfiles में रखकर इस्तेमाल किया जा सकता है

    • पहले से इसे सार्वजनिक कर देने के लिए माफ़ी। मैंने आपका पुराना comment देखकर इसे आज़माया था, और यह इतना असरदार लगा कि इस पर पोस्ट लिखना ठीक लगा
      पहले भी sandbox policy के docs देखे थे, लेकिन तुरंत इस्तेमाल करने लायक app के रूप में यह पहली बार देखा
      हालांकि कुछ असुविधाएँ थीं — home directory में .gitconfig, .gitignore तक पहुँच सीमित हो जाती है, और process access restrictions की वजह से Claude से lldb या pkill जैसे commands नहीं चलवाए जा सकते। अगर fine-grained permission control हो तो अच्छा होगा
    • सोच रहा हूँ कि क्या इसे openclaw पर लागू किया जा सकता है। local machine पर accessible रूप में चलाना सुविधाजनक है, लेकिन साथ ही उसे नियंत्रित करना मुश्किल भी हो जाता है
    • जानना चाहता हूँ कि local execution और container execution में व्यावहारिक अंतर क्या है
    • ओह, मैं यही ढूँढ़ रहा था। microsandbox को ठीक से फिट करने की कोशिश कर रहा था, लेकिन यह उससे कहीं ज़्यादा व्यावहारिक लगता है
      site और scripts देखे, कोई खास समस्या नज़र नहीं आई। क्या कोई ऐसी सावधानियाँ हैं जो docs में नहीं लिखी गईं?
    • विडंबना यह है कि मैं AI पर भरोसा नहीं करता, इसलिए ऐसे प्रोजेक्ट्स में दिलचस्पी रखता हूँ, लेकिन इसे install करने के लिए किसी मनमाने server से .sh file डाउनलोड कर चलानी पड़े, यह थोड़ा मज़ेदार है
      अच्छा होता अगर इसे tarball के रूप में दिया जाता। tarball में अंदर की चीज़ें खुद देखी जा सकती हैं, और यह भी verify किया जा सकता है कि वह CI से automatically generate हुआ है या नहीं, इसलिए उस पर ज़्यादा भरोसा किया जा सकता है

  • ऐसा प्रोजेक्ट देखकर अच्छा लगा, और मुझे लगता है कि इस समय sandboxing सबसे बड़ी चुनौती है
    शुरुआती users बिना सोचे local पर agents चलाएँगे, लेकिन लंबे समय में या enterprise environment में यह बिल्कुल नहीं चलेगा
    सिर्फ network, file और execution permissions को नियंत्रित करना काफी नहीं है; browser testing या cloud resources बनाना जैसे जटिल scenarios भी संभालने होंगे
    आखिरकार security, cost और permission control को जोड़ने वाला व्यावहारिक approach चाहिए

    • लेकिन क्या यह मूल रूप से हल न हो सकने वाली समस्या भी हो सकती है? functionality और safety हमेशा टकराते हैं, और लोग आखिर में पहले वाले को चुन लेते हैं
    • file-level sandboxing तो बुनियादी बात है, असली मुश्किल credentials और network control है
      मैं एक local daemon इस्तेमाल करता हूँ जो short-lived JWT जारी करता है ताकि agent को सीधे keys संभालनी न पड़ें। API access के लिए यह ठीक काम करता है, लेकिन file system स्तर पर अब भी कोई EC2 instances अनंत संख्या में खड़े कर सकता है

  • समस्या यह है कि कई sandboxes का तुलनात्मक मूल्यांकन करना कठिन है
    यह sandbox-exec का एक wrapper लगता है, और आजकल ऐसे wrappers बहुत आ रहे हैं
    असल ज़रूरत reliability verification docs और automated tests की है। ज़्यादातर sandboxes में documentation की कमी है
    भरोसा करने के लिए विस्तार से docs और काम करने के सबूत चाहिए

    • इसी वजह से मैंने इसे Bash में बनाया — opaque binaries से बचने के लिए
      हर agent के लिए sandbox-exec profiles GitHub profile folder में अलग रखे गए हैं, और उन्हें आसानी से review किया जा सकता है
      असली agents के साथ E2E tests भी चल रहे हैं
      Safehouse wrapper के बिना भी Policy Builder से सीधे न्यूनतम permission policies बनाई जा सकती हैं
      साथ ही, LLM से sandbox profile लिखवाने के लिए एक instruction file भी दिया गया है

  • यह sandbox-exec की एक wrapper script है। इसमें पहले से अच्छी तरह तैयार किए गए कई presets हैं, जो बढ़िया हैं
    sandbox-exec का 90% सही scope सेट करने में जाता है, और बाकी 90% उसे समझने में
    लेकिन अच्छा होता अगर overlay या copy-on-write तरीके से sandboxing की जा सकती। मुझे अपनी .bashrc नहीं, सिर्फ एक temporary environment modify होना काफी है

    • Bash इस्तेमाल करने की वजह यह थी कि Go या Rust binaries पर भरोसा करना मुश्किल लगता है
      overlay FS macOS पर कठिन है, लेकिन CWD के बाहर सब कुछ read-only सीमित करके और temporary folder में काम करने के लिए मजबूर करके इसका हल निकाला गया
    • मैं Amika नाम का एक OSS बना रहा हूँ। यह local और remote sandboxes को तेज़ी से शुरू करने वाला टूल है, और Git के साथ अच्छी तरह integrated है
      इसमें TCP/UDP port exposure और team members के साथ sharing भी संभव है। GitHub लिंक देखें
    • मैंने Treebeard नाम का एक प्रोजेक्ट बनाया है। यह sandbox-exec, worktree और COW filesystem को जोड़ता है
      इससे git-ignored files तक सुरक्षित पहुँच मिल सकती है। Treebeard लिंक
    • लेकिन क्या sandbox-exec पहले से ही deprecated नहीं है?

  • एक दिलचस्प बात: sandbox-exec आधिकारिक रूप से macOS Sierra (2016) से deprecated है
    फिर भी यह अब तक उपयोगी बना हुआ है। Apple का App Sandbox ऐसे user-defined rules के लिए उपयुक्त नहीं है
    उम्मीद है Apple इसे पूरी तरह बंद नहीं करेगा

    • सच कहें तो लगता है यह शुरू से ही deprecated जैसा था। profile language की documentation लगभग नहीं के बराबर है, और ज़्यादातर चीज़ें reverse engineering से समझी गई हैं

  • Sandvault नाम का भी एक प्रोजेक्ट है। यह sandbox-exec को Unix user system के साथ जोड़ता है
    हर agent को अलग non-privileged user account दिया जाता है, और sudo, SSH, shared directories के जरिए interaction कराया जाता है
    Sandvault GitHub लिंक

  • मैंने macOS के लिए एक GUI app बनाया है, जिससे sandbox-exec को visual तरीके से manage किया जा सकता है
    इसमें domain-based network filtering और secret detection feature भी शामिल हैं
    multitui.com

  • Apple के container command का इस्तेमाल करके Claude code को Apple container के अंदर चलाने का तरीका साझा किया गया
    container system start → container run → container exec क्रम में environment सेट किया जाता है, फिर Node.js और Claude install किए जाते हैं

    • धन्यवाद! मुझे अभी पहली बार पता चला कि Homebrew में भी apple/container है

  • जानना चाहता हूँ कि local पर agents चलाना बेहतर क्यों माना जा रहा है।
    ज़्यादातर लोगों के लिए remote execution ज़्यादा efficient लगता है — क्योंकि उसे हमेशा चालू रखने की ज़रूरत नहीं होती

    • local execution का फायदा control और ownership है। यह वैसा ही है जैसे लोग Plex या web server खुद चलाते हैं
      और subscription fee से भी बचा जा सकता है
    • मैंने इस समस्या को हल करने के लिए pixels बनाया है। यह TrueNAS SCALE या Incus पर चल सकता है
      इसकी security hardening पर काम चल रहा है, और AI workflows के लिए यह पर्याप्त रूप से उपयुक्त है
      pixels GitHub लिंक

  • क्या “clunker”, “clanker” का नया slang है? मेरे दोस्त के दोस्त Roku ने पूछा
    मैं अभी sandboxing की समस्या से जूझ रहा हूँ, इसलिए timing बिल्कुल सही है

    • वह typo था, अभी-अभी ठीक कर दिया