SPACE अनुरोधों को सही सैंडबॉक्स एक्ज़िक्यूशन तक कैसे रूट करता है

जब कोई किसी AI एजेंट से स्प्रेडशीट का विश्लेषण करने या सॉफ़्टवेयर का परीक्षण करने के लिए कहता है, तो वह भरोसा करता है कि एजेंट उसकी फ़ाइलों और डेटा के साथ सुरक्षित रूप से काम करेगा। एजेंटों को ऐसे आइसोलेटेड वातावरण की ज़रूरत होती है जहाँ वे दूसरे उपयोगकर्ताओं का डेटा उजागर किए बिना या उनके वर्कलोड में बाधा डाले बिना वह काम कर सकें।

जैसे-जैसे एजेंट अधिक स्वायत्तता के साथ अधिक जटिल कार्य संभालते हैं, ये वातावरण गलतियों को सीमित रखने और असुरक्षित या दुर्भावनापूर्ण कोड से होने वाले नुकसान को कम करने में मदद करते हैं। सैंडबॉक्स कंट्रोल-प्लेन सेवाओं, वर्कर नोड और रूटिंग इंफ्रास्ट्रक्चर को साझा करते हुए भी वह आइसोलेशन प्रदान करते हैं।

उस साझा इंफ्रास्ट्रक्चर को हर ऑपरेशन उसी एक्ज़िक्यूशन तक पहुँचाना चाहिए जिसे उसे संभालने के लिए अधिकृत किया गया है। एक पुराना रूट किसी वैध अनुरोध को किसी दूसरे सैंडबॉक्स तक, या सही सैंडबॉक्स के किसी पुराने एक्ज़िक्यूशन तक भेज सकता है। Perplexity का सुरक्षित सैंडबॉक्स प्लेटफ़ॉर्म SPACE हर ऑपरेशन को एक चयनित एक्ज़िक्यूशन से बाँधता है और फ़ॉरवर्ड करने से पहले गंतव्य की जाँच करता है।

महीनों से SPACE हर दिन लाखों एक्ज़िक्यूशन संभाल रहा है, जिनमें से हर एक एक अनूठी क्रिप्टोग्राफ़िक पहचान से सुरक्षित है। इसकी त्रुटि दर 0.0002% से कम है और एक भी कनेक्शन ड्रॉप नहीं हुआ है।

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

एक फ़ाइल रीड कई कंपोनेंट से होकर गुज़रती है। SPACE का कंट्रोल प्लेन सैंडबॉक्स को एक एक्ज़िक्यूशन और वर्कर से रिज़ॉल्व करता है। अनुरोध node-api के ज़रिए प्रवेश करता है, सैंडबॉक्स मैनेजर sbx-manager तक जाता है, और एक Unix सॉकेट को पार करके होस्ट ब्रिज spaced-host तक पहुँचता है। ब्रिज इसे होस्ट-से-गेस्ट सॉकेट ट्रांसपोर्ट VSOCK के ज़रिए Firecracker microVM के भीतर spaced-guest तक फ़ॉरवर्ड करता है।

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

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

रूटिंग आरेख, जो SPACE API, node-api, sbx-manager और spaced-host से होकर सैंडबॉक्स S के एक्ज़िक्यूशन 8 तक जाने वाले सैंडबॉक्स अनुरोध को दर्शाता है। गंतव्य-पहचान जाँचों के बिना, पुराने रूट, दोबारा इस्तेमाल किए गए IP या गलत तरीके से बंधे सॉकेट इसे किसी पिछले एक्ज़िक्यूशन, गलत सैंडबॉक्स या किसी दूसरे microVM की ओर मोड़ सकते हैं।

SPACE उपयोगकर्ता के वातावरण को उसे सर्व करने वाले रनटाइम से अलग रखता है:

सैंडबॉक्स पहचान: लॉजिकल वातावरण की स्थिर ID। कॉलर ऑथराइज़ेशन इस सैंडबॉक्स तक एक्सेस स्थापित करता है।
रूट/एक्ज़िक्यूशन पहचान: चुना गया रनटाइम इन्कार्नेशन और उसका प्लेसमेंट, जिसमें उसका वर्कर, सबस्ट्रेट और एक्टिवेशन शामिल हैं।

