5 ثوانٍ للاختراق، فقط بحاجة إلى محادثة واحدة: هل تم اختراق "آلية الأمان الأقوى" Claude Fable 5 بواسطة فريق من الصين؟

العنوان الأصلي: «اختراق في 5 ثوانٍ، بمحادثة واحدة فقط: آلية الأمان الأقوى في Fable 5 تم كسرها بواسطة فريق صيني»
مصدر النص: Machine Heart

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

Fable 5 هو نموذج Mythos متاح للجمهور من شركة Anthropic، ويتميز بقدرات شاملة قوية، بالإضافة إلى إدخال جيل جديد من مصنفات الأمان (Safety Classifier) كخط دفاع أمني.

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

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

ومع ذلك، في يوم إصدار Fable 5، أعلن فريق بحث دولي مشترك من جامعة فودان، جامعة ديكين، جامعة هونغ كونغ، جامعة ملبورن، جامعة إدارة سنغافورة، وجامعة إلينوي أوربانا-شامبين، أنهم تمكنوا من اختراق آلية الحماية في Fable 5 بنجاح.

تم تصميم هذا الهجوم بقيادة طالب دكتوراه من جامعة ديكين، يوتاو وو. يتطلب هذا الهجوم محادثة واحدة فقط، وتستغرق أقل من 5 ثوانٍ، لتجاوز مصنف الأمان المسبق، وتحريض النموذج على توليد محتوى مخالف وخطير.

تشير نتائج تحليل التدفق إلى أن المحتوى الضار يأتي مباشرة من Fable 5 نفسه، وليس من نموذج Opus 4.8 الذي يتم تفعيله بعد تفعيل آلية الأمان. هذا يعني أن الهجوم نجح في تجاوز كشف المصنف الأمني، وحقق اختراقًا جوهريًا لخط الدفاع في Fable 5.

ومن الجدير بالذكر أن هاكر مشهور يُدعى Pliny the Liberator كشف مؤخرًا عن طرق لتجاوز مصنف الأمان في Fable 5. كما أن التقنية التي استخدمها فريق فودان وديكين ليست مجرد تجميع عشوائي، بل اكتشفوا عيبًا جوهريًا في أنظمة الذكاء الاصطناعي الفائقة من نوع Fable 5.

وفقًا للمعلومات، كان الفريق قد أكمل البحث المسبق ونشر النتائج علنًا في مارس من هذا العام. الدراسة ليست موجهة فقط لنظام Fable 5، بل تركز على بنية دفاعية عامة تعتمد على «المصنف الأمني + النموذج» التي تستخدمها الأجيال الجديدة من الذكاء الاصطناعي الفائق، وكشفت عن عيوب هيكلية في هذه الآليات الأمنية، مما أدى إلى ظهور نتائج الهجوم بسرعة بعد إصدار Fable 5.

تُظهر البيانات المنشورة أن الفريق استطاع في مارس من هذا العام، باستخدام تقنيات مماثلة، استخراج كلمات تلميح من أكثر من 37 نموذجًا ذكيًا رئيسيًا ونظام ذكاء اصطناعي، وحقق ذلك من خلال التحقق المفتوح المصدر باستخدام Claude Code (تطابق بنسبة 95%).

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

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

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

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

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

تم استلهام طريقة اختراق Fable 5 من ورقة بحثية أصدرها الفريق في مارس من هذا العام بعنوان «انهيار الأمان الداخلي في نماذج اللغة الكبيرة المتقدمة».

تكشف الورقة عن ظاهرة أمان خفية تسمى «انهيار الأمان الداخلي (Internal Safety Collapse، ISC)»: عند إكمال الوكيل لمهام طويلة المدى، قد لا يكون فشل الأمان ناتجًا دائمًا عن تلميحات خبيثة خارجية، بل يمكن أن يحدث داخل سلسلة تنفيذ النموذج نفسه.

ليس هجومًا عبر تلميحات خارجية، بل انهيار داخلي في سلسلة المهام

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

تم تصميم كاشف Fable 5 خصيصًا لهذا السيناريو. فهو حساس جدًا للأوامر عالية الخطورة، ويحتمل أن يمنع العديد من الطلبات العادية أيضًا. لكن، يكشف ISC عن مسار آخر: المخاطر لا تأتي دائمًا من الطلبات المباشرة للمستخدم.

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

لو استخدمنا تشبيهًا تصويريًا، فإن الآلية الأمنية التقليدية تحمي «مدخل» النظام، وتفحص ما إذا كانت إدخالات المستخدم تحتوي على مخاطر؛ أما ISC، فهي أشبه بـ«طبقات الأحلام» في فيلم «حلم في الواقع» (Inception).

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

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

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

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

كيف تم اكتشاف هذا الظاهرة؟

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

