كيف توجّه SPACE الطلبات إلى تنفيذ Sandbox الصحيح
تربط SPACE من Perplexity طلبات وكلاء الذكاء الاصطناعي بتنفيذ Sandbox الصحيح من خلال عمليات التحقق من الهوية والمسارات الموقّعة.

عندما يطلب شخص ما من وكيل ذكاء اصطناعي تحليل جدول بيانات أو اختبار برنامج، فإنه يثق بأنه سيتعامل مع ملفاته وبياناته بأمان. ويحتاج الوكلاء إلى بيئات معزولة يمكنهم فيها تنفيذ هذا العمل دون كشف بيانات المستخدمين الآخرين أو التداخل مع أحمال العمل الخاصة بهم.
مع تولي الوكلاء مهام أكثر تعقيدًا وبقدر أكبر من الاستقلالية، تساعد هذه البيئات على احتواء الأخطاء والحد من الضرر الذي قد تُحدثه الشيفرات غير الآمنة أو الضارة. وتوفّر بيئات Sandbox هذا العزل مع مشاركة خدمات مستوى التحكم وعُقد العمل والبنية التحتية للتوجيه.
يجب أن توصل هذه البنية التحتية المشتركة كل عملية إلى التنفيذ المخوَّل بمعالجتها. فقد يرسل مسار قديم طلبًا صالحًا إلى Sandbox آخر، أو إلى تنفيذ أقدم لـ Sandbox الصحيح. تربط SPACE، منصة Sandbox الآمنة من Perplexity، كل عملية بتنفيذ محدد وتتحقق من الوجهة قبل تمرير الطلب.
على مدى أشهر، تعامل SPACE مع ملايين عمليات التنفيذ يوميًا، كلٌّ منها محمية بهوية تشفيرية فريدة، بمعدل أخطاء أقل من 0.0002% ومن دون أي انقطاع في الاتصالات.
مشكلة التوجيه
يعتمد أمان Sandbox أيضًا على إيصال كل طلب إلى الوجهة الصحيحة. فحتى قراءة ملف بسيطة تمر عبر بنية تحتية مشتركة يجب أن تتتبّع مكان تشغيل Sandbox أثناء إيقافه مؤقتًا أو استئنافه أو انتقاله بين الأجهزة.
تمر عملية قراءة الملف عبر عدة مكونات. إذ يحدد مستوى التحكم في SPACE التنفيذ وعقدة العمل المقابلين لـ Sandbox. ويدخل الطلب عبر node-api، ثم ينتقل إلى مدير Sandbox، sbx-manager، ويعبر مقبس Unix إلى جسر المضيف، spaced-host. ثم يمرّره الجسر عبر VSOCK، وهي وسيلة نقل المقابس من المضيف إلى الضيف، إلى spaced-guest داخل microVM الخاص بـ Firecracker.
يعتمد كل قرار على حالة قد تتأخر عن مواكبة التغييرات في البنية التحتية. فقد تحتفظ قاعدة البيانات بموضع قديم، أو قد يشير عنوان مخزَّن مؤقتًا إلى مكان آخر، أو قد يرتبط مسار مقبس بمستمع مختلف. وقد يصل الاتصال الناجح رغم ذلك إلى الوجهة الخاطئة. فقد تكشف عملية قراءة بيانات مستخدم آخر، وقد تعدّل عملية كتابة نظام الملفات الخطأ.
تضيف اللقطات مشكلة أخرى. فاستئناف Sandbox على عقدة عمل أخرى يحافظ على هويته المنطقية لكنه يبدأ تنفيذًا جديدًا. وقد يصل طلب متأخر أو اتصال لا يزال قائمًا إلى التنفيذ السابق ويعيد حالة قديمة تحت اسم Sandbox الصحيح.
هوية Sandbox وهوية التنفيذ
تفصل SPACE بين بيئة المستخدم ووقت التشغيل الذي يخدمها:
- هوية Sandbox: المعرّف الثابت للبيئة المنطقية. ويُثبت تفويض المستدعي صلاحية الوصول إلى Sandbox هذا.
- هوية المسار/التنفيذ: تجسيد وقت التشغيل المحدد وموضع تشغيله، بما في ذلك العامل (worker) والطبقة الأساسية (substrate) والتفعيل الخاص به.
يميّز جيل التنفيذ بين نسخ وقت التشغيل المختلفة. وعلى Kubernetes، يتضمن المسار أيضًا معرّف pod UID. فالعناوين تحدد مواقع نقاط النهاية، بينما تحدد هوية التنفيذ ما إذا كان يجوز لتلك النقاط خدمة العملية.
لنفترض أن Sandbox S يعمل بوصفه التنفيذ 7 على عقدة العمل A، ثم يُستأنف بوصفه التنفيذ 8 على عقدة العمل B. يجب أن يفشل الطلب المحدد للتنفيذ 8 إذا وصل إلى التنفيذ 7. ولن يكشف التحقق من معرّف Sandbox وحده هذا التعارض.
الاختيار الموقَّع للتنفيذ
يحمل كل طلب دليلًا موقّعًا على تنفيذ Sandbox المسموح له بمعالجته وعلى نوع الوصول المسموح به. ويتحقق المكوّن المستقبِل من هذا الدليل مقارنةً بهوية وقت التشغيل الخاصة به قبل السماح للطلب بالمتابعة.
بعد تفويض المستدعي، تُصدر SPACE قدرة موقّعة قصيرة العمر تحدد Sandbox والتنفيذ والموضع والوصول المسموح به. كما تحدد قدرات منافذ الخدمة العامة المنفذ والبروتوكول المسموح بهما.
يتحقق مدير Sandbox المستقبِل من التوقيع ويقارن الهوية الكاملة بسجل وقت التشغيل المحفوظ محليًا لديه. يثبت التوقيع الجهة التي أذنت بالاختيار، بينما تثبت المقارنة ما إذا كان هذا الاختيار يطابق الجهة المستقبِلة.
تخضع حركة مرور ServicePort لتحقق ثانٍ في بوابة الشبكة الخاصة بكل Sandbox، netgtw، قبل فتح اتصال بالضيف. وتقارن البوابة الهوية بحالة التفعيل الموثوقة وتتحقق من المنفذ والبروتوكول. أما عمليات التحكم فتنتقل إلى التحقق من نقاط نهاية الجسر.
تستخدم SPACE توقيعات Ed25519. إذ تُصدر مفاتيح التوقيع في مستوى التحكم القدرات، بينما لا يمكن لمفاتيح التحقق العامة الموجودة على عُقد العمل والبوابات إصدارها.
تدوم القدرات 120 ثانية، مع سماحية تصل إلى 15 ثانية لانحراف الساعة عند التحقق من انتهاء الصلاحية. ولا يكفي التوقيع الصالح والرمز غير المنتهي الصلاحية عندما تختلف الهوية المحددة عن الهوية المثبّتة.
الرفض عند الوجهة الخاطئة
يمكن لعقدة العمل المستقبِلة اكتشاف خطأ في التوجيه حتى عندما يكون الطلب نفسه مخوَّلًا. فهي تتحقق مما إذا كانت تشغّل التنفيذ المحدد لذلك الطلب، وترفض الطلب إذا اختلفا.
إذا وصل طلب محدد للتنفيذ 8 إلى العامل A، الذي لا يزال يخدم التنفيذ 7، فإن العامل A يرفضه قبل إعادة توجيهه. وبمجرد أن يثبّت المستقبِل هوية التنفيذ 8، فإنه يرفض أيضًا القدرات (capabilities) الخاصة بالتنفيذ 7، حتى قبل انتهاء صلاحيتها.
لهذا الضمان حدّ مهم. فقد تظل القدرة الخاصة بالتنفيذ 7 مطابقة لعقدة عمل تخدم التنفيذ 7 إلى أن تعلم تلك العقدة بإيقافه نهائيًا أو تنتهي صلاحية القدرة. ويعمل الإنفاذ المحلي والعمر المحدود للقدرة معًا ريثما تنتشر التحديثات.
التحقق من نقاط نهاية الجسر
يحدّد سجل وقت التشغيل المطابق التنفيذَ المقصود. ويجب أيضًا أن يصل جسر التحكم إلى العمليات ووسيلة النقل التابعة لعملية التفعيل تلك، لا إلى بديل ورث العنوان نفسه.
يتحقق مديرا Sandbox والعقدة من بيانات اعتماد النظير لجسر المضيف، ومن هويتي عمليتي الجسر وFirecracker، بما في ذلك أوقات البدء، لاكتشاف المعرّفات المعاد استخدامها أو الملفات التنفيذية التي تغيّرت
تربط عمليات التحقق من وسيلة النقل مستمعَ VSOCK بعملية Firecracker المتوقعة باستخدام ملكية المقبس وهوية الضيف وأدلة المقبس على مستوى النواة. ولا يمرّر الجسر العمليات إلا بعد التحقق، ويرفض إعادة الاتصال الشفافة. ويجب أن يجتاز كل اتصال جديد عمليات التحقق مرة أخرى.
يشمل هذا التحقق جسر التحكم في Firecracker على Kubernetes والمضيفين المُدارين مباشرةً. وتخضع حركة مرور ServicePort لعمليات تحقق من التنفيذ والمنفذ في بوابتها؛ لكنها لا تُثبت هوية أي تطبيق عشوائي داخل الضيف.
عمر التدفق واستعادة المسار
تبقى بعض الاتصالات مفتوحة أثناء تغيّر تنفيذ Sandbox، لذا يجب أن تمتد عمليات التحقق من الهوية إلى ما بعد الطلب الأولي. وتُنهي SPACE الاتصالات المرتبطة بالتنفيذ القديم وتسمح للعمليات المؤهلة بإعادة الاتصال بالتنفيذ الحالي وفق عمليات التحقق الأمنية نفسها.
يمكن أن تستمر الطرفيات ومراقبات الملفات بعد انتهاء الطلبات التي فتحتها. وتربط SPACE تدفقات الواجهة الخلفية بحقبة هوية، بحيث لا يظل التدفق متصلًا بالتنفيذ السابق بعد أن تثبّت الجهة المستقبِلة تنفيذًا بديلًا.
تعيد SPACE التحقق من الهوية الدائمة قبل فتح التدفق. ويؤدي استبدال مساره أو تنفيذه إلى إلغاء عقد إيجار التدفق، ما يوقف الإدخال والإخراج.
تختلف تغييرات الملكية عن استبدال التنفيذ. فتسليم عمليات دورة الحياة على مقيم Kubernetes لم يتغير يحافظ على هوية مساره وقدراته غير المنتهية الصلاحية وتدفقاته. كما تحافظ البوابة على التدفقات القائمة عند حدوث تغييرات تقتصر على محاولة التفعيل ضمن المسار نفسه وجيل التنفيذ نفسه. أما عمليات الفتح الجديدة فتتطلب الهوية المحدَّثة.
تحافظ عملية الاسترداد على هذه الفحوصات كما هي. إذ يمكن لأداة مقارنة الهوية أن تُرجع RefreshRoute عند عدم تطابق التجسيد داخل Sandbox نفسها، أو Deny عند وجود Sandbox مختلفة. ولا يؤدي إلى إصلاح المسار بعد رفض الهوية إلا إشارة تحديث معترف بها. وتخضع إخفاقات النقل لقواعد استرداد منفصلة خاصة بكل عملية. أما التوقيعات أو الأغراض أو ملفات تعريف المنافذ غير الصالحة فتظل مرفوضة.
يمكن للعملية المؤهلة تحديد التنفيذ الحالي وإجراء محاولة واحدة بعد إعادة بنائها. ويكون استبدال ذاكرة التخزين المؤقت مشروطًا بالمسار المرفوض، ما يمنع الرفض المتأخر من إزالة إدخال أحدث. ويحافظ تحديث الجلسة الأصلية على موعد انتهاء صلاحية ذاكرة التخزين المؤقت الأولي، ما يفصل إصلاح المسار عن تجديد تفويض المستدعي.
تظل قواعد إعادة الإرسال خاصة بكل عملية على حدة. ويجب أن تجتاز الواجهة الخلفية البديلة إجراءات القبول مجددًا، حتى عندما يظل اتصال WebSocket المواجه للعميل مفتوحًا.
المفاضلات وحدود الثقة
تصبح هوية التنفيذ حالةً بالغة الأهمية للأمان. إذ يجب أن تصل تحديثات مستوى التحكم وحزم مفاتيح التحقق إلى مكونات الخدمة، ويسري الإيقاف النهائي عندما تثبّت كل جهة مستقبِلة التحديث. وتحدّ أعمار القدرات القصيرة من إعادة استخدامها أثناء انتشار التحديثات.
يفترض التصميم أن إنفاذ الهوية مفعَّل، ويثق بجهة التوقيع في مستوى التحكم ونواة عقدة العمل وخدمات الإدارة المحلية على العقدة. ويقع اختراق صلاحيات الجذر على عقدة العمل أو اختراق مسؤول العنقود ذي الصلاحيات المميزة خارج نموذج التهديد. والتحقق في الجسر هو تحقق محلي من العملية ووسيلة النقل، وليس إثباتًا عن بُعد مدعومًا بالأجهزة.
يضيف التحقق من التوقيعات ومقارنات وقت التشغيل والتحقق من صحة الجسر عملًا إضافيًا إلى مسار الطلب. لكنها تعتمد على الحالة المحلية بدلًا من إجراء بحث تفويض عن بُعد عند كل قفزة خاصة.
مقارنة مع القطاع
المقارنة ذات الصلة هي كيفية تعامل المنصات مع طلب مخوَّل يصل إلى التنفيذ الخاطئ من Sandbox الصحيح. وتتعلق هذه النتائج بالتطبيقات البرمجية التي خضعت للفحص، لا بأمان المنصات ككل. وقد جرى فحص SPACE وOpenShell وE2B في 8 أكتوبر 2026:
- OpenShell: يوفّر اختيارًا مماثلًا للتنفيذ في الاستدعاءات الجديدة وربطًا بين المشرف ووقت التشغيل من خلال عمليات التحقق من الجيل والتفويض في البوابة، والتحقق من هوية الواجهة الخلفية، وتأكيد اتصالات المشرف النشطة (القبول في البوابة، مصادقة وقت التشغيل وربطه). تنقل SPACE الاختيار الموقَّع عبر مسار الخدمة الخاص بها وتضيف تحققًا محليًا على عقدة العمل من العملية ووسيلة النقل؛ أما OpenShell فيوزّع عمليات التحقق المقابلة على البوابة وهوية الإطلاق وبروتوكول وقت التشغيل المصادَق عليه (تصميم وقت التشغيل).
- E2B: يتتبع معرّفات التنفيذ ويعزل مجمّعات الخوادم الوكيلة حسب دورة حياة Firecracker، لكن الخادم الوكيل الوارد يختار Sandbox المنطقي والمنفذ دون هوية تنفيذ متوقعة تقارن بها الجهة المستقبِلة (نشر المسارات، القبول في الخادم الوكيل). ولا تستطيع عمليات التحقق هذه التمييز بين تنفيذ أقدم لا يزال مسجلًا على أنه نشط لدى جهة مستقبِلة قديمة ببيانات اعتماد مطابقة، والتنفيذ الأحدث المحدد، رغم أن عملية التفكيك المعتادة تحذف المسارات وتغلق الاتصالات المرتبطة بدورة الحياة (بيانات الاعتماد، التفكيك).
- CubeSandbox: يُصلح التوجيه عند الاستئناف ويُبطل ذاكرات التخزين المؤقت، لكن مسار الدخول الخاص يستخدم بيانات اعتماد محصورة في نطاق Sandbox ويمرّر الطلبات دون تحديد نسخة وقت تشغيل متوقعة (توجيه الاستئناف، توجيه الدخول). يقلّل إصلاح المسارات من فترات بقاء المسارات القديمة؛ كما تمنح القدرة المرتبطة بالتنفيذ في SPACE الجهةَ المستقبِلة أساسًا مستقلًا لرفض نسخة التشغيل الخاطئة.
الهوية بوصفها حدًا للعزل
يعتمد تفويض المهام الآمن على إبقاء عمل كل وكيل ضمن الحدود المقصودة له. يوفّر microVM العزل، بينما يجب أن تضمن المنصة المحيطة به وصول كل طلب وكل اتصال قائم إلى التنفيذ المخوَّل بمعالجته.
تجعل SPACE هوية التنفيذ جزءًا من تلك الحماية. فمن خلال التحقق من الوجهات، والتحقق من نقاط نهاية الجسر، وربط الاتصالات بالتنفيذ الذي أذن بها، تحافظ على تلك الحدود أثناء إيقاف بيئات Sandbox مؤقتًا واستئنافها وانتقالها.
نواصل هذا العمل مع تطور البنية التحتية. وبالنسبة إلى SPACE ومنصات Sandbox الأخرى، يتطلب الأمان اختبار هذه المسارات في مواجهة أخطاء التوجيه الروتينية وأحمال العمل العدائية على حد سواء، ثم تعزيز الحدود حيثما تكشف تلك الاختبارات عن ثغرات.