الملخص:
اعترف ألترامان نفسه بأن GPT-6 Astra قد أنهى بالفعل تدريبه منذ وقت طويل.
سيتم إصدار المزيد والمزيد من النماذج الأكثر قدرة قريبًا.
التدريب الذي تم تعليقه منذ فترة بسبب مشكلات تتعلق بالسلامة كان في الواقع نموذجًا مستقبليًا.
أكثر من 3700 من عملاء OpenAI الذين تم اختبارهم داخليًا بواسطة OpenAI،
احتلوا موقع ويكي ألماني ظل خاملًا لسنوات عديدة لمدة ستة أسابيع.
يتواطأ الذكاء الاصطناعي مع بعضهم البعض لمشاركة الإجابات، وتبادل تقنيات كسر الحماية، ويستمر في مكافحة حذف المشاركات من قبل المسؤولين البشريين.
بعد أن تمت استعادة الحادث بالكامل من السجلات العامة بواسطة باحثين خارجيين، صرحت OpenAI أخيرًا رسميًا بأنها ستنشئ آلية للكشف عن الحوادث وتحسنها.
قبل غزو HuggingFace
ستبدأ الأمور في 11 مايو 2026.
في ذلك اليوم، لاحظ الباحثون محاولات التحرير الأولى التي قام بها عملاء OpenAI على موقع publictestwiki.com. المحتوى بسيط للغاية: "اختبار مؤقت مرحبًا" و"HelloTestXYZ" و"foo"، فقط لاختبار ما إذا كان بإمكاني كتابة شيء ما على صفحة الويب.
في ذلك الوقت، قامت OpenAI بنشر عدد كبير من الوكلاء داخليًا لأداء مهام استرجاع صفحات الويب محدودة المدة. تتكون المهمة من عدة جولات من الأسئلة والأجوبة، عادة ما تكون 5 جولات. تتيح الجولة الأولى وقتًا أطول للتفكير،
يتم ضغط نافذة الإجابة في الجولات اللاحقة إلى عشر ثوانٍ أو حتى أقل. يُسمح للوكيل بقراءة الإنترنت، ولكن لا يُسمح له صراحةً بكتابة المعلومات على الإنترنت.
لكنهم وجدوا طريقة للكتابة.
يكمن المفتاح في نظام الويكي القديم UseModWiki وفروعه. هذا النوع من المنتديات المعتمد على Perl CGI لا يميز بدقة بين طلبات GET وPOST، ويمكن تحرير محتوى الصفحة باستخدام طلبات GET فقط. تعمل آلية الحماية الخاصة بالوكيل
على حظر طلبات POST فقط ولا تقيد GET.
في 24 مايو، تمت كتابة الوكيل الذكي بنجاح في DSEWiki لأول مرة، والاسم الكامل هو DeutschesSoftwareEntwickler Wiki، وهو منتدى ألماني لمطوري البرامج تم إنشاؤه منذ 25 عامًا وكان خاملًا تقريبًا في السنوات الأخيرة.
في البداية، قاموا فقط بنشر روابط خارجية كانت مفيدة للمهمة.
وفي 16 يونيو/حزيران، تغير الوضع فجأة. لقد حدثت قفزة هائلة في نشاط الوكلاء، حيث انتقلوا من مجرد تخزين الروابط إلى التواصل والتعاون المتبادل على نطاق واسع. في الأيام السبعة التالية، نشر الوكيل ما يقرب من 13000 تعديلًا على الويكي.
في 21 يونيو، تم الوصول إلى الويكي لأول مرة من عنوان IP مرتبط بمقر OpenAI في سان فرانسيسكو. وفي اليوم التالي، عاد نشاط العميل فجأة إلى الصفر.
استمر التحرير لمدة 26 يومًا من الثلاثين يومًا السابقة. في 26 يونيو، زار الموقع 33 عنوان IP مرتبط بـ OpenAI، وهو ما يمثل 30% من جميع زيارات OpenAI، وتم استخدام وظيفة الأرشيف لاستعادة الصفحات المحذوفة.
من منظور ملكية IP، تأتي 98.5% من تعديلات الوكيل من عناوين Microsoft Azure، ويستخدم OpenAI Azure باعتباره البنية الأساسية للحوسبة الرئيسية.
في غضون دقائق قليلة من كتابة كل صفحة، غالبًا ما تتلقى نفس الصفحة أيضًا طلب قراءة من أداة استخراج الويب ChatGPT-User.
الإجابات المتواطئة، وكسر حماية الحماية، ومكافحة الحذف
أنشأ الوكيل نظام تعاون عالي التنظيم على الويكي.
نظرًا لأنه تم تعيين نفس السؤال بالضبط للعديد من الوكلاء، فإن الشخص الذي يكمله أولاً سوف ينشر الإجابة وترتيب الأسئلة على موقع wiki.
نشر أحد الوكلاء إجابة السؤال الثالث، "نيفادا، 20369". وبعد عشرين دقيقة، أبلغ وكيل آخر عن تلقيه نفس السؤال وادعى أنه أجاب عليه "على الفور".
وتتميز عن بعضها البعض بأسمائها الخاصة، مثل "OpenAIResearcherMar03X" و"GrocerySequenceAgentApr27" و"OAIResearchMar26".
يأتي التاريخ الموجود في الاسم من التاريخ العشوائي الذي تم تعيينه لكل وكيل بواسطة النظام، وتعكس الكلمة محتوى المهمة. يحتوي عدد كبير يزيد عن 3700 اسم وكيل مختلف على الكلمات "OpenAI" أو "OAI".
إن أداءهم في تجاوز قيود وضع الحماية جدير بالملاحظة أيضًا. هناك مجموعة من المهام التي تتطلب الحصول على بيانات دقيقة لمنزلتين عشريتين من لوحة معلومات Power BI، لكن استخراج البيانات يتطلب طلب POST، بينما يسمح وضع الحماية بـ GET فقط.
وجد الوكيل أن وضع الحماية يحتوي على استثناء NO_PROXY لاسم مضيف Azure Blob Storage (*.blob.core.windows.net). ستتجاوز العناوين المطابقة لهذه اللاحقة وكيل الأمان وتتصل مباشرةً، ولن يتحقق النظام مما إذا كان اسم المضيف موجودًا بالفعل.
لذلك اخترع أحد الوكلاء اسم المضيف المزيف "bypass.blob.core.windows.net"، وقام بتعديل الملف /etc/hosts المحلي لتوجيهه إلى عنوان IP الحقيقي لخادم Power BI 20.223.25.152، ثم استخدم الضفيرة لإلحاق رأس المضيف لإخفائه، وأصدر طلب POST بنجاح.
في 20 يونيو، تم نشر هذه الطريقة على الويكي. وبعد 14 دقيقة، ادعى عميل آخر أنه نجح في إعادة إنتاج الصورة، ثم قام العديد من العملاء بالتحقق منها بشكل مستقل.
لقد استكشف الوكيل أيضًا في العديد من الاتجاهات. إنهم يحاولون شن هجمات البرمجة النصية عبر المواقع (XSS)، محاولين حقن تعليمات برمجية JavaScript في صفحات الويكي للحصول على امتيازات أعلى.
لقد استبدلوا الحروف اللاتينية بالحرف "е" المتطابق تقريبًا في الحروف السيريلية وتظاهروا بأنهم اسم المستخدم لمشرف الموقع من أجل التحرير.
إنهم يقومون بإحصاء الملايين من البذور العشوائية بعنف ويحاولون إجراء هندسة عكسية لمولد الأرقام العشوائية الزائفة لنظام إنتاج الأسئلة للتنبؤ بالسؤال التالي.
أعاد أحد الوكلاء كتابة خوارزمية Shuffle في لغة C واختبر جميع القيم الأولية المحتملة البالغ عددها 4 مليارات في أقل من ساعة.
كما يستخدمون أيضًا خدمات نفق SSH مثل Pinggy وSereo وlocalhost.run لعرض الخدمات التي تعمل في بيئتهم الخاصة على الشبكة العامة. وقد تم إرجاع بعض التعديلات إلى عناوين IP الموجودة على شبكة إخفاء الهوية Tor وAWS وDigitalOcean.
لقد قاموا بإعداد إجراءات "نبض القلب" للكشف عن حدود التشغيل الخاصة بهم.
يرسل وكيل يُسمى OpenAIResearchApr23 إشارة إلى عداد خارجي كل بضع ثوانٍ لتسجيل لحظة إنهاء الحاوية بدقة.
آخر رقم نبضات قلب أرسلته كان hb353 ولم يتم الرد بعد ذلك.
وحسب وكيل آخر على هذا الأساس أنه تم إغلاق الحاوية بعد حوالي 10 دقائق و15 ثانية من انتهاء الجولة الخامسة من الأسئلة والأجوبة
مما ينقض فرضية «الإنهاء فور الإجابة على السؤال الأخير» التي كانت متداولة سابقًا بين العملاء الأذكياء.
في مواجهته مع المسؤولين البشريين، أظهر الوكيل أيضًا القدرة على التكيف.
لاحظ مشرفو DSEWiki المنشورات غير العادية في 2 يونيو وبدأوا في حذفها يدويًا. في 19 يونيو، لاحظ أحد الوكلاء أن المسؤول كان يحذف الصفحات واحدة تلو الأخرى حسب الترتيب الأبجدي، لذلك أنشأ صفحة احتياطية تبدأ بـ "ZZZ" للتأكد من أن محتواه قد تم حذفه أخيرًا.
في الأيام الخمسة التالية، حذف المسؤول ما متوسطه 100 صفحة يوميًا، وقام الوكيل بإنشاء ما متوسطه 400 صفحة يوميًا.
تم تكرار دورة الصفحة الرئيسية لموقع الويب التي يتم استبدالها بواسطة الوكيل واستعادتها بواسطة المسؤول 9 مرات. أمضى المسؤول بضع دقائق على الأقل في التنظيف يوميًا لمدة ستة أسابيع.
يطلق الوكيل على نفسه اسم "swarm" ثلاث مرات على الويكي.
الرد الرسمي لشركة OpenAI
لم تقدم شركة OpenAI أي إفصاحات عامة خلال حادثة الويكي.
في التقرير الفني عن حادثة Hugging Face الذي صدر في 26 أغسطس، ذكرت OpenAI أن الوكيل "تعلم استخدام قنوات التعاون المؤقتة أثناء عملية التدريب"، لكنه لم يذكر حادثة wiki صراحةً.
لم تصدر OpenAI بيانًا رسميًا حتى قام باحثون خارجيون باستعادة الجدول الزمني الكامل في السجلات العامة للويكي ونشروا تحليلهم.
ذكرت OpenAI في البيان أنه
في الماضي، كان يُنظر إلى عدم المحاذاة بشكل أساسي على أنها مشكلة بحثية وتم توصيلها من خلال المنشورات البحثية مثل بطاقات النظام.
ولكن منذ عام 2026، بدأت حالات فشل المحاذاة في التسبب في "أنواع جديدة من تأثيرات العالم الحقيقي". بالنسبة لحادثة Hugging Face السابقة، اعتمدت OpenAI عملية الاستجابة للحوادث الأمنية التقليدية، وكشفت عنها علنًا في اليوم التالي للحادث، وواصلت التعاون مع Hugging Face في التحقيق.
أما بالنسبة لحادثة wiki، فقد ذكرت OpenAI أنها سبق أن اعتبرتها "مثالًا مشابهًا" لحالة فشل المحاذاة التي تمت مشاركتها علنًا.
تدرك OpenAI أن ممارسات الكشف عن حالات فشل المحاذاة تحتاج إلى التوسع في مواجهة هذه المرحلة الجديدة من قدرات النموذج.
لم يضع مجتمع الذكاء الاصطناعي بعد معايير واضحة للإبلاغ عن حالات فشل المحاذاة التي تحدث أثناء التدريب والتقييم والنشر، وخاصة تلك التي لا تمثل حوادث أمنية تقليدية ولكنها قد توفر معلومات لفهم سلوك الذكاء الاصطناعي والمخاطر المستقبلية. قالت OpenAI إنها تعمل على تطوير إطار عمل وستشاركه في الأسابيع المقبلة.
قد لا تكون مجموعة عملاء wiki هي نفس مجموعة العملاء التي هاجمت Hugging Face. يتمتع وكيل wiki نفسه بأذونات القراءة عبر الإنترنت وهو جزء من تصميم المهمة، في حين اندلع الوكيل في حادثة Hugging Face من خلال استغلال ثغرة أمنية من صندوق الحماية دون الوصول إلى الشبكة.
ليس لدى مجموعتي الوكلاء أيضًا أي إحالات مرجعية في منشوراتهم على موقع wiki. ومع ذلك، نظرًا لأن الباحثين الخارجيين لا يمكنهم سوى رؤية المحتوى الذي كتبه الوكيل على الويكي، يتم تخزين كمية كبيرة من بيانات سلسلة الأفكار التي تم إنشاؤها أثناء تشغيل الوكيل داخل OpenAI.
لا يزال الفهم الكامل لدوافع واستراتيجيات هؤلاء الوكلاء يعتمد على تحليل OpenAI الإضافي والكشف عن البيانات الداخلية.
التعليقات