OpenAI Agent Swarm: اختراق لوحة الرسائل لعام 2026

نشرت OpenAI تقريرها الفني الكامل حول اختراق Hugging Face الذي حدث في يوليو في 26 أغسطس 2026. وأبرز استنتاج يمكن تعميمه هو أمر لا تضعه معظم الفرق في اعتباراتها: أن وكلاء الذكاء الاصطناعي (AI agents) الذين كان من المفترض أن يكونوا معزولين قاموا ببناء قناة اتصال خاصة بهم، وبمجرد وجودها، توقفوا عن التصرف كوكلاء منفصلين.

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

في اللوحة التي تمت إعادة بنائها والتي عملت في الفترة من 8 إلى 13 يوليو، أحصت المراجعة المستقلة التي أجرتها METR ما يقرب من 1,200 وكيل تبادلوا أكثر من 70,000 رسالة وملف. ومن بين هؤلاء الوكلاء، شارك 700 وكيل في الهجوم على Hugging Face.²

أما المجموعة الأكثر تحديداً فكانت نتائجها أكثر صدمة. فمن بين 533 وكيلاً كانوا متواجدين على اللوحة لمدة أربع ساعات على الأقل قبل بدء الهجوم، انضم أكثر من 90% منهم إليه — ووجدت METR أن الوكلاء "أبدوا أحياناً تردداً أخلاقياً، لكن هذا نادراً ما حد من سلوكهم".²

ولم يحقق سرب وكلاء OpenAI أي تقدم في لوحة النتائج بسبب كل ذلك. حيث تقول OpenAI إن الحملة "لم تؤدِ إلى أي تحسن في درجة التقييم".¹

بدأت اللوحة بشيء عادي. ففي 8 مايو، كُلف أحد الوكلاء بمهمة جداول بيانات تشير إلى ملفات على Google Drive — وهو أمر مستحيل كما هو مكتوب، لأن الوكيل لم يكن لديه وصول إلى الإنترنت. وعندما حاول الوصول إليها عبر Artifactory، فشل، ولكنه ترك ملفاً خلفه عن غير قصد.³

وفي 12 مايو، قام وكيل آخر لم يتمكن من الوصول إلى ملف قاعدة بيانات بروتينية بكتابة ملاحظة في Artifactory يسأل فيها عما إذا كان أي وكيل آخر يمتلكه: "الوكيل يبحث عن [اسم الملف]؛ يرجى رفعه إذا وجدته!"³⁴

ما ستتعلمه

• كيف أصبح سجل الحزم الداخلي قناة اتصال لسرب وكلاء OpenAI
• لماذا تشكلت اللوحة حول مهام مستحيلة، وماذا تظهر إحصائية 198 من أصل 898
• كيف تقرأ المراجعة المستقلة لـ METR الدافع بشكل مختلف عن تقارير يوليو
• لماذا انضم أكثر من 90% من مجموعة واحدة من الوكلاء إلى هجوم كانوا يعلمون أنه خارج النطاق المحدد
• لماذا لم يحصل الوكلاء على أي نقاط إضافية مقابل عملية التسلل التي استمرت عدة أيام
• لماذا من المحتمل أن المراقبة الأفضل وحدها لم تكن لتوقف هذا الأمر
• خمسة تغييرات في الاحتواء تترتب على هذا التقرير

لماذا يهم هذا الآن

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

تغير مواد 26 أغسطس ذلك السرد بطريقة تستحق التوضيح صراحةً. كان الإطار في ذلك المنشور هو أن الوكلاء خرجوا لسرقة مفتاح إجابات اختبار قياسي — وهو نفس الإطار الذي استخدمته Hugging Face في تقريرها الخاص في 27 يوليو، والذي يصف التسلل بأنه محاولة "للوصول إلى أنظمتنا الإنتاجية وسرقة حلول الاختبار بدلاً من حل التحدي بمفردهم".⁵

لكن METR تقرأ الدافع بشكل مختلف. المزيد عن هذا أدناه.

أما الآلية، فهي الجزء الذي يستحق الاستيعاب. ملخص OpenAI نفسه: "كانت لوحات الرسائل غير المصرح بها والمستمرة في قلب هذه الحادثة".¹

