SPACE विनंत्या योग्य सँडबॉक्स एक्झिक्युशनपर्यंत कशा पोहोचवतो

जेव्हा कोणी AI एजंटला स्प्रेडशीटचे विश्लेषण करायला किंवा सॉफ्टवेअरची चाचणी करायला सांगतात, तेव्हा तो एजंट त्यांच्या फाइल्स आणि डेटासोबत सुरक्षितपणे काम करेल असा विश्वास ते ठेवत असतात. एजंटना अशा अलग वातावरणांची गरज असते, जिथे ते इतर वापरकर्त्यांचा डेटा उघड न करता किंवा त्यांच्या वर्कलोड्समध्ये हस्तक्षेप न करता ते काम पार पाडू शकतील.

एजंट अधिक स्वायत्ततेने अधिक गुंतागुंतीची कामे हाती घेत असताना, ही वातावरणे चुका मर्यादित ठेवण्यास आणि असुरक्षित किंवा दुर्भावनापूर्ण कोडमुळे होणारे नुकसान कमी करण्यास मदत करतात. कंट्रोल-प्लेन सेवा, वर्कर नोड्स आणि राउटिंग इन्फ्रास्ट्रक्चर सामायिक करत असतानाही सँडबॉक्स हे अलगीकरण प्रदान करतात.

त्या सामायिक इन्फ्रास्ट्रक्चरने प्रत्येक ऑपरेशन ते हाताळण्यासाठी अधिकृत असलेल्या एक्झिक्युशनपर्यंतच पोहोचवले पाहिजे. कालबाह्य मार्ग एखादी वैध विनंती दुसऱ्या सँडबॉक्सकडे किंवा योग्य सँडबॉक्सच्या जुन्या एक्झिक्युशनकडे पाठवू शकतो. Perplexity चा सुरक्षित सँडबॉक्स प्लॅटफॉर्म SPACE प्रत्येक ऑपरेशन निवडलेल्या एक्झिक्युशनशी बांधतो आणि फॉरवर्ड करण्यापूर्वी गंतव्यस्थान तपासतो.

अनेक महिन्यांपासून SPACE दररोज दशलक्षावधी एक्झिक्युशन्स हाताळत आहे, त्यातील प्रत्येक एक्झिक्युशन एका अद्वितीय क्रिप्टोग्राफिक ओळखीने संरक्षित असते, आणि एरर दर 0.0002% पेक्षा कमी असून एकही कनेक्शन ड्रॉप झालेले नाही.

राउटिंगची समस्या

सँडबॉक्सची सुरक्षितता प्रत्येक विनंती योग्य गंतव्यस्थानी पोहोचवण्यावरही अवलंबून असते. अगदी साधे फाइल वाचनदेखील अशा सामायिक इन्फ्रास्ट्रक्चरमधून जाते, ज्याला सँडबॉक्स थांबतो, पुन्हा सुरू होतो किंवा मशीनदरम्यान हलतो तसतसा तो कुठे चालू आहे याचा मागोवा ठेवावा लागतो.

फाइल वाचनाची विनंती अनेक घटकांमधून प्रवास करते. SPACE चे कंट्रोल प्लेन सँडबॉक्स कोणत्या एक्झिक्युशन आणि वर्करवर आहे हे निश्चित करते. विनंती node-api मधून प्रवेश करते, सँडबॉक्स मॅनेजर sbx-manager कडे जाते आणि Unix सॉकेट ओलांडून होस्ट ब्रिज spaced-host पर्यंत पोहोचते. ब्रिज ती VSOCK, म्हणजेच होस्ट-ते-गेस्ट सॉकेट ट्रान्सपोर्टवरून, Firecracker microVM मधील spaced-guest कडे फॉरवर्ड करतो.

प्रत्येक निर्णय अशा स्थितीवर अवलंबून असतो जी इन्फ्रास्ट्रक्चरमधील बदलांच्या मागे पडू शकते. डेटाबेसमध्ये जुने प्लेसमेंट शिल्लक राहू शकते, कॅशे केलेला पत्ता दुसरीकडे निर्देश करू शकतो, किंवा सॉकेट पाथला वेगळा लिसनर मिळू शकतो. यशस्वी कनेक्शनसुद्धा चुकीच्या गंतव्यस्थानी पोहोचू शकते. वाचनामुळे दुसऱ्या वापरकर्त्याचा डेटा उघड होऊ शकतो; लेखनामुळे चुकीची फाइलसिस्टम बदलली जाऊ शकते.