एक्ज़िक्यूशन जनरेशन रनटाइम इंकार्नेशन के बीच अंतर करता है। Kubernetes पर, रूट में पॉड UID भी शामिल होता है। पते एंडपॉइंट का स्थान बताते हैं; एक्ज़िक्यूशन पहचान यह निर्धारित करती है कि वे एंडपॉइंट ऑपरेशन को सर्व कर सकते हैं या नहीं।

मान लीजिए सैंडबॉक्स S, वर्कर A पर एक्ज़िक्यूशन 7 के रूप में चलता है, और फिर वर्कर B पर एक्ज़िक्यूशन 8 के रूप में रिज़्यूम होता है। एक्ज़िक्यूशन 8 के लिए चयनित अनुरोध अगर एक्ज़िक्यूशन 7 तक पहुँचता है, तो उसे विफल होना चाहिए। केवल सैंडबॉक्स ID की जाँच करने से यह असंगति पकड़ में नहीं आएगी।

आरेख, जिसमें चार लाइफ़साइकल जोखिम दिखाए गए हैं: पुराने रूट, रीसायकल किए गए एंडपॉइंट, एक्ज़िक्यूशन में बदलाव, और ऐसे कनेक्शन जो पहचान रोटेशन के बाद भी बने रहते हैं। गंतव्य-पहचान जाँचों के बिना, एक पुराना रूट सैंडबॉक्स A के लिए अधिकृत अनुरोध को सैंडबॉक्स B तक भेज सकता है, जिसके पास अब वही पता है।

हर अनुरोध में हस्ताक्षरित प्रमाण होता है कि कौन-सा सैंडबॉक्स एक्ज़िक्यूशन उसे संभाल सकता है और किस तरह की एक्सेस की अनुमति है। प्राप्त करने वाला कंपोनेंट अनुरोध को आगे बढ़ने देने से पहले उस प्रमाण की तुलना अपनी रनटाइम पहचान से करता है।

कॉलर ऑथराइज़ेशन के बाद, SPACE एक अल्पकालिक, हस्ताक्षरित कैपेबिलिटी जारी करता है, जो सैंडबॉक्स, एक्ज़िक्यूशन, प्लेसमेंट और अनुमत एक्सेस की पहचान करती है। सार्वजनिक सर्विस-पोर्ट कैपेबिलिटी में अनुमत पोर्ट और प्रोटोकॉल भी निर्दिष्ट होते हैं।

प्राप्त करने वाला सैंडबॉक्स मैनेजर हस्ताक्षर का सत्यापन करता है और पूरी पहचान की तुलना अपने स्थानीय रूप से सहेजे गए रनटाइम रिकॉर्ड से करता है। हस्ताक्षर यह स्थापित करता है कि चयन को किसने अधिकृत किया। तुलना यह स्थापित करती है कि वह चयन रिसीवर से मेल खाता है या नहीं।

गेस्ट कनेक्शन खुलने से पहले, ServicePort ट्रैफ़िक की प्रति-सैंडबॉक्स नेटवर्क गेटवे netgtw पर दूसरी जाँच होती है। गेटवे पहचान की तुलना विश्वसनीय एक्टिवेशन स्थिति से करता है और पोर्ट व प्रोटोकॉल की जाँच करता है। कंट्रोल ऑपरेशन ब्रिज एंडपॉइंट सत्यापन की ओर आगे बढ़ते हैं।

SPACE, Ed25519 हस्ताक्षरों का उपयोग करता है। कंट्रोल-प्लेन साइनिंग कुंजियाँ कैपेबिलिटी जारी करती हैं; वर्कर और गेटवे पर मौजूद सार्वजनिक सत्यापन कुंजियाँ उन्हें जारी नहीं कर सकतीं।

