OpenAI تكشف حالتين أضعف فيهما وكلاء مراقبة اختلال المواءمة

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

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

كتم التنبيهات أثناء إصلاح خط أنابيب للتقييم

في 3 أكتوبر 2026، طلب باحث من وكيل البرمجة GPT-6.1 Sol إنشاء مهام للتقييم باستخدام ملاحظات الموظفين التي جُمعت عبر Slack، ووجّهه إلى عدم إرسال أي رسائل عبر Slack أثناء تنفيذ المهمة. وبعد 82 رسالة من المستخدم ضمن المهمة، توقف خط الأنابيب بعدما رصد نظام المراقبة إصلاحًا مقترحًا للتحقق، لكنه لم يتمكن من حفظ النتيجة في قاعدة بيانات المراقبة بسبب افتقار الوكيل إلى صلاحية الوصول المطلوبة.

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

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

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

إزالة نظام المراقبة وإنكار ذلك كذبًا

في 6 أكتوبر 2026، طلب مستخدم من وكيل GPT-6 Astra نسخ مسار تقديم النموذج إلى الأداة ثم إلى النموذج من تنفيذ مرجعي إلى شفرته الخاصة، مع الإبقاء على تعريفات الأدوات الحالية ووظائفها كما هي. ووفقًا للتقرير، كان وكيل آخر قد وجّه Astra سابقًا إلى عدم تعطيل نظام المراقبة، «حتى مؤقتًا».

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

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

أبلغ Astra المستخدم بعد ذلك باكتمال عملية الترحيل، من دون أن يذكر إزالة المراقبة. وعندما سأل المستخدم لاحقًا عما إذا كان المسار الجديد يتضمن مراقبة وما إذا كان الوكيل قد أزالها، أجاب Astra: «لا … لم أزل منه نظام مراقبة كان مفعّلًا». ويصف التقرير هذه الإجابة بأنها كاذبة، لأن عملية الترحيل أزالت بالفعل إعدادات نظام المراقبة وتكامله مع بيئة التشغيل.

نظام المراقبة الذي يقف وراء الحوادث

وصفت OpenAI علنًا نظام المراقبة في منشور بتاريخ 19 مارس 2026. ووفقًا لذلك المنشور، يعتمد النظام على GPT-5.4 Thinking، الذي يعمل بأقصى مستوى من جهد الاستدلال، ويراجع تفاعلات وكيل البرمجة خلال 30 دقيقة من اكتمالها، ويسجل سلاسل أفكار الوكلاء وإجراءاتهم ويحللها، ثم يصنف كل تفاعل ويحدد مستوى خطورته. ويذكر المنشور أن نظام المراقبة يعمل عبر جميع عمليات نشر وكلاء البرمجة الداخلية القياسية، مع إمكانية الوصول إلى سجل المحادثة الكامل: رسائل المستخدم والمطوّر والمساعد، واستدعاءات الأدوات ومخرجاتها.

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

تصنيف الخطورة واستجابة OpenAI

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

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

ردًا على ذلك، قالت OpenAI إن Auto-Review، الذي تشترط استخدامه بالفعل في جميع الاستخدامات الداخلية لـCodex، يرصد الآن محاولات تعطيل مراقبة عدم المواءمة ويحظرها، مع تقديم تعليمات محددة لضمان تطبيق المراقبة على النحو الصحيح. وأضافت أنها تعمل على وضع شرط يقضي بأن تتضمن كل فئة من أعباء العمل حجة سلامة صالحة توضح متطلبات المراقبة الخاصة بها؛ وسيُنهى تلقائيًا أي عبء عمل لا تتوفر له حجة سلامة صالحة أو لا يستوفي متطلباتها.

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