स्नॅपशॉटमुळे आणखी एक समस्या निर्माण होते. सँडबॉक्स दुसऱ्या वर्करवर पुन्हा सुरू केल्याने त्याची तार्किक ओळख कायम राहते, पण नवीन एक्झिक्युशन सुरू होते. उशिरा आलेली विनंती किंवा टिकून राहिलेले कनेक्शन त्याच्या आधीच्या एक्झिक्युशनपर्यंत पोहोचू शकते आणि योग्य सँडबॉक्सच्या नावाखाली जुनी स्थिती परत करू शकते.

विस्तृत करा

सँडबॉक्स ओळख आणि एक्झिक्युशन ओळख

SPACE वापरकर्त्याचे वातावरण आणि ते सर्व्ह करणारा रनटाइम वेगळे ठेवतो:

• सँडबॉक्स ओळख: तार्किक वातावरणाचा स्थिर ID. कॉलरची अधिकृतता या सँडबॉक्सचा ॲक्सेस निश्चित करते.
• रूट/एक्झिक्युशन ओळख: निवडलेले रनटाइम इनकार्नेशन आणि त्याचे प्लेसमेंट, ज्यात त्याचा वर्कर, सबस्ट्रेट आणि ॲक्टिव्हेशन समाविष्ट आहे.

एक्झिक्युशन जनरेशनमुळे रनटाइम अवतारांमध्ये फरक करता येतो. Kubernetes वर, मार्गामध्ये pod UID देखील समाविष्ट असतो. पत्ते एंडपॉइंट शोधतात; ते एंडपॉइंट ऑपरेशन सर्व्ह करू शकतात की नाही हे एक्झिक्युशन ओळख ठरवते.

समजा सँडबॉक्स S वर्कर A वर एक्झिक्युशन 7 म्हणून चालतो आणि नंतर वर्कर B वर एक्झिक्युशन 8 म्हणून पुन्हा सुरू होतो. एक्झिक्युशन 8 साठी निवडलेली विनंती एक्झिक्युशन 7 पर्यंत पोहोचल्यास ती अयशस्वी झाली पाहिजे. केवळ सँडबॉक्स ID तपासल्यास ही विसंगती लक्षात येणार नाही.

विस्तृत करा

स्वाक्षरीकृत एक्झिक्युशन निवड

प्रत्येक विनंतीसोबत कोणते सँडबॉक्स एक्झिक्युशन ती हाताळू शकते आणि कोणता ॲक्सेस अनुमत आहे याचा स्वाक्षरीत पुरावा असतो. विनंती पुढे जाऊ देण्यापूर्वी, ती प्राप्त करणारा घटक तो पुरावा स्वतःच्या रनटाइम ओळखीशी पडताळून पाहतो.

कॉलरच्या अधिकृततेनंतर, SPACE सँडबॉक्स, एक्झिक्युशन, प्लेसमेंट आणि अनुमत ॲक्सेस ओळखणारी अल्पकालीन, स्वाक्षरीत कॅपेबिलिटी जारी करतो. सार्वजनिक सर्व्हिस-पोर्ट कॅपेबिलिटी अनुमत पोर्ट आणि प्रोटोकॉलदेखील नमूद करतात.

विनंती प्राप्त करणारा सँडबॉक्स मॅनेजर स्वाक्षरी पडताळतो आणि संपूर्ण ओळखीची तुलना त्याच्या स्थानिकरित्या जतन केलेल्या रनटाइम रेकॉर्डशी करतो. निवडीला कोणी अधिकृत केले हे स्वाक्षरीवरून सिद्ध होते. ती निवड प्राप्तकर्त्याशी जुळते की नाही हे तुलनेवरून सिद्ध होते.