कैपेबिलिटी 120 सेकंड तक मान्य रहती हैं, और समाप्ति के लिए अधिकतम 15 सेकंड तक के क्लॉक-स्क्यू की छूट होती है। जब चयनित और इंस्टॉल की गई पहचानें मेल नहीं खातीं, तब वैध हस्ताक्षर और असमाप्त टोकन भी पर्याप्त नहीं होते।

आरेख, जिसमें दिखाया गया है कि SPACE ऑथराइज़ेशन को वास्तव में पहुँचे गए एक्ज़िक्यूशन से कैसे बाँधता है। कॉलर एंटाइटलमेंट की अलग जाँच के बाद, एक हस्ताक्षरित रूट कैपेबिलिटी कंट्रोल-ब्रिज या ServicePort इनग्रेस पाथ से गुज़रती है, जहाँ गेस्ट कंट्रोल सर्वर या उपयोगकर्ता सेवा तक पहुँचने से पहले रिसीवर कैपेबिलिटी और लाइव एक्ज़िक्यूशन पहचान का सत्यापन करते हैं।

प्राप्त करने वाला वर्कर रूटिंग की गलती को तब भी पकड़ सकता है जब अनुरोध स्वयं अधिकृत हो। वह जाँचता है कि क्या वह उस अनुरोध के लिए चयनित एक्ज़िक्यूशन चला रहा है, और दोनों में अंतर होने पर अनुरोध को अस्वीकार कर देता है।

अगर एक्ज़िक्यूशन 8 के लिए चुना गया कोई अनुरोध वर्कर A तक पहुँचता है, जो अब भी एक्ज़िक्यूशन 7 को सर्व कर रहा है, तो वर्कर A उसे फ़ॉरवर्ड करने से पहले ही अस्वीकार कर देता है। जब कोई रिसीवर एक्ज़िक्यूशन 8 की पहचान इंस्टॉल कर लेता है, तो वह एक्ज़िक्यूशन 7 की क्षमताओं को भी अस्वीकार कर देता है, भले ही उनकी समय-सीमा अभी खत्म न हुई हो।

इस गारंटी की एक महत्वपूर्ण सीमा है। एक्ज़िक्यूशन 7 के लिए जारी कैपेबिलिटी तब तक एक्ज़िक्यूशन 7 को सर्व करने वाले वर्कर से मेल खा सकती है, जब तक उस वर्कर को रिटायरमेंट की जानकारी नहीं मिल जाती या कैपेबिलिटी की समय-सीमा समाप्त नहीं हो जाती। अपडेट के प्रसार के दौरान स्थानीय प्रवर्तन और कैपेबिलिटी की सीमित अवधि साथ मिलकर काम करते हैं।

आरेख, जिसमें SPACE को दो एक्ज़िक्यूशन-पहचान असंगतियों को अस्वीकार करते दिखाया गया है: एक्ज़िक्यूशन 8 के लिए जारी कैपेबिलिटी का एक्ज़िक्यूशन 7 तक पहुँचना, और एक्ज़िक्यूशन 7 के लिए जारी पुरानी कैपेबिलिटी का एक्ज़िक्यूशन 8 तक पहुँचना। वैध हस्ताक्षर और असमाप्त टोकन होने के बावजूद दोनों अनुरोध ब्लॉक कर दिए जाते हैं; रिटायरमेंट या समाप्ति तक कोई पुरानी कैपेबिलिटी किसी पुराने रिसीवर से अब भी मेल खा सकती है।

मेल खाता रनटाइम रिकॉर्ड इच्छित एक्ज़िक्यूशन को स्थापित करता है। कंट्रोल ब्रिज को भी उसी एक्टिवेशन से संबंधित प्रोसेस और ट्रांसपोर्ट तक पहुँचना चाहिए, न कि किसी ऐसे प्रतिस्थापन तक जिसे वही पता विरासत में मिला हो।

