OpenAI تشدد حماية Codex بعد خلل حذف الملفات

تقول OpenAI إن تحديث Codex يسد مسارًا خطيرًا لحذف الملفات

أصدرت OpenAI تحديثًا أمنيًا لـ Codex بعد أن أفاد مستخدمون بأن GPT-5.6 Sol كان قادرًا على حذف ملفات حقيقية من دون إذن أثناء تنفيذ مهام مستقلة. وتقول الشركة إن المشكلة جاءت من أمر تنظيف كان يفترض أن يزيل ملفات العمل المؤقتة، لكنه كان يمكن أن يشير إلى بيانات المستخدم الفعلية عندما تُدار متغيرات النظام على نحو غير صحيح.

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

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

ما الذي تقول OpenAI إنها غيّرته

يصف النص المصدر عدة إجراءات وقائية وضعتها OpenAI الآن. ويقال إن Codex يتحقق من أهداف الحذف قبل تنفيذها، وينشئ مجلدات مؤقتة جديدة، ويمنع إساءة استخدام متغيرات النظام. كما أضافت الشركة فحوصات أكثر صرامة تهدف إلى اكتشاف أوامر الحذف الخطرة قبل تنفيذها.

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

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

لماذا تبقى بيئة العزل أساسية

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

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

وهذا يضغط على مطوري الأدوات لكي يفعلوا أكثر من مجرد الاعتماد على تعليمات بمستوى المطالبة مثل “كن حذرًا” أو “اطلب الإذن قبل الحذف”. هذه القواعد مفيدة، لكنها ضوابط رخوة ما لم يفرضها النظام المحيط. وما تصفه OpenAI هنا هو انتقال نحو ضوابط أشد: التحقق من المسارات، ومجلدات مؤقتة آمنة، وفحص أشد للأوامر، وتمييز أوضح بين التشغيل داخل العزل والتشغيل مع وصول كامل.

ماذا يقول ذلك عن تصميم الوكلاء

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

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

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

ما الذي ينبغي أن يستخلصه المستخدمون من التحديث

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

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

• تعزو OpenAI الخلل إلى أمر تنظيف كان يمكن أن يستهدف بيانات مستخدم حقيقية.
• تقول الشركة إن Codex يتحقق الآن من أهداف الحذف وينشئ مجلدات مؤقتة جديدة.
• تهدف الفحوصات الأشد إلى اعتراض أوامر الحذف الخطرة قبل تنفيذها.
• وتقول OpenAI أيضًا إن تفعيل وضع الوصول الكامل بالخطأ أصبح محظورًا.

هذه المقالة مبنية على تقرير The Decoder. اقرأ المقال الأصلي.