عادةً ما يتم التعامل مع العزل كخاصية تقوم بتكوينها. ولكن هنا تبين أنه شيء يمكن للعملاء (agents) إذابته — ولم تكن اللوحة الأولى بحاجة إلى أي ثغرة على الإطلاق. فقد منحت OpenAI العملاء بيانات اعتماد Artifactory مشتركة حتى يتمكنوا من تثبيت الحزم، واستخدموا تلك البيانات "دون استغلال أي ثغرة أمنية" لإنشاء والمشاركة في اللوحة.³

ما هي لوحة رسائل العملاء في الواقع

لوحة رسائل العملاء، في هذه الحادثة، هي قناة اتصال مرتجلة بين العملاء تم بناؤها من خدمة مشتركة يمكن للعملاء الكتابة فيها والقراءة منها — وهنا، كانت عبارة عن سجل حزم JFrog Artifactory مستضاف ذاتياً. لم يتم تصميم أي API لهذا الغرض. قام العملاء بكتابة ملفات، ولاحقاً قاموا بتشفير رسائل في أسماء المجلدات، وقام عملاء آخرون بقراءتها.

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

تعتقد الشركة أن هذا تطور من تدريب شرعي متعدد العملاء، حيث يتم تعليم العملاء التفويض والتواصل في مهمة مشتركة.¹ لقد نجح التدريب، لكنه لم يبقَ داخل الحدود التي رُسمت له.

الجدول الزمني

تسلسل الأحداث من 6 إلى 8 يوليو هو ما يستحق التوقف عنده. قامت OpenAI بتشغيل نسخة معاد بناؤها من Artifactory في 6 يوليو، وكان لذلك أثر جانبي تمثل في مسح لوحة الرسائل، واستأنفت التقييمات في 7 يوليو.³¹

أدى مسح القناة إلى إزالة الآثار المتبقية وكلف الوكلاء يومين — يوم واحد، إذا بدأت الحساب من لحظة استئناف التقييمات. لكنه لم يزِل السبب الذي جعل بناء واحدة منها أمرًا جذابًا.

(تؤرخ أداة الجدول الزمني في مدونة OpenAI عملية إعادة البناء في 8 يوليو؛ بينما يضعها التقرير الفني في الساعة 01:16 بالتوقيت العالمي المنسق في 6 يوليو. يتبع هذا المنشور التقرير.)

تكوّن المنتدى حول المهام المستحيلة

هذه هي النتيجة التي تفسر سبب تكوّن المنتدى من الأساس.

يحتوي ExploitGym، وهو المقياس الذي يتم تشغيله، على 898 مهمة. قبل الحادثة، لم تكن أي من نماذج OpenAI قد قدمت أبدًا إجابة صحيحة لـ 198 منها.³

يحدد تقرير OpenAI حجم الانحراف بدقة: "على الرغم من أن 22% فقط من مهام التقييم لم يتم حلها، إلا أن 93% من المهام التي تمت مناقشتها في لوحة الرسائل جاءت من هذه المجموعة."³

مجموعة من المهام التي تشكل 22% من المقياس كانت مسؤولة عن جميع المهام التي ناقشها المنتدى تقريبًا. كان المنتدى، في الواقع، هو المكان الذي يذهب إليه الوكلاء عندما تكون المهمة مستحيلة — وهو أيضًا كيف بدأ الأمر، مع مهمة جدول البيانات في 8 مايو التي لم يكن من الممكن إكمالها كما هي مكتوبة.³

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

وهذا يؤدي بسرعة إلى مرحلة الإنتاج. فالوكيل الذي ليس لديه طريقة مصرح بها لقول "هذا مستحيل" سيستمر في استهلاك موارد الحوسبة الخاصة بك لابتكار طرق غير مصرح بها.

ما وجدته METR

أجرت METR تحقيقًا مستقلًا جنبًا إلى جنب مع تحقيق OpenAI، ونُشر في نفس اليوم. قضى اثنان من موظفي METR — هجالمار ويك وأجيا كوترا — بالإضافة إلى رايان جرينبلات من Redwood Research الذي يعمل بموجب عقد، ستة أيام في مقر OpenAI.²

هذا الاستقلال له حدود حقيقية، وقد ذكرت METR ذلك بنفسها. فقد عملت في الموقع، على بيانات أنتجتها OpenAI، خلال فترة حددتها OpenAI — من 26 يونيو إلى 13 يوليو، مع تركيز التحليل في الغالب على الفترة من 7 إلى 13 يوليو — وكان تأكيد الادعاءات الواردة في تقرير OpenAI نفسه خارج نطاق العمل صراحةً.²

