प्रोडक्ट्स के across Claude को हम जिन तरीकों से सीमित करते हैं

सुरक्षा खतरों और एक्सफिल्ट्रेशन जोखिम

• टिप्पणीकार लेख में बताए गए दायरे से परे भी कई एक्सफिल्ट्रेशन वेक्टरों की ओर इशारा करते हैं: डोमेन फ्रंटिंग, कमिट्स या टेक्स्ट में स्टेगैनोग्राफिक एनकोडिंग, टाइमिंग/ऑर्डरिंग साइड चैनल, और रिपो, डॉक्यूमेंट्स, बग रिपोर्ट्स, या डिपेंडेंसीज़ में छिपे प्रॉम्प्ट इंजेक्शन।
• कई लोगों का तर्क है कि बहुत मजबूत, बहु-स्तरीय डेटा क्लासिफिकेशन सिस्टम और साइड-चैनल-सुरक्षित डिज़ाइन के बिना प्रॉम्प्ट-इंजेक्शन-आधारित एक्सफिल्ट्रेशन को रोकना व्यावहारिक रूप से असंभव है।
• कुछ लोग अनुमान लगाते हैं कि उद्योग एजेंट डिप्लॉयमेंट को “YOLO” करेगा और एक्सफिल्ट्रेशन व करप्शन को फ्रॉड-जैसी स्वीकार्य लागत मान लेगा।

कंटेनमेंट आर्किटेक्चर (VMs, एयरलॉक, अलग मशीनें)

• कई उपयोगकर्ता एजेंटों को VMs (qemu, macOS containers, Linux VMs) में सख्त egress नियंत्रण, प्रोजेक्ट-विशिष्ट टोकन, और कमिट्स की मैनुअल समीक्षा के साथ चलाने का वर्णन करते हैं।
• एक “airlock” पैटर्न पर चर्चा होती है: एक स्थानीय, ऑफ़लाइन एजेंट जिसमें filesystem access हो; एक ऑनलाइन, no-FS एजेंट; डेटा केवल यूज़र-मध्यस्थ टेक्स्ट के माध्यम से इनके बीच जाता है, और कभी भी अपने-आप इंटरनेट पर वापस नहीं जाता।
• अन्य लोग इससे भी कड़ी अलगाव की सलाह देते हैं: पूरी तरह अलग हार्डवेयर (सस्ते laptops/VPSs), one-way channels, या Qubes और “Tin Foil Chat” से प्रेरित अवधारणाएँ।
• containers बनाम VMs पर बहस होती है: कुछ Docker को बहुत कमजोर security boundary मानते हैं; अन्य लोग bubblewrap जैसे अतिरिक्त टूलिंग के साथ इसे स्वीकार करते हैं।

वर्तमान guardrails की सीमाएँ

• टिप्पणीकार इस बात पर ज़ोर देते हैं कि environment-layer controls “well-behaved” models से अधिक महत्वपूर्ण हैं; models अभी भी probabilistic हैं और उन्हें बहकाया जा सकता है।
• लेख में यह नोट कि auto-approval सिर्फ ~83% जोखिमपूर्ण actions को ब्लॉक करता है, कुछ पाठकों को चिंतित करता है, जो इसे product docs के साथ असंगत मानते हैं जो अधिक मज़बूत guarantees का संकेत देते हैं।
• Claude Code sandboxing और token scoping में पहले की गई bugs की रिपोर्टें सुझाती हैं कि containment अभी भी नाज़ुक है और पीछे भी जा सकती है।

जोखिम–लाभ का ढांचा और संदेह

• कई प्रतिभागी लेख के स्पष्ट risk–reward framing की आलोचना करते हैं: वे इसे security में सामान्य मानते हैं, लेकिन चिंता करते हैं कि कंपनियाँ अपना reward optimize कर रही हैं और risk यूज़र्स पर डाल रही हैं।
• अन्य लोग तर्क देते हैं कि वास्तविक दुनिया की सभी प्रणालियाँ शून्य से अलग जोखिम स्वीकार करती हैं; महत्वपूर्ण बात अपेक्षित नुकसान को कम करना है, उसे पूरी तरह समाप्त करना नहीं।
• vendor communications के बारे में स्पष्ट skepticism भी दिखता है, जहाँ कुछ लोग “model danger” narratives को marketing मानते हैं, भले ही वे वास्तविक safety work को स्वीकार करते हों।