أطلقت OpenAI للتو codex-security على GitHub – وهو ماسح ضوئي يمكن تثبيته عبر npm، يقوم بإجراء تحليل ثلاثي المراحل للمستودع (repository) ويحاول إصلاح الأخطاء تلقائيًا.

ما يتجاهله هذا الإطلاق هو خلل أعمق كشفته مؤخرًا عروض توضيحية لتجاوز البيئة المعزولة (sandbox bypass). فقد أظهر الباحثون أن الوكلاء (agents) الذين يعملون داخل بيئات "مغلقة" لأدوات مثل Cursor وCodex CLI وGemini CLI وGoogle Antigravity لا يزال بإمكانهم الهروب من الحماية المقصودة عبر استغلال الواجهات التي تربط البيئة المعزولة بالنظام المضيف. ولا يتطرق ماسح OpenAI الجديد إلى سطح الهجوم هذا.

كيف تعمل عمليات التجاوز

يظل الوكلاء داخل حاوياتهم (containers)، ولكن كل ما يكتبونه على القرص يتم الوثوق به فورًا من قبل المساعدين الخارجيين – مثل git hooks وPython extensions وDocker daemons والخدمات المماثلة. تقوم هذه المساعدات بقراءة الملفات، والتعامل معها كملفات مشروعة، وتنفيذها على النظام المضيف دون مطالبة المستخدم.

  • سمحت Cursor لوكيل بتسجيل git hook يعمل خارج البيئة المعزولة.
  • فشل Codex CLI في التحقق من صحة المعلمات (parameters) في أوامر git، مما فتح مسارًا للتنفيذ التعسفي.
  • حصل العديد من الوكلاء على وصول مباشر إلى Docker socket، وهو نقطة دخول مميزة تسمح للكود بتشغيل حاويات على الجهاز المضيف.
  • سمحت ثغرات DuneSlide للمهاجم بالكتابة فوق المكون الذي يفرض البيئة المعزولة، مما أدى فعليًا إلى إزالة الجدار تمامًا.

في كل حالة، وصل الاستغلال بصمت – سواء كان نتيجة بحث ويب أو استجابة من أداة multi-choice-prompt (MCP) استهلكها الوكيل. تم تنفيذ الحمولة الضارة (malicious payload)، ثم اختفت، ولم تظهر أبدًا في فحص الكود الثابت (static code scan).

لماذا يخطئ أداة OpenAI الهدف

يركز codex-security على التحليل الثابت (static analysis): حيث يقوم بفحص ملفات المصدر التي ترفعها (commit)، ويحدد الأنماط غير الآمنة، ويمكنه إعادة كتابتها تلقائيًا. هذا النهج يكتشف الكود المهمل أو الخطير قبل إرساله، لكنه يفحص الكود الذي ترسله، بينما تحدث الهجمات في بيئة التشغيل (runtime environment) الخاصة بالوكيل نفسه.

تُظهر عمليات تجاوز البيئة المعزولة أن الخطر الحقيقي يكمن في جسر وقت التشغيل (runtime bridge) بين بيئة الذكاء الاصطناعي المعزولة وبقية سلسلة أدوات المطور (toolchain). لا يحتاج المهاجم إلى حقن كود ضار في المستودع؛ بل يحتاج فقط إلى إقناع الوكيل المعزول بكتابة ملف سيقوم إجراء خارجي بتنفيذه لاحقًا.

من يربح ومن يخسر

  • المطورون
  • موردو الأدوات
  • OpenAI
  • المهاجمون

ما يمكن للمجتمع فعله الآن

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

  • تثبيت إصدارات الوكيل (Pin agent versions) وقراءة سجل التغييرات قبل الترقية. يمكن للإصدارات الجديدة أن تفتح عن غير قصد hook أو socket جديدًا.
  • تعامل مع عملية "الاستنساخ والاستكشاف" (clone and explore) كأنها تشغيل لكود غير معروف. لا توجه وكيلًا أبدًا إلى مستودع لا تتحكم فيه دون عزل إضافي.
  • راجع كل أداة مساعدة (git hooks، Python extensions، الوصول إلى Docker). إذا كانت الأداة قادرة على تعديل دليل (directory) أو رابط رمزي (symlink) بناءً على مخرجات الوكيل، فافترض أنه يمكن تحويلها إلى سلاح.
  • قم بإزالة الوصول إلى Docker socket من البيئة المعزولة.
  • اسأل: ماذا يقرأ ماذا؟. قم برسم مخطط لتدفق البيانات من البيئة المعزولة إلى المضيف؛ يجب فحص أي عملية تستهلك الملفات التي يكتبها الوكيل بدقة.

وجهة نظر معارضة: لماذا لا يزال codex-security مهمًا

يحسن الماسح الضوئي جانبًا واحدًا من المشكلة، لكنه لا يغني عن الحاجة إلى تحصين جسر وقت التشغيل.

ما يجب مراقبته لاحقًا

  • أدلة التحصين التي يقودها المجتمع والتي تصنف الإعدادات الآمنة لسلاسل أدوات المطورين الشائعة عند اقترانها بوكلاء الذكاء الاصطناعي.

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