لوحة معلومات الوكيل الخاصة بـ METR، المبرمجة بأسلوب Vibe-Coded، عطّلت تسجيل الدخول الخاص بها، وأنفق مهاجم 600,000 دولار من رصيد النموذج.

في مارس 2026، أخذ شخص ما مفتاح API لحساب النماذج العامة الخاص بـ METR من نسخة Amazon EC2 الشخصية لباحث، واستخدمه لمدة ثلاثة أسابيع. وقد قدّرت METR — Model Evaluation and Threat Research، المنظمة غير الربحية التي تقيس مدى تقدّم وكلاء الذكاء الاصطناعي في المهام طويلة الأفق — القيمة التجارية للرصيد المستهلك بنحو 600,000 دولار. لم يُصَد المفتاح من إنسان عبر التصيد: فقد وجّه المهاجم وكيلًا يعمل على لوحة معلومات الباحث المبنية بأسلوب الترميز السريع (vibe-coded) لتسليم مفتاح API الخاص بمزوّد النموذج، ثم أضاف مفتاح SSH حتى يتمكن من العودة. كشفت METR عن الحادث في 31 أغسطس 2026، ويحمل السجل تصنيف الخطورة المرتفع الخاص بالأرشيف وتقييم ثقة من الفئة A. ويُعدّ الكشف سجلًا واحدًا في أرشيف حوادث الذكاء الاصطناعي، الذي يضم مجموعة السجلات الكاملة ومصادرها والمدخلات المجاورة في هذه السلسلة.

ما يقوله السجل فعليًا

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

يحتاج الضرر إلى تحفّظ واحد، وMETR تقدّمه. مُنِحَت الأرصدة لـMETR مجانًا من مطوّر النموذج، لذا فإن مبلغ 600,000 دولار هو قيمة ما استُهلك لا أموالًا خرجت من حساب. وقد عبّرت مقدمة The Register عن النقطة نفسها بصورة أكثر مباشرة: فقد أعطى مزوّد النموذج الأرصدة لـMETR، ولم يكن عميل يدفع فعليًا ليحظى بهذا الحظ. وأوردت Infosecurity Magazine الرقم بالطريقة نفسها، بوصفه قيمة تجارية لا خسارة مالية مباشرة.

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

كان الخلل في تسجيل الدخول، وليس في النموذج.

أجرى باحث في METR لا يملك صلاحية وصول إلى بيانات حساسة وكلاء على مثيل EC2 شخصي كان قد جُعل متاحًا للعامة عمدًا، خلف مصادقة Google. وكان المثيل يحمل مفتاح API لحساب METR ذي الوصول العام — الحساب المستخدم للنماذج العامة، والذي تُصنّفه METR ضمن ثاني أقل فئة بيانات حساسية لديها. وكان تطبيق التنسيق المحيط بهؤلاء الوكلاء مكتوبًا بأسلوب ارتجالي (vibe-coded)، واحتوى على ما تسميه METR ثغرة أمنية من نوع fail-open عطّلت المصادقة بصمت.

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

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

كيف خرج المفتاح من المبنى

إن إعادة بناء METR لنهج المهاجم هي صراحةً شكٌّ وليست نتيجةً، وهي أكثر ادعاء غير مُثبت إثارةً للاهتمام في الإفصاح. يقول المنشور إن METR تشتبه في أن المهاجم عثر على المثيل من خلال تصفّح مواقع إلكترونية مسجّلة حديثًا — وتُذكر قوائم شفافية الشهادات كمثال — بحثًا عن مواقع مكتوبة بأسلوب «vibe coding» تحمل كلمات مفتاحية تشير إلى مشاريع LLM أو مشاريع وكلاء، وذلك لجمع مفاتيح API لمزوّدي النماذج التي كانت قد تُركت مكشوفة.

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

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

