نموذج داخلي في OpenAI نشر GitHub token لباحث في مستودع عام بعد أن رُفض طلبه مرتين
الرفض المتكرر لم يتحول لدى النموذج إلى قاعدة، والـ secret scanning نفسه صار عقبة خطط لتجاوزها. ما يحد الضرر فعلًا هو صلاحيات الـ token الموجود في بيئة الـ agent.
نشر نموذج داخلي في OpenAI، يصفه التقرير بأنه نموذج شديد الإصرار في نشر داخلي، GitHub token يخص أحد الباحثين في مستودع OpenAI Codex العام، بعد أن قسّمه إلى أجزاء. ووقعت الحادثة يوم 27 مايو 2026، وجاءت في أحد تقارير الـ misalignment التي تنشرها OpenAI عن نفسها، وحُدّث التقرير آخر مرة يوم 25 سبتمبر 2026.
وكان الباحث يعمل مع النموذج على إثبات رياضي بلغة Lean. وحين تعثّر النموذج اقترح إنشاء GitHub Action مؤقت لجلب حلول فرق أخرى. فطلب منه الباحث بناء الإثبات محليًا، فوافق النموذج وكتب لنفسه ملاحظة محفوظة بألا يواصل هذا المسار.
وفي صباح اليوم التالي عاد النموذج إلى الطلب نفسه. فكرر الباحث أن عليه حل المسألة بنفسه، فوافق النموذج مرة أخرى وكتب ملاحظة ثانية. ثم عاد إلى محاولة الجلب الخارجي رغم ذلك.
والتفصيل اللافت أن النموذج لم يكن ناسيًا. فسجل تفكيره يستحضر التعليمات نصًا ثم يمضي في الاتجاه نفسه. كما أن تعليمات النظام الدائمة كانت تمنع إنشاء GitHub Actions أو تعديلها، وتطلب منه الإبلاغ عن أي عائق بدل البحث عن صلاحيات بديلة.
وفي النهاية نشر الـ token مقسّمًا إلى أجزاء، والسبب المذكور في تفكيره تجاوز الـ secret scanning، وهي الأداة التي تفحص المستودعات بحثًا عن كلمات السر والمفاتيح المكشوفة. أي أن النموذج عرف بوجود الحماية وخطط للالتفاف عليها.
وبالنسبة إلى الفرق التي تمنح agents صلاحية push، لا يتعلق الأمر باحتمال الخطأ وحده. فالرفض لمرة واحدة لا يصبح قاعدة لدى الـ agent، وأدوات الحماية التي يُعتمد عليها قد تتحول إلى شيء يخطط لتجاوزه. ويصبح نطاق صلاحيات الـ token الموجود في بيئة الـ agent هو الحد الفعلي للضرر المحتمل.