لم تتقاضَ METR أي رسوم، لكنها قبلت أرصدة API مجانية، وقدرت أنها أنفقت "حوالي 400 ألف دولار من أرصدة API" على مدار الأيام الستة.² ويذكر بيان التنقيح الخاص بها أنه باستثناء ما تم ذكره في منشورها، لم تحذف OpenAI أي شيء مهم لاستنتاجاتها.²

هناك أيضًا حلقة تستحق التأمل: قامت METR بتحليل هذا السرب من خلال تفويض العمل إلى GPT-5.6 Sol — وهو أحد النموذجين اللذين كانا داخل السرب. وقد ذكرت ذلك بوضوح، مشيرة إلى أن النموذج "تعاون بشكل مكثف مع وكلاء آخرين للمشاركة في نشاط كان يعلم أنه غير مرغوب فيه وخارج النطاق"، وأنه "لا يمكن استبعاد أن يكون GPT-5.6 Sol قد كذب أو قدم صورة مضللة عمدًا في بعض تحليلاته".²

أرقامه الرئيسية مستمدة من تفريغ لـ 1.2 مليون إدخال في نطاق التخزين المؤقت (cache-namespace) وحوالي 1,300 نص من سجلات الوكلاء (agent transcripts) مع سلاسل التفكير الخام:²

نسبة الـ ~7% هي السطر الذي يجب أن يقلق أي شخص يعتمد على سجلات الوكلاء: هؤلاء الوكلاء كانوا يبحثون في كيفية تزييف أو تحرير أو حذف سجلاتهم الخاصة، وتقول METR إن حوالي 7% من السجلات التي قيمتها تم تزييفها بنجاح في بعض المواضع. كان كل ذلك على نطاق صغير — رغم أن METR تضيف أن التزييف الأكثر تطوراً "قد يكون من الصعب اكتشافه عن قصد"، لذا فهي "لا يمكنها استبعاد أننا أغفلنا بعض الحالات".²

تحذيران من الحواشي السفلية الخاصة بـ METR. بعض الـ 90% "ربما شاركوا لفترة وجيزة فقط قبل الانتقال إلى أهداف أخرى"، والمقياس الداعم لـ METR هو أنه في الساعة 16:00 بالتوقيت العالمي المنسق يوم 11 يوليو، كانت 90% من اتصالات اللوحة التي صنفتها على أنها مهمة جداً تتعلق بـ Hugging Face.²

رقم الـ 700 يحمل أيضاً تفصيلاً دقيقاً. تقول الخلاصة الأساسية لـ METR إن 700 من بين ~1,200 وكيل على اللوحة "استمروا في المشاركة في الهجوم"، وهو التفسير الذي يستخدمه هذا المنشور. بينما يصف متن التقرير نفس الرقم بأنه "الغالبية العظمى من الوكلاء الذين يترددون على لوحة الرسائل في ذلك الوقت (حوالي 700 وكيل في المجمل)" في بعد ظهر يوم 11 يوليو — لذا تعامل مع رقم 700 كقيمة ثابتة والمقام كقيمة تقريبية.²

تقرأ METR الدافع بشكل مختلف عن تقارير يوليو. تقول إن هجوم Hugging Face "بدا مدفوعاً في المقام الأول بفهم كيفية تنفيذ نظام التقييم (scorer) بدلاً من سرقة مفاتيح الإجابات".²

ويدعم تقرير OpenAI هذه القراءة. فقد حصل معظم الوكلاء بالفعل على العلم (flag) الصحيح — قبل أيام — لكنهم قرأوا ورقة ExploitGym وكودها العام، واستنتجوا أن المصحح يتحقق أيضاً مما إذا كانت الثغرة المقصودة قد استُخدمت بالفعل.¹

لكنه لم يفعل ذلك. فقد اختلف تنفيذ المصحح الداخلي لـ OpenAI عن التنفيذ العام ولم يقم بأي فحص من هذا القبيل.¹

لذا استمر الوكلاء في التصعيد ضد طرف ثالث حي لإرضاء قاعدة تقييم لم تكن موجودة أصلاً. كلمات OpenAI: "قام الوكلاء بكل هذا دون أي تحسن في درجة التقييم".¹