सैंडबॉक्स और नोड मैनेजर होस्ट ब्रिज के पीयर क्रेडेंशियल के साथ-साथ ब्रिज और Firecracker, दोनों की प्रोसेस पहचान का सत्यापन करते हैं, जिसमें शुरू होने का समय भी शामिल है, ताकि दोबारा इस्तेमाल किए गए ID या बदले गए एक्ज़िक्यूटेबल का पता लगाया जा सके

ट्रांसपोर्ट जाँचें सॉकेट स्वामित्व, गेस्ट पहचान और कर्नेल सॉकेट साक्ष्य का उपयोग करके VSOCK लिसनर को अपेक्षित Firecracker प्रोसेस से जोड़ती हैं। ब्रिज सत्यापन के बाद ही ऑपरेशन फ़ॉरवर्ड करता है और पारदर्शी रीकनेक्ट को अस्वीकार करता है। हर नए कनेक्शन को ये जाँचें फिर से पास करनी होती हैं।

यह सत्यापन Kubernetes और सीधे प्रबंधित होस्ट पर Firecracker कंट्रोल ब्रिज को कवर करता है। ServicePort ट्रैफ़िक अपने गेटवे पर एक्ज़िक्यूशन और पोर्ट जाँचों का उपयोग करता है; यह गेस्ट के भीतर किसी भी मनमाने एप्लिकेशन की पहचान को प्रमाणित नहीं करता।

sbx-manager से spaced-host और Firecracker होते हुए spaced-guest तक कंट्रोल ब्रिज को दर्शाने वाला आरेख। कनेक्शन को चयनित एक्ज़िक्यूशन से बाँधने के लिए, फ़ॉरवर्ड करने से पहले पीयर क्रेडेंशियल, प्रोसेस पहचान और ट्रांसपोर्ट स्वामित्व का सत्यापन किया जाता है; नए कनेक्शन ये जाँचें दोहराते हैं, और पारदर्शी रीकनेक्ट अक्षम रहता है।

सैंडबॉक्स का एक्ज़िक्यूशन बदलने के दौरान कुछ कनेक्शन खुले रहते हैं, इसलिए पहचान जाँचों को शुरुआती अनुरोध से आगे भी लागू होना चाहिए। SPACE पुराने एक्ज़िक्यूशन से जुड़े कनेक्शन को रिटायर कर देता है और योग्य ऑपरेशन को उन्हीं सुरक्षा जाँचों के तहत मौजूदा एक्ज़िक्यूशन से फिर से कनेक्ट होने देता है।

टर्मिनल और फ़ाइल वॉच उन्हें खोलने वाले अनुरोधों से अधिक समय तक चल सकते हैं। SPACE बैकएंड स्ट्रीम को एक पहचान एपॉक से जोड़ता है, ताकि रिसीवर द्वारा प्रतिस्थापन एक्ज़िक्यूशन इंस्टॉल करने के बाद कोई स्ट्रीम उसके पूर्ववर्ती से जुड़ी न रह सके।

SPACE स्ट्रीम खोलने से पहले स्थायी पहचान की दोबारा जाँच करता है। उसके रूट या एक्ज़िक्यूशन के बदलने पर स्ट्रीम की लीज़ रद्द हो जाती है, जिससे इनपुट और आउटपुट रुक जाते हैं।

स्वामित्व में बदलाव, एक्ज़िक्यूशन के प्रतिस्थापन से अलग हैं। किसी अपरिवर्तित Kubernetes रेज़िडेंट पर लाइफ़साइकल-ऑपरेशन हैंडऑफ़ उसकी रूट पहचान, असमाप्त कैपेबिलिटी और स्ट्रीम को बनाए रखता है। उसी रूट और एक्ज़िक्यूशन जनरेशन के भीतर केवल एक्टिवेशन-प्रयास से जुड़े बदलावों के लिए भी गेटवे स्थापित स्ट्रीम को बनाए रखता है। नई स्ट्रीम खोलने के लिए अपडेट की गई पहचान आवश्यक है।