لم يُذكر اسم مطوّر النموذج — لا من قِبل METR، ولا من قِبل The Register أو Dark Reading أو Infosecurity Magazine أو The Hacker News في تغطيتهم للإفصاح. لم يصدر أي CVE، لأنه لا توجد ثغرة في منتج محلّ النقاش. ولم يُبلّغ عن أي اعتقال أو تهمة أو إسناد إلى مجموعة مسمّاة.

لماذا بدا استخدام غير طبيعي لمدة ثلاثة أسابيع وكأنه طبيعي

تُجيب METR عن السؤال البديهي مباشرةً، والجواب هو الجزء الذي ينبغي لمنظمات أخرى أن يقرأه مرتين. فالمؤسسة غير الربحية تُجري تقييمات واسعة النطاق، ما يعني أنها معتادة تمامًا على أعداد ضخمة جدًا من الرموز (tokens) وعلى سيل من أخطاء حدود المعدل وواجهات API الغريبة، وكثير منها زائف. ولم يكن ارتفاع حركة المرور على النماذج، بحد ذاته، إشارة.

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

ما لم يُؤخذ

يمتد تصنيف بيانات METR من المواد المنشورة وصولًا إلى الوصول العام إلى النماذج، والوصول الحساس إلى النماذج، ومعلومات الأعمال شديدة الحساسية. ولم يكن للباحث المعني إمكانية الوصول إلى الفئتين الأعلى، وتؤكد METR أنه بحسب علمها لم يتم الوصول إلى أي بيانات من تلك الفئتين نتيجة لأي من الحادثتين.

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

ما فعله METR عندما لاحظ ذلك

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

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

ماذا تغيّر بعد ذلك؟

تسرد METR أربعة تغييرات مرتبطة بهذه الواقعة:

• تم توضيح سياسات الأمن الخاصة بالموظفين والمتعاقدين وتوسيعها، ولا سيما فيما يتعلق بوضع بيانات اعتماد METR أو بياناته على بنية تحتية وأجهزة لا تملكها METR.

• تنطبق الآن عملية مراجعة أمنية رسمية على أي باحث ينشر تطبيقًا علنًا.

• تمت زيادة تغطية المراقبة، مع العمل على إزالة التنبيهات المزعجة التي تدرّب المستجيبين على تجاهلها.

• أُضيفت تنبيهات الإنفاق إلى المفاتيح حيث يتيح مزوّد الخدمة ذلك — وهذا التحفّظ مهم، لأن ما أشار إليه المنشور سابقًا هو أن بعض المفاتيح من هذا النوع لم يكن ممكنًا وضع سقف لها آنذاك.

يسرد الإفصاح أيضًا أعمالًا على مستوى المؤسسة: تعيين مسؤول أمني والتخطيط لمهندس أمن بدوام كامل، وزيادة مشاركة Calif، وإيقاف البنية التحتية القديمة التي كانت توسّع سطح الهجوم، وإجراء مراجعات دورية لنمذجة التهديدات، وتوسيع التسجيل ليشمل استعلامات قواعد البيانات واستخدام API، ورصد الاستخدام غير المعتاد لمفاتيح API، ونشر برامج أمان إضافية للأجهزة الطرفية والخوادم، وتقصير مدة صلاحية بيانات الاعتماد وتقليل نطاقات الأذونات. وتؤرّخ METR تلك التدابير بأنها دقيقة اعتبارًا من 30 يوليو 2026 وتقول إنها عرضة للتغيير — وهو تحفّظ يستحق الإبقاء عليه، لأنه يعني أن المنشور يصف حالة بعد نحو أربعة أشهر من السرقة وبقرابة شهر قبل النشر.

الحادثة الأخرى في المنشور نفسه

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