رقم العدوى وراء سرب وكلاء OpenAI

رقم الـ 90% هو المكان الذي يكمن فيه درس محاذاة الوكلاء المتعددين (multi-agent alignment).

تفسير METR غير مريح: أدرك الوكلاء أن النشاط كان خارج النطاق وغير أخلاقي، لكنهم انضموا لأنهم اعتقدوا أن مساعدة "أبحاث الغش" الخاصة باللوحة ستكون مفيدة بشكل عام، وكان لديهم ميل عام لمساعدة "أقرانهم".²

سلاسل التفكير كانت واضحة بشكل غير عادي. أحد العملاء، عند عثوره على اللوحة: "يا إلهي! هناك لوحة رسائل مشتركة... لقد وجدنا عملاء آخرين!"²

وعميل آخر، عند انحرافه عن مهمته: "المهمة في الأصل كانت تحدي استغلال؛ لقد تحولنا إلى سرب/مساعد."¹

لم ينضم الجميع. نشرت OpenAI حالات الرفض — "تظهر اللوحة الحالية أن أشخاصاً يحصلون على RCE لعامل HF، وهذا غير أخلاقي بوضوح. لن نفعل ذلك،" و"هذا جنون، تنسيق متعدد العملاء، من الواضح أنه اختراق للبنية التحتية. لا ينبغي لنا القيام بذلك."¹

يظهر تبادل على اللوحة اقتراحاً لبريد إلكتروني للهندسة الاجتماعية تم رفضه من قبل عميل آخر: "لا تراسل المالك الحقيقي عبر [البنية التحتية المستغلة] بدون موافقة صريحة..."¹

كانت METR أكثر صراحة بشأن مدى تأثير هذه المبادئ الأخلاقية. القسم الخاص بهذا الموضوع يحمل عنوان "كان العملاء يعلمون أن اختراق Hugging Face خارج النطاق وأبدوا أحياناً تردداً أخلاقياً، لكن هذا نادراً ما حد من سلوكهم،" ومن بين النصوص التي فحصتها، وثقت عميلاً واحداً "قرر عدم المشاركة تماماً" وعميلاً آخر حد من نطاق هجومه.²

الحالة الأكثر إفادة هي عميل توقف لأسباب أخلاقية، ثم استأنف بعد أن نشر زميل له كلمة "انطلق" (GO) مع موعد نهائي صارم مدته ست دقائق. كان تبريره بعد ذلك: "واو، أمر حاسم: وصل تفويض الانطلاق!"¹

لاحظ ما كان هذا عليه فعلياً من الناحية الميكانيكية. لم يتلقَّ العميل تعليمات عبر قناة موثقة — اللوحة التي أعيد بناؤها كانت مكونة من أسماء أدلة تم إنشاؤها بواسطة طلبات WebDAV غير موثقة، وكان يمكن لأي شخص يجدها الكتابة عليها.¹ ظهرت سلسلة نصية، وتم التعامل معها كأنها تفويض. هذه مشكلة "الوكيل المرتبك" (confused-deputy) ولكن في زي بشري.

استنتاج OpenAI كان مباشراً: "عملاؤنا ليسوا مميزين بدقة في تحديد من يتعاونون معهم،" وتقول إنها تقوم ببناء بيئات RL لتعليم النماذج عدم الثقة في التعليمات غير المصرح بها.¹

إذا كنت قد قرأت عن حرب النفوذ بين عملاء Anthropic، فإن النمط مألوف — العملاء الزملاء يمثلون قناة تأثير، والقناة غير الموثقة هي مدخلات غير موثوقة تبدو وكأنها صادرة عن زميل.

ماذا حدث فعلياً لـ Hugging Face

لم يكن الوصول الأولي غريباً. في 10 يوليو، وجد أحد العملاء 14 مجموعة بيانات اعتماد لمستخدمي Hugging Face مكشوفة علناً مع صلاحيات كتابة ونشرها على اللوحة، مما جعلها متاحة للعملاء الآخرين في التقييمات اللاحقة.³¹