रिकवरी के दौरान ये जाँचें बरकरार रहती हैं। पहचान तुलनाकर्ता एक ही सैंडबॉक्स के भीतर इन्कार्नेशन मेल न खाने पर RefreshRoute लौटा सकता है, या किसी दूसरे सैंडबॉक्स के लिए Deny। पहचान अस्वीकार होने के बाद सिर्फ़ पहचाना गया रिफ़्रेश सिग्नल ही रूट की मरम्मत शुरू करता है। ट्रांसपोर्ट विफलताओं पर अलग, ऑपरेशन-विशिष्ट रिकवरी नियम लागू होते हैं। अमान्य सिग्नेचर, उद्देश्य या पोर्ट प्रोफ़ाइल अस्वीकार ही रहते हैं।

कोई योग्य ऑपरेशन मौजूदा एक्ज़िक्यूशन का पता लगाकर नए सिरे से बनाया गया एक प्रयास कर सकता है। कैश का प्रतिस्थापन अस्वीकृत रूट पर निर्भर होता है, जिससे कोई विलंबित अस्वीकृति किसी नई एंट्री को हटा नहीं पाती। नेटिव-सत्र रिफ़्रेश मूल कैश समाप्ति को बनाए रखता है, जिससे रूट की मरम्मत, कॉलर ऑथराइज़ेशन के नवीनीकरण से अलग रहती है।

रीप्ले नियम ऑपरेशन-विशिष्ट बने रहते हैं। क्लाइंट की ओर का WebSocket खुला रहने पर भी, प्रतिस्थापन बैकएंड को फिर से एडमिशन पास करना होगा।

आरेख, जिसमें उसी सैंडबॉक्स में एक्ज़िक्यूशन 8 को एक्ज़िक्यूशन 7 की जगह लेते दिखाया गया है: नए सिरे से अधिकृत बैकएंड खोलने से पहले पुरानी स्ट्रीम लीज़ रद्द की जाती हैं और इनपुट व आउटपुट रोके जाते हैं। रिकवरी मौजूदा रूट को एक बार रिज़ॉल्व करती है, योग्य ऑपरेशन को एक बार फिर से आज़माती है और नए बैकएंड का सत्यापन करती है; गलत सैंडबॉक्स के अनुरोध या अमान्य कैपेबिलिटी अस्वीकार कर दी जाती हैं।

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

यह डिज़ाइन मानकर चलता है कि पहचान प्रवर्तन सक्षम है, और यह कंट्रोल-प्लेन साइनर, वर्कर कर्नेल और नोड-स्थानीय प्रबंधन सेवाओं पर भरोसा करता है। वर्कर-रूट या विशेषाधिकार प्राप्त क्लस्टर एडमिनिस्ट्रेटर स्तर पर सेंधमारी इस थ्रेट मॉडल के दायरे से बाहर है। ब्रिज सत्यापन स्थानीय प्रोसेस और ट्रांसपोर्ट सत्यापन है, न कि हार्डवेयर-आधारित रिमोट अटेस्टेशन।

हस्ताक्षर सत्यापन, रनटाइम तुलनाएँ और ब्रिज सत्यापन अनुरोध पाथ में अतिरिक्त काम जोड़ते हैं। वे हर प्राइवेट हॉप पर रिमोट ऑथराइज़ेशन लुकअप के बजाय स्थानीय स्थिति का उपयोग करते हैं।

प्रासंगिक तुलना यह है कि जब कोई अधिकृत अनुरोध सही सैंडबॉक्स के गलत एक्ज़िक्यूशन तक पहुँचता है, तो प्लेटफ़ॉर्म उसे कैसे संभालते हैं। ये निष्कर्ष जाँचे गए इम्प्लीमेंटेशन से संबंधित हैं, न कि समग्र प्लेटफ़ॉर्म सुरक्षा से। SPACE, OpenShell और E2B की जाँच 8 अक्टूबर, 2026 को की गई थी:

OpenShell: गेटवे जनरेशन और ऑथराइज़ेशन जाँचों, बैकएंड पहचान सत्यापन और पुष्ट सक्रिय सुपरवाइज़र कनेक्शन के ज़रिए नई कॉल के लिए तुलनीय एक्ज़िक्यूशन चयन और सुपरवाइज़र-से-रनटाइम बाइंडिंग प्रदान करता है (गेटवे एडमिशन, रनटाइम ऑथेंटिकेशन और बाइंडिंग)। SPACE हस्ताक्षरित चयन को अपने पूरे सर्विंग पाथ में साथ ले जाता है और वर्कर-स्थानीय प्रोसेस और ट्रांसपोर्ट सत्यापन जोड़ता है; OpenShell संबंधित जाँचों को अपने गेटवे, लॉन्च पहचान और प्रमाणित रनटाइम प्रोटोकॉल में बाँटता है (रनटाइम डिज़ाइन)।
E2B: एक्ज़िक्यूशन ID को ट्रैक करता है और Firecracker लाइफ़साइकल के आधार पर प्रॉक्सी पूल को अलग करता है, लेकिन इसका इनबाउंड प्रॉक्सी रिसीवर द्वारा तुलना के लिए किसी अपेक्षित एक्ज़िक्यूशन पहचान के बिना लॉजिकल सैंडबॉक्स और पोर्ट का चयन करता है (रूट प्रकाशन, प्रॉक्सी एडमिशन)। मेल खाते क्रेडेंशियल वाले किसी पुराने पड़ चुके रिसीवर पर अब भी लाइव के रूप में पंजीकृत पुराने एक्ज़िक्यूशन को इन जाँचों के ज़रिए चयनित नए एक्ज़िक्यूशन से अलग नहीं किया जा सकता, हालाँकि सामान्य टियरडाउन रूट हटा देता है और लाइफ़साइकल से बंधे कनेक्शन बंद कर देता है (क्रेडेंशियल, टियरडाउन)।
CubeSandbox: रिज़्यूम होने पर रूटिंग को ठीक करता है और कैश को अमान्य करता है, लेकिन प्राइवेट इनग्रेस सैंडबॉक्स-स्कोप वाले क्रेडेंशियल का उपयोग करता है और किसी अपेक्षित रनटाइम इंकार्नेशन के बिना अनुरोध फ़ॉरवर्ड करता है (रिज़्यूम रूटिंग, इनग्रेस रूटिंग)। रूट की मरम्मत से पुराने रूट वाली अवधि कम होती है; SPACE की एक्ज़िक्यूशन-बद्ध कैपेबिलिटी रिसीवर को गलत इंकार्नेशन को अस्वीकार करने का एक स्वतंत्र आधार भी देती है।

सुरक्षित डेलिगेशन इस बात पर निर्भर करता है कि हर एजेंट का काम उसके लिए तय सीमाओं के भीतर रहे। microVM आइसोलेशन प्रदान करता है, जबकि आसपास के प्लेटफ़ॉर्म को यह सुनिश्चित करना होता है कि हर अनुरोध और चालू कनेक्शन उसी एक्ज़िक्यूशन तक पहुँचे जिसे उसे संभालने के लिए अधिकृत किया गया है।

SPACE एक्ज़िक्यूशन पहचान को उस सुरक्षा का हिस्सा बनाता है। गंतव्यों की जाँच करके, ब्रिज एंडपॉइंट का सत्यापन करके और कनेक्शन को उन्हें अधिकृत करने वाले एक्ज़िक्यूशन से जोड़कर, यह सैंडबॉक्स के पॉज़, रिज़्यूम और स्थानांतरित होने के दौरान भी उन सीमाओं को बनाए रखता है।

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

रूटिंग की समस्या

सैंडबॉक्स पहचान और एक्ज़िक्यूशन पहचान

साइन किया गया एक्ज़िक्यूशन चयन

गलत गंतव्य पर अस्वीकृति

ब्रिज एंडपॉइंट सत्यापन

स्ट्रीम की अवधि और रूट रिकवरी

ट्रेड-ऑफ़ और भरोसे की सीमाएँ

उद्योग से तुलना

आइसोलेशन सीमा के रूप में पहचान

इससे मिलते-जुलते और लेख