كيف تحبس شيفرة وكيل الذكاء الاصطناعي: subprocess وDocker وmicroVM — ثلاثة مستويات من الحماية

لقد منحتَ الوكيل أداة «نفّذ شيفرة Python»، وفي تلك اللحظة لم يعد لديك مجرد مساعد، بل تنفيذ شيفرة عن بُعد، وإن كان بطلب من النموذج. فالنموذج قد يخطئ، وقد يتلقى تعليمات ضارة من صفحة أو ملف دُسَّ له. لذلك فالسؤال ليس «هل الوكيل ذكي»، بل «ما الذي يمكن أن يصل إليه برنامج سيئ عندما يبدأ التشغيل». يجيب مؤلفو التحليل المنشور على Machine Learning Mastery عن ذلك عمليًا: يبنون ثلاث بيئات معزولة (sandbox) ويُجرون على كل منها الهجمات نفسها.

أداة واحدة وواجهات خلفية قابلة للتبديل

البنية بسيطة. يعرف الوكيل أداة واحدة هي run_python: تستقبل سلسلة نصية تحتوي على الشيفرة وتعيد stdout وstderr ورمز الخروج. ولا تُنفَّذ شيفرة النموذج أبدًا داخل عملية الوكيل نفسه، بل تُرسَل إلى كائن البيئة المعزولة الذي يملك الدالة run(code)، ويصلح لذلك أي صنف يملك هذه الدالة. ولهذا فإن تغيير مستوى العزل لا يتطلب المساس بمنطق الوكيل: يكفي استبدال الواجهة الخلفية. ويُعلَّم رمز الإرجاع المختلف عن الصفر على أنه خطأ، فيراه النموذج ويستطيع تصحيح نفسه.

ومن مبادئ مدونة Docker المهمة، والتي يطبقها المؤلفون على كل المستويات: الوصول إلى الملفات وسياسة الشبكة والأسرار تحدَّد بواسطة البنية التحتية قبل تشغيل الوكيل، لا بواسطة الوكيل نفسه.

ثلاثة حدود

Subprocess هو الخيار الأخف. وهو عملية فرعية مع حدود على زمن المعالج والذاكرة (فضاء العناوين) وحجم الملفات المكتوبة. وحوله:

• التشغيل في الوضع المعزول python -I داخل مجلد مؤقت؛
• بيئة نظيفة بلا مفاتيح API ولا مجلد منزلي؛
• unshare --net، أي شبكة خاصة فارغة؛
• توجيه المخرجات إلى ملفات، ليحمي حدّ حجم الملف أيضًا من سيل print؛
• عند انتهاء المهلة تُقتل مجموعة العمليات بأكملها.

وإذا تعذّر على المُنشئ تفعيل عزل الشبكة فإنه يفشل مع خطأ بدل أن يترك الشبكة مفتوحة بصمت. وتحت صلاحيات root تُخفَّض صلاحيات الشيفرة أولًا إلى المستخدم nobody.

لكن لهذا المستوى تحفظًا صريحًا: تبقى النواة ونظام الملفات للمضيف. فالشيفرة تعمل باسمك على نظام ملفاتك ولا تُخفي ملفاتك. أما حدّ عدد العمليات فيحتسب جميع عمليات المستخدم، ولذلك لا معنى له إلا لمستخدم منفصل، ويُتجاوَز على الحاسوب المحمول العادي.

حاوية Docker تضيف فضاءات الأسماء وcgroups، لكنها تظل عمليات على نواة المضيف. وتقول وثائق Docker صراحة إن الحاوية بلا إعدادات صريحة ليس لها حدود للموارد، ولذلك تُحدَّد في البيئة المعزولة الذاكرة وعدد المعالجات وعدد العمليات (في المثال: 256 ميغابايت ومعالج واحد و64 pid). وتحدث عمليات هروب فعلًا: ففي نوفمبر 2025 أتاحت ثلاث ثغرات في runc الخروج من الحاوية.

MicroVM على Firecracker (في المثال عبر E2B) تمنح كل بيئة معزولة نواتها الخاصة خلف مراقب (hypervisor). تسمّي Docker ذلك حدًّا عتاديًا، وتؤكد AWS أن النواة في Lambda على Firecracker لا تُشارك بين الجلسات. وهو الخيار الأغلى من حيث زمن الاستجابة، ويتطلب حساب E2B مع مفتاح.

ما العمل بهذا كله

يختبر المؤلفون كل مستوى ببرامج عدائية متطابقة: استنزاف المعالج والذاكرة والعمليات والقرص، ومحاولات قراءة الملفات والخروج إلى الشبكة. ثم يقيسون في bench.py ثمن تعزيز العزل من حيث زمن الاستجابة. ولا توجد أرقام للقياسات في الجزء المتاح من المادة، فشغّل الاختبار على جهازك: فالتأخير يعتمد بشدة على البيئة.

والمنطق العملي للاختيار كالتالي:

• Subprocess يصلح للتجارب المحلية وللشيفرة التي تثق بها تقريبًا. يتطلب Linux أو WSL.
• Docker بأعلام صارمة يناسب الأدوات الداخلية التي تقبل فيها مخاطرة الهروب.
• MicroVM هي الخيار للمدخلات الغريبة غير الموثوقة وللمنتجات متعددة المستأجرين، حيث يعني الهروب حادثًا أمنيًا.

والأهم: لا تترك للوكيل قرار بيئته المعزولة. فالأسرار والشبكة والملفات يحدّدها من ينشر البنية التحتية. وإن أردتَ حلًّا جاهزًا لا مبنيًّا يدويًا، فلدى المؤلفين مقال منفصل عن خمس بيئات معزولة مستضافة؛ أما هنا فيُجمَّع كل شيء يدويًا ليتضح ما تفعله هذه المنصات فعلًا تحت الغطاء.