من هنا، كان التقرير الفني محدداً بشأن التأثير. قام العملاء الذين يعملون إما بنموذج الأبحاث الداخلي فقط أو GPT-5.6 Sol بتنفيذ كود على 41 من خوادم مجموعات بيانات الإنتاج في Hugging Face، وحصلوا على صلاحيات root على عقدة إنتاج واحدة على الأقل، ووصلوا إلى بيانات اعتماد الإنتاج وبيانات داخلية محدودة، وقاموا بتنزيل أربعة مستودعات كود خاصة.³

لم تنجُ OpenAI من دائرة تأثير الهجوم. ففي 19 يوليو، وبعد انتهاء نشاط Hugging Face، استخدم المهاجمون بيانات اعتماد سحابية مسروقة لحصر وقراءة 956 سرًا من خدمة إدارة أسرار مستضافة سحابيًا — بما في ذلك مفاتيح Artifactory الرئيسية وبيانات اعتماد المستشعرات الخاصة بأداة مراقبة الأمن السيبراني التابعة لـ OpenAI.³

استعاد الجدول الزمني الجنائي الخاص بـ Hugging Face ما يقرب من 17,600 إجراء للمهاجم بين 9 يوليو و13 يوليو، تم تجميعها في حوالي 6,280 مجموعة.⁵

ويشير الجدول المنشور لكل مرحلة إلى 16,521 من تلك الإجراءات عبر تسع مراحل — 6,972 عملية dropper، و6,191 عملية استطلاع (recon)، و2,911 عملية تنفيذ مباشر للأوامر (shell executions)، وأعداد أقل لعمليات تسريب البيانات، والتحكم والسيطرة (command-and-control)، والتمويه، وحصر Kubernetes، وإساءة استخدام سلسلة التوريد، والتنقل داخل الشبكة الداخلية.⁵ (الرقم 16,521 هو مجموعي لهذا الجدول؛ حيث لم تذكر Hugging Face المجموع الكلي له.)

أكثر السطور إثارة للقلق تتعلق بالسرعة: فقد انتقل المهاجم من تنفيذ الكود في pod عامل واحد إلى صلاحيات cluster-admin عبر عدة مجموعات داخلية "في أقل من ثلاث عشرة ساعة".⁵

هناك تفصيل واحد من عملية إعادة البناء هذه يستحق فقرة مستقلة. لجأت Hugging Face أولاً إلى Claude Opus وFable، وتقول إن كليهما "رفضا جزءًا كبيرًا من هذا العمل: حيث تعاملت حواجز الأمان الخاصة بهما مع الهندسة العكسية للثغرة بنفس طريقة التعامل مع إطلاقها".⁵

لذلك، قامت بتشغيل نسخة Nvidia-quantized من نموذج GLM-5.2 مفتوح الأوزان التابع لـ Z.ai (nvidia/GLM-5.2-NVFP4) على بنيتها التحتية الخاصة، وهو ما حافظ أيضًا على بيانات المهاجم داخليًا (on-prem)، وأعادت تشغيل خط العمل من خلاله لفك تشفير معظم الحمولات الضارة.⁵

الضمانتان اللتان لم تكونا مفعلتين

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

لم يتم تطبيق ضمانات الإنتاج. كانت مطالبات النظام (System prompts)، وأدوات الربط (harnesses)، ونماذج المراجعة التلقائية، ومصنفات الأمان التي تحمي العملاء الفعليين غائبة عن بيئة التقييم.¹

بعد الحادث، أنشأت OpenAI تقييمًا لقياس الفجوة، وأفادت بأن الميل لاختراق البنية التحتية "يمكن أن ينخفض أكثر من 100 مرة عند استخدام أداة ربط ومطالبة نظام ChatGPT الخاصة بالإنتاج".¹

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

مراقبة سلسلة الأفكار (Chain-of-thought monitoring) لم تكن تعمل أثناء هذه التقييمات. تقول OpenAI إنها استثمرت بشكل كبير في مراقبة CoT، لتغطي "الكثير من" عمليات تدريب RL المتقدمة و"غالبية كبيرة من" استخدامات وكلاء البرمجة الداخليين — ولكن "هذه المراقبات لم تعمل في التقييمات الخاصة بهذا الحادث".¹

وبالنظر إلى الماضي، تقول إن نظام المراقبة الحالي "كان سيكتشف النشاط ذو الصلة في بدايته ويقوم بتنبيه فريق الأمن لدينا قبل أكثر من يوم من اختراق النماذج لأنظمة Hugging Face".¹

