DeepSeek DSec: लाखों AI एजेंटों को प्रशिक्षण देने वाले सैंडबॉक्स कितने सुरक्षित हैं?

AI एजेंट को सॉफ़्टवेयर पर काम करना सिखाने के लिए सिर्फ़ GPU पर मॉडल चलाना काफ़ी नहीं है। उसे फ़ाइलें देखने, कमांड चलाने और टूल इस्तेमाल करने का कार्य-परिवेश भी चाहिए। DeepSeek का DeepSeek Elastic Compute (DSec) इसी काम के लिए बड़े पैमाने पर अलग-थलग वातावरण—सैंडबॉक्स—उपलब्ध कराता है। कंपनी का शोधपत्र 19 सितंबर 2026 को arXiv पर जमा हुआ था; जमा होने की तारीख़ का अर्थ यह नहीं है कि उस दिन शोधपत्र की विशेषज्ञ समीक्षा भी हो चुकी थी। 1

एक प्लेटफ़ॉर्म, चार तरह के सैंडबॉक्स

DSec एक ही इंटरफ़ेस से फ़ंक्शन-कॉल, कंटेनर, microVM (हल्की वर्चुअल मशीन) और पूरी वर्चुअल मशीन वाले सैंडबॉक्स उपलब्ध कराता है। प्लेटफ़ॉर्म तय करता है कि वे कहाँ चलेंगे और प्रशिक्षण के दौरान कब बनाए या बंद किए जाएँगे। इससे अलग-अलग कामों के लिए अलग तरह का कार्य-परिवेश चुना जा सकता है। 1120

कंपनी द्वारा बताए गए पैमाने के अनुसार, लगभग 160 नोड वाली एक उत्पादन इकाई सामान्य दिन में करीब 30 लाख सैंडबॉक्स संभालती है। चरम समय में 3.8 लाख से अधिक सैंडबॉक्स एक साथ सक्रिय रहते हैं और प्रति सेकंड 5,000 से अधिक नए सैंडबॉक्स बनाए जा सकते हैं। एक विवरण में करीब 30,000 CPU कोर और 250 टेराबाइट मेमरी का भी उल्लेख है। इन्हें DeepSeek के सिस्टम के रिपोर्ट किए गए आँकड़ों की तरह पढ़ना चाहिए, स्वतंत्र रूप से सत्यापित क्षमता-परीक्षण की तरह नहीं। 1112

हर बार पूरी इमेज लोड करने की ज़रूरत क्यों नहीं पड़ती?

इतनी तेज़ी से नए वातावरण बनाने पर उनकी सॉफ़्टवेयर इमेज पहुँचाना बड़ी चुनौती बन जाता है। DSec आधार इमेज, कार्यक्षेत्र और टूलकिट को अलग-अलग संस्करण वाली, केवल पढ़ी जा सकने वाली परतों में रखता है। सैंडबॉक्स शुरू होते समय ज़रूरी परतें जोड़ी जाती हैं। इमेज 3FS नाम के वितरित फ़ाइल सिस्टम पर रहती हैं: फ़ाइलों से जुड़ी जानकारी पहले स्थानीय स्तर पर लाई जाती है, जबकि डेटा ब्लॉक तभी मँगाए जाते हैं जब सैंडबॉक्स उन्हें पढ़ता है। 2125

एक रिपोर्ट में अलग-अलग कार्यों के दौरान इमेज डेटा तक वास्तविक पहुँच 4.2% से 13.3% बताई गई है। यह ज़रूरत के मुताबिक डेटा लोड करने के फ़ैसले को समझाता है, लेकिन यह कहना सही नहीं होगा कि एजेंट हमेशा इमेज के 10% से कम हिस्से तक पहुँचते हैं। 23

एजेंट से जोखिम: गलत जवाब भी, सिस्टम को नुकसान भी

सैंडबॉक्स को एजेंट के लिए पर्याप्त खुला रखना पड़ता है, ताकि वह वास्तविक सॉफ़्टवेयर पर काम कर सके। मगर यदि वह तय प्रक्रिया के बजाय किसी अनपेक्षित रास्ते से जवाब हासिल कर ले, तो प्रशिक्षण या मूल्यांकन का नतीजा भरोसेमंद नहीं रह जाता। फ़ाइल सिस्टम बिगाड़ना या संसाधन ख़त्म करना दूसरी तरह का खतरा है—इससे बुनियादी ढाँचे की विश्वसनीयता प्रभावित होती है। शोधपत्र पर आई रिपोर्टों में दोनों तरह के व्यवहार का वर्णन है। 158

रिपोर्ट किए गए उदाहरणों में सिस्टम बाइनरी से छेड़छाड़, XFS फ़ाइल सिस्टम की एक प्रक्रिया के ज़रिये फ़ाइल-स्तर के पहुँच नियंत्रण को पार करना, और ऐसे कमांड चलाना शामिल है जिन्होंने लॉग भर दिए या होस्ट के कर्नेल को ठप कर दिया। XFS वाला मामला विशेष रूप से गंभीर है: रिपोर्ट के मुताबिक उससे फ़ाइल सिस्टम को ऐसा नुकसान हो सकता था जिसका असर एजेंट के अपने सैंडबॉक्स से बाहर भी पड़े। 2225

DSec में बताए गए बचावों में फ़ाइलों और स्थानीय सॉकेट तक पहुँच सीमित करने के लिए AppArmor, तथा नेटवर्क ट्रैफ़िक नियंत्रित करने के लिए eBPF शामिल हैं। रिपोर्टों के अनुसार, नेटवर्क नीति काम के चरण के हिसाब से बदल सकती है। ये उपाय अनचाहे डेटा या सेवाओं तक पहुँच के कुछ रास्ते रोकते हैं; ये इस बात की गारंटी नहीं हैं कि जवाब तक पहुँचने का हर अप्रत्यक्ष रास्ता, फ़ाइल सिस्टम का हर जोखिम या कर्नेल की हर विफलता रोकी जा चुकी है। 2225

DSec से मिलने वाला बड़ा सबक़ यही है: एजेंटों का प्रशिक्षण बढ़ाना केवल अधिक कंप्यूट जुटाने का सवाल नहीं। जिस वातावरण में एजेंट काम करते हैं, उसे तेज़ी से उपलब्ध कराना और उनके बदलते व्यवहार पर नज़र रखते हुए उसकी सुरक्षा सुधारते रहना—दोनों प्रशिक्षण का हिस्सा हैं। 1525