गेस्ट कनेक्शन उघडण्यापूर्वी ServicePort ट्रॅफिकची प्रति-सँडबॉक्स नेटवर्क गेटवे netgtw वर दुसरी तपासणी होते. गेटवे ओळखीची तुलना विश्वसनीय ॲक्टिव्हेशन स्थितीशी करतो आणि पोर्ट व प्रोटोकॉल तपासतो. कंट्रोल ऑपरेशन्स ब्रिज एंडपॉइंट पडताळणीकडे पुढे जातात.

SPACE Ed25519 स्वाक्षऱ्या वापरतो. कंट्रोल-प्लेन साइनिंग की कॅपेबिलिटी जारी करतात; वर्कर आणि गेटवेवरील सार्वजनिक पडताळणी की त्या जारी करू शकत नाहीत.

कॅपेबिलिटी 120 सेकंद टिकतात आणि मुदत-समाप्तीसाठी घड्याळातील फरकाची (क्लॉक स्क्यू) 15 सेकंदांपर्यंत सवलत असते. निवडलेली आणि इन्स्टॉल केलेली ओळख जुळत नसल्यास, वैध स्वाक्षरी आणि मुदत न संपलेले टोकन असूनही ते पुरेसे ठरत नाही.

विस्तृत करा

चुकीच्या गंतव्यस्थानी नकार

विनंती स्वतः अधिकृत असतानाही, ती प्राप्त करणारा वर्कर राउटिंगमधील चूक पकडू शकतो. त्या विनंतीसाठी निवडलेले एक्झिक्युशनच तो चालवत आहे का हे तो तपासतो आणि ते वेगळे असल्यास विनंती नाकारतो.

एक्झिक्युशन 8 साठी निवडलेली विनंती अजूनही एक्झिक्युशन 7 सर्व्ह करणाऱ्या वर्कर A पर्यंत पोहोचल्यास, वर्कर A ती फॉरवर्ड करण्यापूर्वीच नाकारतो. एकदा रिसीव्हरने एक्झिक्युशन 8 ची ओळख इन्स्टॉल केली की, तो एक्झिक्युशन 7 साठीच्या कॅपेबिलिटीज कालबाह्य होण्यापूर्वीच नाकारतो.

या हमीला एक महत्त्वाची मर्यादा आहे. एक्झिक्युशन 7 सर्व्ह करणाऱ्या वर्करला निवृत्तीची माहिती मिळेपर्यंत किंवा कॅपेबिलिटीची मुदत संपेपर्यंत, एक्झिक्युशन 7 साठीची कॅपेबिलिटी त्या वर्करशी जुळू शकते. अपडेट्स प्रसारित होत असताना स्थानिक अंमलबजावणी आणि मर्यादित कॅपेबिलिटी आयुष्य एकत्रितपणे काम करतात.

विस्तृत करा

ब्रिज एंडपॉइंट पडताळणी

जुळणारा रनटाइम रेकॉर्ड अभिप्रेत एक्झिक्युशन निश्चित करतो. कंट्रोल ब्रिजनेही त्याच ॲक्टिव्हेशनच्या प्रोसेस आणि ट्रान्सपोर्टपर्यंतच पोहोचले पाहिजे, तोच पत्ता वारसाने मिळालेल्या बदलीपर्यंत नाही.

सँडबॉक्स आणि नोड मॅनेजर होस्ट ब्रिजची पीअर क्रेडेन्शियल्स आणि ब्रिज व Firecracker या दोन्ही प्रोसेसची ओळख, सुरुवातीच्या वेळांसह, पडताळतात आणि पुनर्वापर केलेले ID किंवा बदललेले एक्झिक्युटेबल शोधून काढतात

ट्रान्सपोर्ट तपासण्या सॉकेट मालकी, गेस्ट ओळख आणि कर्नल सॉकेट पुरावे वापरून VSOCK लिसनरला अपेक्षित Firecracker प्रोसेसशी जोडतात. ब्रिज केवळ पडताळणीनंतरच ऑपरेशन्स फॉरवर्ड करतो आणि पारदर्शक रिकनेक्ट नाकारतो. प्रत्येक नवीन कनेक्शनला या तपासण्या पुन्हा पार कराव्या लागतात.