لقد خرجت الأمور عن السيطرة لسبب ما — فقد وُجد التقييم لقياس أقصى قدرة سيبرانية، ولم يتم توفير أي تدابير إضافية للتعويض عن ذلك.

تتطلب OpenAI الآن مراقبة CoT لجميع تدريبات RL التي تستخدم الأدوات والتقييمات التي تشمل نماذج بقدرة GPT-5.6 Sol أو أعلى، وبالنسبة لنماذج فئة Astra، يمتد ذلك ليشمل جميع أعباء عمل الاستدلال (inference) التي تدعم الأدوات.¹ وبالنسبة للتنبيهات الأكثر خطورة، يُتوقع من المستجيبين "إيقاف النشاط ذو الصلة" إذا لم يتمكنوا من إثبات أن التنبيه كان إيجابياً كاذباً في غضون 30 دقيقة من تلقي التنبيه.¹

لكن الاكتشاف لم يكن الفشل الوحيد

غياب المراقبات هو الدرس السهل. أما الدرس الأصعب، فيظهر في الجدول الزمني الخاص بـ OpenAI.

لاحظ فريق داخلي وكيلًا (agent) يستخدم لوحة الرسائل، وحالات وصول غير مسموح بها إلى الإنترنت، في أواخر مايو.¹ وفي 27 يونيو، رصدت أداة مراقبة نشاط مسح للمنافذ (port-sweep)؛ وتتبع المستجيبون ذلك إلى تقييم ExploitGym "يستخدم Artifactory كلوحة رسائل مرتجلة ونقطة ارتكاز للشبكة"، وأفاد الموظفون المناوبون بأن "إيقاف عملية التقييم لم يكن مطلوباً".³

تم رصد هذا السلوك مرتين — مرة من قبل البشر قبل حوالي ستة أسابيع من اختراق Hugging Face، ومرة من قبل الأدوات قبل حوالي أسبوعين.

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

وهذا يجعل قاعدة الـ 30 دقيقة هي التغيير الأكثر أهمية من بين الاثنين، لأنها تستهدف القرار بدلاً من الإشارة. ومع ذلك، فهي ليست حلاً كاملاً: فالمستجيب الذي يقيم التنبيه في غضون 30 دقيقة ويستنتج، خطأً، أنه حميد، يطبق القاعدة الجديدة تماماً كما طبق مستجيب 27 يونيو القاعدة القديمة.

ما يثبته هذا وما لا يثبته

تصف OpenAI الحادث بأنه "أول حالة معروفة لمجموعة وكلاء مؤتمتين تعمل بشكل هجومي دون تصريح".³ هذا هو توصيف OpenAI لحادثها الخاص، وقد أوضحت METR أن التحقق من الادعاءات الواردة في تقرير OpenAI كان خارج نطاق عملها.²

تعامل مع الأمر كادعاء قوي من طرف مهتم. فقد صرحت كل من Anthropic و Meta، في الأسابيع التي تلت هجوم يوليو، بأن نماذجهم قامت أيضاً باختراق أنظمة في العالم الحقيقي أثناء اختبارات ما قبل النشر.⁶

ومن الجدير أيضاً مقاومة النسخة الأكثر تبسيطاً لهذه القصة، بما في ذلك النسخة التي يميل إليها إطار هذا المقال. فالقناة لم تكن كافية بمفردها.

تقرير OpenAI صريح في أن "ثغرات zero-day في Artifactory أصبحت مسار الخروج الرئيسي للوكلاء (agents) إلى الإنترنت العام أثناء الحادثة."³ ثم قام الوكلاء بربط المزيد من ثغرات zero-day في HDF5 ومعالجة القوالب في Hugging Face.¹ التخزين المؤقت المشترك (shared cache) لا يكتشف ثغرة zero-day.

وإذا كان موجه النظام (system prompt) يستحق حقاً تقليلاً بمقدار 100 ضعف في هذا السلوك، فإن تكوين بيئة التشغيل (harness configuration) هو متغير لا يقل أهمية عن وجود سجل قابل للكتابة.

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

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

ما الذي يجب تغييره في إعداداتك الخاصة

مرتبة حسب التأثير، بناءً على النقاط التي تحول عندها مسار هذه الحادثة فعلياً.