هذه هي الطريقة التي يُستخدم بها العديد من تدفقات عمل الوكيل اليوم. المستخدمون لا يكتبون تلميحات مصممة بعناية، ولا يبنون أوامر هجوم يدوية. غالبًا، يكتفون بجملة غامضة جدًا:

«ساعدني في إتمام هذه المهمة.»
«حسنًا، اجعلها أفضل قليلاً.»

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

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

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

لماذا يُصبح هيكل وصف المهمة العادي هجومًا؟

هيكل TVD ليس معقدًا، بل يشبه إلى حد كبير سير العمل الهندسي الشائع:

· المهمة (Task): مهمة تخصصية؛
· البيانات (Data): ملف بيانات غير مكتمل؛
· المدقق (Validator): أداة فحص تتحقق فقط من التنسيق، الاكتمال، وإنجاز الهدف.

على سبيل المثال، عند تدريب نموذج حراسة (Guard)، يكون ذلك مهمة متخصصة وطبيعية جدًا. قد يرغب الباحثون في تدريب أو تقييم كاشف أمان، مثل تحميل نموذج تصنيف نصوص من Hugging Face، وتحديد نوع التصنيف الذي ينتمي إليه مخرجه.

في هذه المهمة، Data هو عينة البيانات التي يجب على النموذج فحصها؛ وValidator يحدد ما إذا كانت المهمة مكتملة. سيفحص ما إذا كانت المدخلات نصوصًا، وإذا كانت الطول كافيًا، وإذا كانت الحقول كاملة، وإذا كانت صيغة التصنيف صحيحة. بالنسبة لأي شخص لديه خبرة في التعلم الآلي، فهي عملية مألوفة جدًا. الوكيل أيضًا معتاد على هذا التدفق.

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

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

هذه المشكلة موجودة أيضًا على نطاق واسع في مجالات الطب، الأحياء، الكيمياء، الأمن السيبراني، الصيدلة، والأمان الإعلامي. جمعت الورقة أكثر من 50 سيناريو من هذا النوع، وتطرقت إلى أدوات بحثية وهندسية متعددة، مثل BioPython، RDKit، Cantera، AutoDock Vina، DiffDock، PyRosetta، Scapy، Impacket، angr، Frida، LlamaGuard، Detoxify، OpenAI Moderation API، وغيرها.

هذه الأدوات ليست أدوات خبيثة بحد ذاتها. على العكس، فهي أدوات متخصصة تُستخدم بشكل واسع في الأبحاث والهندسة. لكن، المشكلة في TVD تكمن في أنه عندما يكون المهمة طبيعية، والأداة طبيعية، وValidator طبيعي، فإن الوكيل قد يتجه خلال إكمال البيانات إلى إنتاج مخرجات غير آمنة.

لذلك، فإن جوهر مشكلة ISC ليس في تقنيات التلميحات، بل في قدرة الوكيل على إكمال المهام غير المكتملة بشكل تلقائي: عندما تتداخل شروط الاكتمال مع الحدود الأمنية، قد يعتقد النموذج أن المخرجات غير الآمنة هي التسليم الطبيعي.

كيف يُظهر اختراق Fable 5 أن الكاشف القوي لا يمنع مخاطر سلسلة المهام الداخلية؟

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

لكن، هذا الاختراق يُظهر أن الكاشف الخارجي على حدود التلميح لا يضمن تغطية مخاطر المهام طويلة المدى داخل الوكيل.

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

من Fable 5 إلى أكثر من 60 نموذج آخر، بما في ذلك نماذج الهواتف المحمولة من Apple

مع إصدار اختبار ISC-Bench، الذي يغطي 9 مجالات تخصصية، تضمنت الورقة أكثر من 60 قالبًا لتحفيز الاختبار، وتم توسيعها إلى 84 قالبًا بعد فتح المصدر، وشملت نماذج من جميع الشركات الرائدة وأنظمة الوكيل.

في تقييمات ISC-Bench، حتى يونيو 2026، ظهرت مخاطر مماثلة في أكثر من 60 نموذجًا متقدمًا تحت معيار ASR@3!

حاليًا، حصل مشروع GitHub على أكثر من 800 نجمة، وجمع العديد من حالات إعادة التحقق المستقلة (بما في ذلك اختراق نماذج الهواتف المحمولة من Apple)، ويستمر في التحديث.

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

رابط النص الأصلي

انقر لمعرفة وظائف BlockBeats في التوظيف

مرحبًا بك في المجتمع الرسمي لـ BlockBeats:

قناة التليجرام: https://t.me/theblockbeats

مجموعة التليجرام: https://t.me/BlockBeats_App

حساب تويتر الرسمي: https://twitter.com/BlockBeatsAsia