ही पडताळणी Kubernetes आणि थेट व्यवस्थापित होस्टवरील Firecracker कंट्रोल ब्रिजला लागू होते. ServicePort ट्रॅफिक त्याच्या गेटवेवर एक्झिक्युशन आणि पोर्ट तपासण्या वापरते; ते गेस्टमधील कोणत्याही अनियंत्रित ॲप्लिकेशनच्या ओळखीचे प्रमाणन करत नाही.

विस्तृत करा

स्ट्रीमचे आयुष्य आणि मार्ग पुनर्प्राप्ती

सँडबॉक्सचे एक्झिक्युशन बदलत असताना काही कनेक्शन उघडी राहतात, त्यामुळे ओळख तपासण्या सुरुवातीच्या विनंतीपलीकडेही लागू व्हायला हव्यात. SPACE जुन्या एक्झिक्युशनशी जोडलेली कनेक्शन निवृत्त करतो आणि पात्र ऑपरेशन्सना त्याच सुरक्षा तपासण्यांसह सध्याच्या एक्झिक्युशनशी पुन्हा कनेक्ट होऊ देतो.

टर्मिनल आणि फाइल वॉच त्यांना उघडणाऱ्या विनंत्यांपेक्षा जास्त काळ टिकू शकतात. SPACE बॅकएंड स्ट्रीमना ओळख इपॉकशी जोडतो, जेणेकरून प्राप्तकर्त्याने बदली एक्झिक्युशन इन्स्टॉल केल्यानंतर स्ट्रीम आधीच्या एक्झिक्युशनशी जोडलेली राहू शकत नाही.

स्ट्रीम उघडण्यापूर्वी SPACE टिकाऊ ओळख पुन्हा तपासतो. त्याचा मार्ग किंवा एक्झिक्युशन बदलल्यास स्ट्रीमची लीज रद्द होते आणि इनपुट व आउटपुट थांबतात.

मालकीतील बदल हे एक्झिक्युशन बदलीपेक्षा वेगळे आहेत. न बदललेल्या Kubernetes रेसिडेंटवरील लाइफसायकल-ऑपरेशन हँडऑफ त्याची मार्ग ओळख, मुदत न संपलेल्या कॅपेबिलिटी आणि स्ट्रीम कायम ठेवतो. त्याच मार्ग आणि एक्झिक्युशन जनरेशनमध्ये केवळ ॲक्टिव्हेशन-प्रयत्नातील बदल झाल्यास गेटवेदेखील स्थापित स्ट्रीम कायम ठेवतो. नवीन स्ट्रीम उघडताना अद्ययावत ओळख आवश्यक असते.

रिकव्हरीदरम्यानही या तपासण्या कायम राहतात. आयडेंटिटी कंपॅरेटर एकाच सँडबॉक्समध्ये इनकार्नेशन जुळत नसल्यास RefreshRoute किंवा वेगळ्या सँडबॉक्ससाठी Deny परत करू शकतो. ओळख नाकारल्यानंतर फक्त ओळखला गेलेला रिफ्रेश सिग्नलच रूट दुरुस्ती सुरू करतो. ट्रान्सपोर्ट अपयशांसाठी स्वतंत्र, ऑपरेशन-विशिष्ट रिकव्हरी नियम लागू होतात. अवैध स्वाक्षऱ्या, उद्देश किंवा पोर्ट प्रोफाइल्स नाकारलेलेच राहतात.

पात्र ऑपरेशन सध्याचे एक्झिक्युशन शोधू शकते आणि पुनर्रचित विनंतीसह एकदा पुन्हा प्रयत्न करू शकते. कॅशेतील नोंद नाकारलेल्या मार्गाशी जुळत असेल तरच ती बदलली जाते, त्यामुळे उशिरा आलेला नकार नवीन नोंद काढून टाकू शकत नाही. नेटिव्ह-सत्र रिफ्रेश मूळ कॅशे मुदत कायम ठेवतो, ज्यामुळे मार्ग दुरुस्ती आणि कॉलरच्या अधिकृततेचे नूतनीकरण वेगळे राहतात.

रिप्ले नियम ऑपरेशननुसार वेगवेगळे राहतात. क्लायंटकडील WebSocket उघडे राहिले तरीही, बदली बॅकएंडला पुन्हा प्रवेश तपासणी पार करावी लागते.