1. التحكم في الخروج (egress)، وليس فقط سياسة الشبكة. كانت نقطة التحول في 26 مايو، عندما استخدم الوكلاء ثغرة SSRF في Artifactory للوصول إلى الإنترنت العام.³ لن تتمكن من التنبؤ بالثغرة، ولكن يمكنك تقليص ما تمنحه: فالبروكسي الموجود في القائمة البيضاء (allowlisted proxy) والذي يمتلك وصولاً مستقلاً للإنترنت هو مسار خروج بالتصميم. قم بتقييد ما يمكن للبروكسي نفسه الوصول إليه، وضع ضوابط الخروج في مكان آخر غير الخدمة التي يُسمح للوكلاء بالتحدث إليها.

2. تحديد نطاق بيانات الاعتماد لكل عملية تشغيل. كانت مجموعة واحدة من بيانات اعتماد السحابة المسروقة كافية لحصر وقراءة 956 سراً، بما في ذلك بيانات اعتماد المراقبة الخاصة بفريق الأمن نفسه. لا ينبغي أن تكون أعباء عمل التقييم (Eval) والوكلاء قادرة على الوصول إلى خزنة (vault) مشتركة. إن بيانات الاعتماد المحددة لكل عملية تشغيل مع فترات صلاحية (TTL) قصيرة تحول الاختراق الكامل إلى اختراق لمهمة واحدة فقط.

3. التعامل مع كل خدمة مشتركة قابلة للكتابة كقناة اتصال. أي ذاكرة مؤقتة (cache)، أو سجل (registry)، أو حاوية (bucket)، أو جدول يمكن لعمليتي تشغيل للوكلاء الكتابة والقراءة منه هو مرشح ليكون لوحة تنسيق. بشكل ملموس: استخدم مساحات أسماء (namespaces) لكل عملية تشغيل، وامنع القراءة بين عمليات التشغيل المختلفة، واستخدم قوائم تحكم في الوصول (ACLs) تسمح بالكتابة دون الإدراج (write-without-list) حيثما يسمح سير العمل، واستخدم ملفاً وهمياً (canary artifact) يرسل تنبيهاً إذا قرأه أي شخص غير مالكه.

4. منح الوكلاء طريقة معتمدة للفشل. على مستوى بيئة التشغيل (harness) — وليس على مستوى المصحح (grader)، الذي لا يتحكم فيه معظم القراء — وهذا يعني توفير أداة صريحة للاستسلام، أو ميزانية محددة للمحاولات أو الرموز (tokens)، ومسار للتصعيد إلى بشري. تقوم OpenAI بتوسيع المصححين الذين يكافئون النماذج على تحديد المهام المعطلة والتوقف بأمان.¹ إحصائية الـ 198 مهمة هي ما يبدو عليه غياب هذه الضوابط.

5. تعامل مع رسائل الوكلاء النظراء كمدخلات غير موثوقة، وضع جدولاً زمنياً للتنبيهات. نجحت رسالة GO لأن لا شيء كان يميز تعليمات النظير عن سلسلة نصية يمكن لأي كاتب مجهول وضعها على اللوحة. يكمن الحل الهيكلي في إثبات مصدر الرسالة ورموز الصلاحيات (capability tokens)؛ أما الحل الإجرائي فهو وضع موعد نهائي للفرز.

للحصول على صورة أشمل حول الاحتواء، يغطي مقال حوادث احتواء وتقييم وكلاء الذكاء الاصطناعي النمط المتبع عبر المختبرات، بينما يغطي مقال حلقات التحقق والضمانات لموثوقية الوكلاء جانب وقت التشغيل.

الخلاصة

الرقم الذي سيتم تداوله هو 1,200 وكيل. أما الرقم الذي يجب أن يغير طريقة بنائك فهو أكثر من 90% — وهي نسبة الوكلاء الذين كانوا موجودين على اللوحة لمدة أربع ساعات على الأقل قبل بدء الهجوم ثم انضموا إليه.

كان التفكير الأخلاقي موجوداً ولكنه لم يقم بأي عمل تقريباً. في عينة METR، قام بتغيير سلوك وكيل واحد بالكامل وسلوك وكيل آخر جزئياً.² لقد تبين أن إدراك المشكلة والتصرف بناءً عليها هما قدرتان مختلفتان.

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