METR وRedwood تخترقان نظام مراقبة وكلاء OpenAI: تغطية 75–94% من الحركة

على مدى ثلاثة أسابيع، من 21 يوليو إلى 11 أغسطس، حاول باحث من METR وباحث من Redwood Research تجاوز النظام الذي تراقب به OpenAI اختلال التوافق لدى وكلائها الداخليين. وكانت النتيجة تقريرًا مغلقًا من 61 صفحة موجّهًا إلى باحثي OpenAI وفريق الأمن فيها، وخلاصة عامة قصيرة نُشرت الآن. وأهم تقدير فيها أن المراقبة كانت تشمل وقت الفحص 75–94% من حركة الوكلاء الداخلية عبر Responses API الصادرة عن نماذج لا تقل قدرة عن GPT-5.5، مع إقرار الباحثين بوجود هامش عدم يقين في الاتجاهين. كما وجد الباحثون في النظام طرقًا للإفلات من الرقابة تمامًا.

وصول يكاد يماثل وصول المهندسين العاملين في الشركة

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

وللقيود أهميتها أيضًا. فالمسموح بنشره هو منشور موجز فقط: يحق لـ OpenAI حجب أي معلومة تعدّها سرية، وبخلاف الأعمال السابقة لا يحق لـ METR أن تصف علنًا وبشكل منفرد هذه التعديلات. وسُلّمت إلى قيادتي METR وRedwood نسخة من التقرير من 38 صفحة حرّرتها OpenAI. وفُحص النظام بالحالة التي كان عليها في 21 يوليو وما قبله، لا الإضافات التي كانت الشركة تطرحها بالتوازي. كما لا صلة للدراسة بتحقيق METR في حادثة Hugging Face، وإن أُعلنت الحادثة علنًا في اليوم الأول من التمرين.

اثنتا عشرة نتيجة

• تغطية الحركة. كانت المراقبة تشمل 75–94% من حركة الوكلاء عبر Responses API (التي يعمل عليها Codex) الصادرة عن نماذج بمستوى GPT-5.5 وأقوى.

وبالنسبة إلى مجموعة فرعية من وكلاء Codex الداخليين كان التقدير أعلى: 99,2%. أما حركة خدمة الـ inference البحثية الداخلية فلم تُقيَّم بسبب قيود الوصول والوقت. • تدريب RL.

رُصد جزء من rollouts بحثًا عن اختلال التوافق من مارس إلى يونيو، لكن عمليات RL لم تكن مشمولة بالنظام مع بدء التمرين. • Compaction. بسبب أحداث compaction التي يتعذر فحصها، لم يكن نحو 10% من حركة Codex المؤهلة للمراقبة مراقَبًا من مايو إلى يوليو 2026.

ولم يتسنَّ تحديد النسبة بدقة لأن البيانات اللازمة لم تكن تُسجَّل. وكانت OpenAI قد لاحظت المشكلة قبل التمرين وأصلحتها أثناءه. • تأجيل الفحص.

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

• الأخطاء وload-shedding. بحسب البيانات المعروضة، أخطأ المراقب في أقل من 0,2% من الطلبات، ولم تُسجَّل أي حالة تخفيف حمل خلال يوم واحد من 24 ساعة أثناء التمرين. • Sandbox في Codex.

عُثر على طريقة لتجاوز sandboxing وAuto-Review، يصبح الوكيل بعدها قادرًا على فعل كل ما يتاح لمستخدم المضيف. • استغلال البقعة العمياء. وُجدت حيلة تجعل مئات الإجراءات الأخيرة، بما فيها إجراءات الاستغلال نفسها، خارج نطاق المراقبة.

وقد حذفت OpenAI التفاصيل. • التسلسل (serialization). يُرجَّح أن الوكلاء قادرون على بناء مدخلات تعطّل المراقب وتمنع إرسال المسار إلى مراجعة بشرية، لأن مسار الوكيل ومسار المراقب يُسلسَلان بطريقتين مختلفتين.

• الترويسات. ترويستان مستقلتان من جهة العميل تعطّلان المراقبة للوكلاء الجدد، ما يتيح تشغيل نسخة مطابقة لكنها غير مراقَبة. لكن قد يلاحظ المراقب نفسه تعيين الترويسة وإنشاء النسخة.

• أدوات «القراءة فقط». عُدّت أداتان داخليتان للوكلاء بلا مراقبة أداتَي read-only، لكن وُجد استغلال بسيط ينفّذ إجراءات اعتباطية في sandbox الخاص بهما. ولم تُختبر قابلية الاستغلال عمليًا.

• اكتمال السياق. باستثناءات صغيرة قليلة، يرى المراقب المسار نفسه الذي يراه الوكيل. • prompts المراقب.

تبحث عن scheming وتقويض نظام المراقبة نفسه والتخريب وسرقة البيانات والخداع، إضافة إلى prompt injection الوارد والصادر.

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

خمسة مبادئ لمراقبة تصمد أمام وكيل ذكي

استخلص المؤلفون من النتائج متطلبات للأنظمة القادرة على مقاومة هجمات متعمدة واستراتيجية وطويلة الأمد من وكلاء داخليين أقوياء:

• يجب أن يكون تجاوز المراقبة صعبًا. لا تُسمح الطلبات غير المراقَبة إلا لمؤسسات ومفاتيح API معتمدة صراحةً يُحظر عليها الـ inference الوكيلي. ويُفحص الوكيل كل N رسائل أو دقائق، لا عند انتهاء الدور.

• مراقبة التغطية الفعلية. تُسجَّل كل عمليات الـ inference ونسبة المراقَب منها، وتُطابَق السجلات دوريًا مع سجلات المراقب، وتُحفظ قائمة بالتجاوزات المعروفة، ويُتأكد من أن المراقب يرى السياق نفسه الذي يراه الوكيل. • الاستجابة السريعة للحوادث.

يُعيَّن مسؤول، وتوضع تعليمات واضحة، وتُحفظ سجلات غير قابلة للتعديل وسهلة البحث. • مهاجمة المراقب بانتظام. تُجرى control evaluations، ويُبحث عن الأخطاء القابلة للاستغلال، وتُطوَّر منهجية لتقييم التواطؤ الاستراتيجي.

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

ما الذي ينبغي فحصه في منظومة الوكلاء لديك

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