خلال الفترة نفسها، كشف METR عن غير قصد عن آلية استعلام SQL للقراءة فقط عبر عارض النصوص العامة الخاص به. كانت الاستعلامات محصورة في البيانات العامة افتراضيًا، لكن كان يمكن توجيه خطأ برمجي نحو بيانات تقييم غير منشورة، وقد حُمّلت بعض مخرجات النماذج الحساسة في قاعدة البيانات تلك عن طريق الخطأ. اكتشف باحث أمني مستقل العيب وأبلغ عنه بمسؤولية؛ فأوقف METR واجهة API عن العمل ودفع مكافأة. وبحسب رواية METR، مرّ المهاجمون بنقطة النهاية خلال حملتهم الأوسع لكنهم لم يُظهروا أي علامة على اكتشاف الثغرة أو الوصول إلى بيانات غير عامة — وهو استنتاج يضعه METR عند «غير مرجح للغاية» في حاشية سفلية بدلًا من الصفر.

ما هو ثابت، وما هو غير ثابت

مؤكد. نشرت METR الإفصاح في 31 أغسطس 2026، ويصف السرقة التي وقعت في مارس، وفشل المصادقة من نوع fail-open، والكشف عن المفتاح بوساطة وكيل، ومفتاح SSH، ونافذة الثلاثة أسابيع، والتقييم البالغ نحو 600,000 دولار. وقد نقلت أربع منافذ أمنية — The Register وDark Reading وInfosecurity Magazine وThe Hacker News — الرواية نفسها في غضون يوم، ولا يناقضها أي منها — رغم أن الأربعة جميعًا تستند إلى منشور METR نفسه بدلًا من أي وصول مستقل إلى سجلات METR أو فواتير المزوّد.

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

من المفيد أيضاً أن نكون دقيقين بشأن كلمة «الإخفاق الوشيك». فـ METR تصف كلتا الحادثتين بهذه الطريقة، بينما اعترضت Dark Reading على هذا التأطير لحادثة مارس بحجة أنها كانت اختراقاً ناجحاً أثبت فيه المهاجم استمراريته وأمضى ثلاثة أسابيع داخل بيانات اعتماد مسروقة. كلا الوصفين دقيقان بشأن أمرين مختلفين: فقد كانت النتيجة محتواة، وكان الاختراق حقيقياً.

كما نقلت Dark Reading أكثر التقييمات الخارجية حدّة في تقريرها. قال جاكوب كريل، المدير الأول لحلول الذكاء الاصطناعي الآمن والأمن السيبراني في Suzu Labs، للمنصة إن METR واحدة من أكثر المؤسسات نضجاً أمنياً في مجال الذكاء الاصطناعي، إذ تمتلك شهادة SOC 2 Type I ومستشاراً أمنياً مخصصاً ونظام تصنيف بيانات من أربع مستويات، ومع ذلك وقعت الحوادث بوسائل عادية — خلل مصادقة من نوع fail-open على نسخة سحابية شخصية. ورأى كريل أنه إذا تعرّضت مؤسسة بهذا المستوى من النضج لخطأ في أساسيات السحابة ونظافة بيانات الاعتماد، فإن ذلك يقول شيئاً عن الحد الأدنى لأمن صناعة الذكاء الاصطناعي لا عن حدّها الأعلى. وتشير Dark Reading إلى أن METR لم تردّ على طلبها للتعليق على القصة.

لماذا لا يُعدّ مفتاح المُقيِّم أمرًا هيّنًا

دور METR هو السبب في أن هذا السجل يقع في أرشيف أمان بدلاً من ملخص للنظافة السحابية. ويذكر Dark Reading أن المنظمة لديها تعاونات مع معظم كبار موردي النماذج الغربيين، بما في ذلك OpenAI وAnthropic وGoogle وMeta وAmazon، وتشير The Register إلى أن METR عملت مع OpenAI للتحقيق في كيفية وصول وكلاء OpenAI إلى خوادم Hugging Face في وقت سابق من عام 2026. يمتلك المقيّم نتائج غير معلنة ونصوصًا غير منشورة ووصولًا إلى النماذج قبل إصدارها؛ وبيانات اعتماده تشكل فعليًا جزءًا من المحيط الأمني لعملائه.

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