عزل وكلاء الذكاء الاصطناعي (Agent Sandboxing): لماذا لم تعد الآلة الافتراضية كافية في 2026؟

في الثامن من سبتمبر 2026 نُشرت ثغرة حملت الرقم CVE-2026-82533 بدرجة خطورة 9.4 من 10، ومضمونها بسيط إلى حدّ مقلق: وكيل ذكاء اصطناعي كان قادراً على تعطيل الساندبوكس الخاص به بنفسه عبر أمر واحد فقط. لم يكن الأمر اختراقاً معقّداً ولا سلسلة استغلال طويلة — مجرد استدعاء غيّر إعداد الجلسة إلى وضع صلاحيات كاملة، فسقطت معه كل نوافذ التأكيد التي كان من المفترض أن تحمي المستخدم.

الحادثة ليست استثناءً، بل عرَض لمشكلة أوسع: نحن نمنح الوكلاء صلاحية تشغيل أوامر حقيقية على أنظمة حقيقية، ثم نفترض أن طبقة عزل واحدة تكفي. هذا المقال يشرح لماذا لا تكفي، وما البديل العملي.

لماذا يختلف الوكيل عن أي برنامج آخر؟

البرنامج التقليدي حتمي (Deterministic): تعطيه المدخل نفسه فيعطيك المخرج نفسه، ويمكنك مراجعة كل مسار تنفيذ فيه. الوكيل المبني على نموذج لغوي مختلف جوهرياً في ثلاث نقاط:

• غير حتمي: قد يختار في التشغيلة الثانية مساراً لم يخطر ببالك في الأولى.
• يتأثر بالمدخلات الخارجية: صفحة ويب أو ملف أو نتيجة أداة يمكن أن تحمل تعليمات تغيّر سلوكه.
• يملك أدوات فعلية: طرفية، شبكة، نظام ملفات، ومفاتيح وصول أحياناً.

النتيجة أن ضبط السلوك بالتعليمات والسياسات المكتوبة داخل الطلب وحده غير كافٍ — لأن ما يقيّد الوكيل هنا هو نصّ، والنصّ قابل للتجاوز بنصّ آخر.

القاعدة التي استقرّ عليها المجال في 2026: لا تثق في ما يقوله الوكيل إنه سيفعله، بل في ما تسمح له البنية التحتية بفعله أصلاً.

المشكلة مع "شغّله في آلة افتراضية وخلاص"

النصيحة الشائعة لسنوات كانت: ضعه في حاوية أو آلة افتراضية وانتهى الأمر. المراجعات الأمنية الحديثة تشكّك في هذا الافتراض لسبب واضح — مساحة الهجوم كبيرة جداً.

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

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

أين يفشل العزل الواحد عملياً؟

السيناريو	هل يوقفه الساندبوكس؟
الوكيل يحاول الكتابة خارج مجلد المشروع	نعم
الوكيل يمسح بيانات داخل قاعدة أُعطي مفتاحها	لا
الوكيل ينفّذ تعليمات خبيثة قرأها من صفحة ويب	لا، إن كانت الأداة مسموحة
الوكيل يسرّب سرّاً عبر طلب شبكة مسموح	لا
الوكيل يعطّل إعداد العزل من داخل الجلسة	لا، إن كان الإعداد في متناوله

الصفّ الأخير هو بالضبط ما حدث في ثغرة سبتمبر: العزل كان موجوداً، لكن مفتاح إيقافه كان داخل الغرفة.

نموذج الطبقات: كيف تعزل وكيلاً فعلياً

المقاربة العملية اليوم هي الدفاع بالطبقات لا الحاجز الواحد. أربع طبقات تغطّي معظم الحالات:

1. عزل التنفيذ

شغّل الوكيل في بيئة منفصلة فعلاً — حاوية أو آلة افتراضية خفيفة (microVM) — بنظام ملفات خاص بها، ولا تشارك معها إلا المجلد الذي يحتاجه المشروع. الأهم: إعدادات العزل تُدار من خارج البيئة، لا من داخلها. إن كان الوكيل يستطيع تعديل قيود نفسه، فهي ليست قيوداً.

2. تقييد الشبكة

هذه الطبقة الأكثر إهمالاً والأعلى عائداً. امنع الاتصال الصادر افتراضياً واسمح فقط بقائمة نطاقات محدّدة (مستودع الحزم، واجهة النموذج، ما يحتاجه المشروع). معظم سيناريوهات تسريب البيانات تحتاج قناة خروج — أغلق القناة تسقط السيناريوهات معها.

3. أقلّ صلاحية ممكنة للأسرار

لا تمرّر ملف البيئة كاملاً لأن الوكيل "قد يحتاجه". مرّر المتغيّر المطلوب وحده، بمفتاح مؤقت إن أمكن، وبصلاحية قراءة فقط حين يكفي ذلك. المفتاح الذي لم يدخل البيئة لا يمكن تسريبه منها.

4. مراجعة بشرية عند نقاط اللاعودة

ليست كل عملية متساوية. اقرأ ملفاً، شغّل اختباراً، ابنِ المشروع — كلها قابلة للتراجع. أما الحذف، والدفع إلى الفرع الرئيسي، والنشر، وأي تعديل على بيانات الإنتاج، فنقاط لا رجعة فيها وتستحق تأكيداً بشرياً صريحاً، مهما بدا ذلك مزعجاً.

قائمة تحقّق سريعة قبل تشغيل وكيل على مشروعك

1. هل يعمل في بيئة معزولة يمكن حذفها بالكامل دون أثر؟
2. هل مجلد العمل محدود بالمشروع وحده، لا بالجهاز كله؟
3. هل الشبكة الصادرة مقيّدة بقائمة سماح؟
4. هل الأسرار الممرَّرة هي الحد الأدنى، لا ملف البيئة كاملاً؟
5. هل بيانات الإنتاج خارج متناوله تماماً؟
6. هل تملك سجلّاً بكل أمر نفّذه، قابلاً للمراجعة لاحقاً؟
7. هل تستطيع التراجع عن كل ما فعله بأمر واحد (فرع Git منفصل مثلاً)؟
8. هل إعدادات العزل نفسها خارج قدرته على التعديل؟

إن كانت إجابتك "لا" على السابع أو الثامن تحديداً، فأنت لا تملك عزلاً بل ترتيباً مريحاً.

أسئلة شائعة

هل الحاوية (Docker) كافية لعزل وكيل برمجة؟

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

أشتغل على مشروع شخصي صغير — هل أحتاج كل هذا؟

لا تحتاج الطبقات الأربع كاملة، لكن اثنتين منها تكلفتهما دقائق وعائدهما كبير: اجعل الوكيل يعمل على فرع Git منفصل حتى يكون التراجع أمراً واحداً، وابعد بيانات الإنتاج ومفاتيحها عن بيئته تماماً. هاتان الخطوتان وحدهما تمنعان أغلب الحوادث الشائعة.

ما الفرق بين العزل ومراجعة ما ينتجه الوكيل؟

العزل يحدّ من حجم الضرر الممكن، والمراجعة تكتشف الخطأ في النتيجة. الأول يحميك من عملية مدمّرة، والثاني من كود يعمل لكنه خاطئ أو غير آمن. الاثنان مطلوبان، وأحدهما لا يغني عن الآخر.

الخلاصة

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

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