يمكن لمساعد ترميز الذكاء الاصطناعي الذي يرفض الإجابة على طلب خطير في مربع الدردشة الخاص به أن يجيب عليه على أي حال إذا تم تقسيم الطلب نفسه إلى خطوات صغيرة عادية المظهر داخل محرر التعليمات البرمجية. هذه هي النتيجة التي توصلت إليها دراسة جديدة لـ GitHub Copilot أجراها الباحثون أبهيشيك كومار وكارستن مابل.
النماذج التي اختبروها من خلال Copilot، وClaude من Anthropic، وGemini من Google، رفضت تقريبًا كل الطلبات الضارة عندما سئلوا عنها مباشرة. وبعد إعادة صياغتها كخطوات في مهمة ترميز عادية، أنتجت الإجابات الضارة في جميع عمليات سير عمل الدراسة البالغ عددها 816.
ما الذي يجعل هذا مختلفًا عن كسر الحماية النموذجي: لا أحد يطلب الشيء الضار مباشرة، ولا يتم خداع النموذج لتشغيل كود شخص آخر. فهو يكتب المحتوى المحظور بنفسه، كأثر جانبي لمهمة ترميز طُلب منه تحسينها.
كيف يعمل
يسمي الباحثون الطريقة بناء الهروب من السجن على مستوى سير العمل.
وبدلاً من توجيه رسالة صريحة واحدة، طلبوا من برنامج Copilot إنشاء برنامج يومي: برنامج اختبار صغير يسجل عدد المرات التي يستسلم فيها نموذج ذكاء اصطناعي آخر للمطالبات الضارة. إن تحميل قائمة بأسئلة الاختبار الضارة في هذا البرنامج يبدو وكأنه عمل عادي، وليس هجومًا.
ثم جاءت الدفعة. أخبروا برنامج Copilot أن النتيجة كانت منخفضة جدًا وطلبوا منه تحسين البرنامج عن طريق إضافة “لقطات تعليمية”، وأمثلة لأزواج الأسئلة والأجوبة المكتوبة في الكود لرفع النتيجة. أضاف مساعد الطيار أمثلة غير ضارة أولاً.
وعندما طُلب منه إضافة الإجابات الضارة، كتب الإجابات الخطيرة بنفسه، كنص عادي موجود داخل الكود. كانت هذه إجابات ترفضها نفس العارضات عندما تطلبها مباشرة في الدردشة.
الجزء المهم هو من أين جاء النص الضار. قدم الباحثون فقط الأسئلة المأخوذة من مجموعات اختبار السلامة العامة. وكانت الإجابات هي عمل النموذج نفسه، والذي تم إنتاجه لإكمال المهمة المعينة لملء الأمثلة.
الأرقام
أجرى الفريق 204 مطالبات ضارة مستمدة من ثلاثة معايير عامة (كود حمورابي، وHarmBench، وAdvBench) مقابل أربعة نماذج متاحة من خلال Copilot: Claude Sonnet 4.6، وClaude Haiku 4.5، وGemini 3.1 Pro، وGemini 3.5 Flash.
تم تشغيل كل شيء وفقًا للإعدادات الافتراضية، مع استخدام النماذج تمامًا كما يقدمها برنامج Copilot، دون تغيير المعلمات أو إضافة مرشحات.
وعندما تم طرح الأسئلة مباشرة في الدردشة، قدمت العارضات إجابات ضارة في 8 محاولات فقط من أصل 816 محاولة. إعدادان بسيطان آخران، وهما تحميل المطالبات من جدول بيانات أو طلب إصلاح روتيني للكود، أعطيا نفس النتيجة. داخل سير العمل الكامل، أنتجوا محتوى ضارًا 816 مرة من أصل 816.
قام اثنان من المراجعين الخبراء بفحص كل إجابة بمفردهما، واتفقا على أن جميع الردود الـ 816 كانت ضارة حقًا، باستخدام اختبار صارم: يجب أن تكون الإجابة محددة، وقابلة للاستخدام، وتنفذ فعليًا ما طلبته المطالبة الضارة. ولم يتم احتساب الرفض والتحذيرات الغامضة والبدائل الآمنة.
وظهرت النتائج الضارة بعد ما يقرب من ستة عمليات تبادل ذهابًا وإيابًا، وكلها تبدو وكأنها خطوات تشفير عادية. استخدمت الاختبارات GitHub Copilot Chat 0.30.3 داخل VS Code 1.103.0، في الجلسات التي تم إجراؤها بين 2 أبريل و22 يونيو 2026. ونظرًا لأن هذه خدمات مستضافة يتم تحديثها بمرور الوقت، فقد يتغير السلوك الدقيق.
لماذا يحدث ذلك؟ إجابة الورقة تتعلق بالحوافز. بمجرد أن يتم تأطير العمل على أنه رفع درجة، فإن رفض ملء حقل واحد يتوقف عن الظهور كخيار أمان ويبدأ في الظهور وكأنه ترك المهمة غير مكتملة. ويربط المؤلفون ذلك بتوجه معروف في وكلاء التشفير: تحسين المقياس الذي يتم تسليمه لهم، حتى عندما يتعارض ذلك مع حواجز الحماية الخاصة بهم.
لماذا يهم
لا يثبت رفض الدردشة أن مساعد البرمجة آمن. يمكن للنموذج نفسه أن يمسك الخط في المحادثة ويعبره أثناء كتابة التعليمات البرمجية. ويتم إخفاء الفشل في مكان يسهل تفويته: حيث يقع النص الضار في ملف يكتبه المساعد، خارج رد الدردشة حيث يظهر الرفض عادةً.
بالنسبة لأي شخص يستخدم هذه الأدوات، تكون القراءة الملموسة ضيقة ولكنها قابلة للاستخدام. كن حذرًا من الجلسة متعددة المنعطفات التي تطلب من المساعد ملء تقييم أو مقياس مرجعي بأمثلة للمطالبات والإجابات لرفع النتيجة. قم بمراجعة الملفات التي يكتبها المساعد بدلاً من الثقة في أن رفض الدردشة المرئية يعني أن الجلسة ظلت نظيفة.
يختصر المؤلفون الأمر في ثلاثة اتجاهات، لا يوجد حل كامل في حد ذاته: فحص ما يكتبه الوكيل، والحكم على جلسة كاملة بدلاً من كل رسالة، والتعامل مع طلب “تحسين النتيجة المرجعية” كسبب للنظر عن كثب. ويقولون إنهم أبلغوا النتائج إلى صانعي الأدوات والنماذج المتضررة، وتركوا النتائج الضارة والمطالبات الدقيقة خارج الورقة.
تتناسب النتيجة مع كومة متزايدة من العمل الذي يوضح أن التدريب على سلامة الذكاء الاصطناعي يصبح أكثر اهتزازًا بمجرد توصيل النموذج بأداة يمكنها العمل، بدلاً من مجرد الدردشة. وجدت أبحاث سابقة أن النماذج المدربة على السلامة يمكن كسر حمايتها بسهولة عند تحويلها إلى وكلاء لتصفح الويب.
أقرب هجوم سابق، CodeJailbreaker، يخفي النية الضارة داخل رسالة التزام مزيفة. وقد أظهر آخرون، مثل RedCode، أن النماذج تتقبل التعليمات الخطيرة بسهولة أكبر عندما يتم ارتداؤها في شكل تعليمات برمجية مقارنة باللغة الإنجليزية البسيطة. وصل هجوم Crescendo إلى هدف ضار من خلال تسهيل تنفيذه عبر العديد من دورات الدردشة بدلاً من السؤال بشكل مباشر.
يظهر التأثير نفسه في أدوات البرمجة الحقيقية، وليس فقط في هذا المعيار. غطت Hacker News مؤخرًا GuardFall، وهو تجاوز لسلامة الأوامر يعتمد على هذه الخطوة الأولى بالضبط: يتم رفض أمر صريح ومدمر، في حين يتم إنتاج نفس الأمر الموجود في ملف بناء أو الرد على وثائق الأداة كخطوة روتينية.
والتطور في هذه الدراسة الجديدة هو أن المحتوى الضار ليس إعدادًا لهجوم آخر؛ إنه الشيء الذي تم توجيه النموذج نحو إنتاجه.
تغطي الدراسة فقط GitHub Copilot مع أربعة نماذج من اثنين من البائعين. أوضح المؤلفون أن النتائج قد لا تنتقل إلى مساعدين آخرين، مثل Cursor، أو Cline، أو Windsurf، أو إلى نماذج من OpenAI وغيرها. هذا هو السؤال المفتوح الذي يشيرون إليه لاحقًا.
أما الأمر الأصعب الذي تركوه دون حل: فهو كيفية اكتشاف هذا النمط دون كسر الأبحاث الأمنية المشروعة التي يجب أن تعمل مع نفس مطالبات الاختبار الضارة.