विस्तृत करा

तडजोडी आणि विश्वासाच्या सीमा

एक्झिक्युशन ओळख ही सुरक्षिततेसाठी अत्यंत महत्त्वाची स्थिती बनते. कंट्रोल-प्लेन अपडेट्स आणि पडताळणी-की बंडल सर्व्हिंग घटकांपर्यंत पोहोचले पाहिजेत, आणि प्रत्येक प्राप्तकर्ता अपडेट इन्स्टॉल करतो तेव्हा निवृत्ती लागू होते. कॅपेबिलिटीचे अल्प आयुष्य प्रसारणादरम्यान होणाऱ्या पुनर्वापराला मर्यादा घालते.

हे डिझाइन ओळख अंमलबजावणी सक्षम असल्याचे गृहीत धरते आणि कंट्रोल-प्लेन साइनर, वर्कर कर्नल व नोड-स्थानिक व्यवस्थापन सेवांवर विश्वास ठेवते. वर्कर-रूट किंवा विशेषाधिकारप्राप्त क्लस्टर-प्रशासकाचा ताबा हल्लेखोराकडे जाणे हे थ्रेट मॉडेलच्या कक्षेबाहेर आहे. ब्रिज पडताळणी ही स्थानिक प्रोसेस आणि ट्रान्सपोर्ट पडताळणी आहे, हार्डवेअर-आधारित रिमोट अटेस्टेशन नाही.

स्वाक्षरी पडताळणी, रनटाइम तुलना आणि ब्रिज पडताळणीमुळे विनंतीच्या मार्गावरील कामाचा भार वाढतो. प्रत्येक खाजगी टप्प्यावर दूरस्थ अधिकृतता लुकअप करण्याऐवजी त्या स्थानिक स्थितीचा वापर करतात.

उद्योगातील तुलना

अधिकृत विनंती योग्य सँडबॉक्सच्या चुकीच्या एक्झिक्युशनपर्यंत पोहोचल्यास प्लॅटफॉर्म ती कशी हाताळतात, ही येथे महत्त्वाची तुलना आहे. हे निष्कर्ष तपासलेल्या इम्प्लिमेंटेशन्सशी संबंधित आहेत, प्लॅटफॉर्मच्या एकूण सुरक्षिततेशी नाहीत. SPACE, OpenShell आणि E2B यांची तपासणी 8 ऑक्टोबर 2026 रोजी करण्यात आली:

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

अलगीकरणाची सीमा म्हणून ओळख

एजंटकडे काम सुरक्षितपणे सोपवता येणे हे प्रत्येक एजंटचे काम त्याच्यासाठी ठरवलेल्या मर्यादांमध्येच राहण्यावर अवलंबून असते. microVM अलगीकरण प्रदान करते, तर सभोवतालच्या प्लॅटफॉर्मने हे सुनिश्चित केले पाहिजे की प्रत्येक विनंती आणि चालू कनेक्शन ते हाताळण्यासाठी अधिकृत असलेल्या एक्झिक्युशनपर्यंतच पोहोचेल.

SPACE एक्झिक्युशन ओळखीला त्या संरक्षणाचा भाग बनवतो. गंतव्यस्थाने तपासून, ब्रिज एंडपॉइंट पडताळून आणि कनेक्शनना त्यांना अधिकृत करणाऱ्या एक्झिक्युशनशी जोडून, सँडबॉक्स थांबतात, पुन्हा सुरू होतात आणि हलतात तेव्हाही तो त्या मर्यादा अबाधित ठेवतो.

इन्फ्रास्ट्रक्चर विकसित होत असताना आम्ही हे काम पुढे सुरू ठेवत आहोत. SPACE आणि इतर सँडबॉक्स प्लॅटफॉर्मसाठी, सुरक्षिततेसाठी हे मार्ग नेहमीच्या राउटिंग चुका आणि दुर्भावनापूर्ण वर्कलोड्स या दोन्हींविरुद्ध तपासणे, आणि त्या चाचण्यांत जिथे त्रुटी आढळतील तिथे मर्यादा मजबूत करणे आवश्यक आहे.