Google Cloud ने एक मैनेज्ड GKE Agent Sandbox सर्विस पेश की है, जबकि ओपन-सोर्स kubernetes-sigs/agent-sandbox प्रोजेक्ट यही क्षमता किसी भी Kubernetes क्लस्टर को प्रदान करता है। दोनों ही डेवलपर्स को AI एजेंट्स के लिए एक डिस्पोजेबल Linux कंटेनर देते हैं, जिससे बाकी का इंफ्रास्ट्रक्चर सुरक्षित रहता है।

AI-जनरेटेड कोड को 'प्लेपेन' (playpen) की आवश्यकता क्यों है

आधुनिक AI एजेंट्स सिर्फ सवालों के जवाब ही नहीं देते। वे स्क्रिप्ट लिखते हैं, वेब ब्राउज़ करते हैं, शेल कमांड चलाते हैं और यहाँ तक कि वेब सर्विसेज भी लॉन्च करते हैं। यह शक्ति एक सुरक्षा अंतराल (security gap) पैदा करती है: उनके द्वारा जनरेट किया गया कोड बग से भरा, दुर्भावनापूर्ण (malicious) या अत्यधिक आक्रामक हो सकता है। एक ऐसा एजेंट जो rm -rf / चला दे या बिना अनुमति के किसी इंटरनल डेटाबेस से जुड़ जाए, वह पूरे सिस्टम को खतरे में डाल सकता है।

एक सैंडबॉक्स (sandbox) प्रत्येक एजेंट को उसके अपने कंटेनर में अलग कर देता है—जो एक छोटा, डिस्पोजेबल वर्चुअल मशीन की तरह होता है। यदि एजेंट गलत व्यवहार करता है, तो नुकसान उसी कंटेनर के भीतर ही रहता है; होस्ट और अन्य वर्कलोड सुरक्षित रहते हैं। नया GKE ऑफरिंग और कम्युनिटी-संचालित प्रोजेक्ट इस विचार को एक रेडी-टू-यूज़ सर्विस में बदल देते हैं।

सैंडबॉक्स प्राप्त करने के दो तरीके

  • GKE Agent Sandbox – Google Cloud ग्राहकों के लिए एक पूरी तरह से मैनेज्ड सर्विस।
  • kubernetes-sigs/agent-sandbox – किसी भी Kubernetes क्लस्टर के लिए एक ओपन-सोर्स प्रोजेक्ट।

दोनों का कोर आर्किटेक्चर एक ही है, जो स्टैंडर्ड Kubernetes प्रिमिटिव्स (primitives) पर आधारित है।

सिस्टम कैसे बना है

Component भूमिका (Role)
Sandbox आइसोलेटेड कंटेनर जो एजेंट के कोड को चलाता है। यदि आवश्यक हो, तो इसका एक स्थिर नाम और पर्सिस्टेंट स्टोरेज होता है।
SandboxTemplate एक ब्लूप्रिंट जो कंटेनर इमेज और सुरक्षा नीतियों को परिभाषित करता है—नए सैंडबॉक्स बनाने का एक तरीका (recipe)।
SandboxClaim एक विशिष्ट टेम्पलेट से सैंडबॉक्स शुरू करने के लिए एजेंट (या उसके कंट्रोलर) द्वारा जारी किया गया अनुरोध।
SandboxWarmPool पहले से बनाए गए सैंडबॉक्स का एक पूल जो तुरंत उपलब्ध होने के लिए तैयार है। कंटेनर्स को 'वार्म' रखने से हर बार इमेज खींचने और नया पॉड (pod) शुरू करने की लेटेंसी (latency) से बचा जा सकता है।

जब किसी एजेंट को एनवायरनमेंट की आवश्यकता होती है, तो वह एक SandboxClaim पोस्ट करता है। कंट्रोलर वार्म पूल की जाँच करता है, एक खाली (idle) सैंडबॉक्स चुनता है, और उसे क्लेम से जोड़ देता है। यदि पूल खाली है, तो यह टेम्पलेट से एक नया सैंडबॉक्स बनाता है; अन्यथा, यह प्रक्रिया मिलीसेकंड में पूरी हो जाती है।

सुरक्षा नियंत्रण (Security knobs) जिन्हें आप बदल सकते हैं

  • Default-deny networking – डिफ़ॉल्ट रूप से, एक सैंडबॉक्स इंटरनल नेटवर्क तक नहीं पहुँच सकता। आपको आउटबाउंड या इनबाउंड कनेक्शन की अनुमति देने के लिए स्पष्ट नियम जोड़ने होंगे, जिससे इंटरनल सर्विसेज के आकस्मिक एक्सपोज़र को रोका जा सके।
  • Isolation levels – वह कंटेनर रनटाइम चुनें जो आपके रिस्क टॉलरेंस (risk tolerance) के अनुकूल हो:
    • स्पीड के लिए स्टैंडर्ड कंटेनर्स,
    • अतिरिक्त यूजर-स्पेस आइसोलेशन लेयर के लिए gVisor, या
    • हार्डवेयर-असिस्टेड आइसोलेशन के लिए Kata Containers, जो एक लाइटवेट VM की तरह काम करता है।
  • SDKs – Python और Go क्लाइंट लाइब्रेरीज़ डेवलपर्स को प्रोग्रामेटिक रूप से सैंडबॉक्स बनाने, क्लेम करने और नष्ट करने की अनुमति देती हैं, जो AI-संचालित पाइपलाइनों के वर्कफ़्लो के अनुकूल है।

किसे लाभ होगा, और कौन विरोध कर सकता है

निष्कर्ष (Bottom line)

AI एजेंट्स को उनका अपना डिस्पोजेबल Linux बॉक्स देने से AI-संचालित ऑटोमेशन से सबसे बड़ा अनजाना जोखिम खत्म हो जाता है: यह जोखिम कि जनरेट किया गया कोड होस्ट को नुकसान पहुँचा सकता है। Google Cloud की मैनेज्ड GKE Agent Sandbox और कम्युनिटी द्वारा संचालित kubernetes-sigs/agent-sandbox इस आइसोलेशन को क्लाउड-नेटिव और ऑन-प्रीम (on-prem) दोनों वातावरणों के लिए व्यावहारिक बनाते हैं। वे संगठन जिन्हें सुरक्षा के साथ चपलता (agility) का संतुलन बनाए रखने की आवश्यकता है, अब उनके पास AI-जनरेटेड कोड को सैंडबॉक्स्ड प्लेपेन में रखने के लिए एक ठोस, Kubernetes-नेटिव टूल है।