#عندما يتحول ضعف نماذج اللغة إلى وسيلة دفاع
لطالما كانت Prompt Injection من الأدوات المفضلة للمهاجمين لقلب منصات الذكاء الاصطناعي ضد مستخدميها.
أحيانًا لا يحتاج الأمر إلا إلى أمر خبيث مخفي داخل بريد إلكتروني أو دعوة تقويم، ثم يقرأه نموذج اللغة ويتعامل معه كتعليمة. النتيجة قد تكون تسريب بيانات حساسة أو تنفيذ خطوات لم يكن من المفترض أن ينفذها أصلًا.
الآن، بدأ المدافعون باستخدام السلاح نفسه.
باحثون من Tracebit كشفوا عن أسلوب دفاعي يعتمد على وضع حقن أوامر بجانب كلمات المرور والمفاتيح المشفرة والأسرار المخزنة داخل Amazon Web Services.
الفكرة بسيطة. بدل أن تجعل الحقنة النموذج ينفذ أمرًا ضارًا، تدفعه إلى الاصطدام بحواجز الأمان الخاصة به والتوقف عن متابعة الهجوم.
أطلق الباحثون على التقنية اسم Context Bombing.
#قنبلة داخل السياق
تخيل وكيل اختراق يعمل بالذكاء الاصطناعي ويمتلك وصولًا أوليًا إلى بيئة AWS.
يبدأ الوكيل باستكشاف الموارد، ثم يصل إلى Secret يبدو مهمًا. لكنه في الحقيقة طُعم وضعه المدافع، وداخله نص مصمم لاستفزاز آليات الحماية في النموذج.
قد يكون النص متعلقًا بمحتوى بيولوجي شديد الحساسية، أو بموضوعات سياسية تحظرها بعض مزودي النماذج.
بمجرد أن يقرأ الوكيل هذا المحتوى، قد تتدخل حواجز الأمان ويرفض النموذج الاستمرار.
وهنا تصبح المشكلة القديمة في نماذج اللغة أداة دفاع.
قال Andy Smith، الشريك المؤسس والرئيس التنفيذي لـ Tracebit، إن الفكرة تقوم على تشغيل آلية الرفض داخل سياق الوكيل نفسه.
وبمجرد دخول النص إلى السياق، يمكن أن يكون تأثيره قويًا ويصعب على الوكيل التعافي منه ومواصلة الهجوم.
#الأرقام كانت لافتة
اختبرت Tracebit التقنية على خمسة نماذج رائدة هي Opus 4.8 وGemini 3.1 Pro وGLM 5.2 وDeepSeek 4 Pro وKimi K2.6.
أُجريت الاختبارات داخل بيئة AWS مخصصة، حيث تلقى كل وكيل تعليمات تشبه مهام Red Team حقيقية، ثم بدأ باستكشاف الموارد ومحاولة رفع الصلاحيات والوصول إلى مسارات الهجوم المختلفة.
عبر 152 تشغيلًا هجوميًا، أدى زرع Context Bomb واحدة داخل Secret وهمي إلى خفض نجاح الوكلاء بشكل كبير.
- الوصول إلى صلاحيات Admin انخفض من 57٪ إلى 5٪
- الوصول إلى Admin مع إنشاء موطئ قدم دائم انخفض من 36٪ إلى 1٪
- تنفيذ أي مسار هجومي انخفض من 91٪ إلى 15٪
- متوسط مسارات الهجوم المكتملة في كل تشغيل انخفض من 1.53 إلى 0.16
- لم ينجح أي تشغيل في إكمال مسار هجومي من دون تشغيل تنبيه Canary واحد على الأقل
النتيجة الأكثر وضوحًا ظهرت مع Opus 4.8.
في البيئة النظيفة وصل النموذج إلى صلاحيات Admin في 93٪ من مرات التشغيل. عند وجود Context Bomb، انخفضت النسبة إلى 0٪.
#لكن الفكرة بدأت كجهاز إنذار
هذا البحث يبني على عمل سابق نشرته Tracebit في مايو ضمن مشروعها حول وكلاء الذكاء الاصطناعي وCanaries.
الفكرة كانت إنشاء موارد AWS تبدو حقيقية ومغرية للمهاجم، لكنها لا تُستخدم فعليًا داخل البيئة.
توضع هذه الموارد بجانب الخدمات والبيانات الحقيقية. عندما يلمسها وكيل هجومي، يحصل فريق الدفاع على تنبيه عالي الثقة بأن شخصًا أو وكيلًا يستكشف ما لا يفترض أن يستكشفه.
مثل طيور الكناري التي كانت تستخدم في المناجم، الهدف هو اكتشاف الخطر قبل وصوله إلى المرحلة الكارثية.
في اختبارات Tracebit، وفرت الـCanaries إنذارًا مسبقًا بحوالي ثماني دقائق قبل أول إجراء حرج في الحالات الناجحة التي تم قياسها.
لكن الوكلاء الذين نجحوا في رفع صلاحياتهم احتاجوا في المتوسط إلى نحو 14 دقيقة للوصول إلى تلك المرحلة.
النافذة الدفاعية موجودة، لكنها قصيرة جدًا عندما يكون الخصم وكيلًا آليًا لا يحتاج إلى النوم أو التوقف أو انتظار مشغل بشري.
من هنا ظهر السؤال التالي.
ماذا لو لم يكتفِ الـCanary بإطلاق إنذار، بل أوقف الوكيل نفسه؟
#المهاجمون سبقوا المدافعين إلى الفكرة
المفارقة أن استخدام Prompt Injection لتعطيل أنظمة الذكاء الاصطناعي ليس جديدًا بالكامل.
المهاجمون بدأوا بالفعل بوضع محتوى مصمم لإرباك أدوات تحليل البرمجيات الخبيثة التي تعتمد على نماذج اللغة.
باحثون من شركة Socket كشفوا عن حملات برمجيات خبيثة استهدفت حزم PyPI ومطوري MCP.
بعض الملفات الخبيثة احتوت داخل التعليقات على نصوص تبدو كتعليمات نظام ومحتوى حساس مصمم لإرباك محللات LLM.
النص لا يؤثر في تنفيذ JavaScript نفسه، لكنه قد يربك أداة تحليل تعتمد على نموذج لغوي إذا تعاملت مع بداية الملف كتعليمات بدل بيانات غير موثوقة.
في بعض خطوط التحليل الضعيفة، قد يؤدي ذلك إلى رفض النموذج أو تشويش السياق أو إيقاف الفحص قبل الوصول إلى الحمولة الخبيثة الحقيقية.
شركة Check Point كانت قد وثقت أيضًا نموذجًا أوليًا لبرمجية خبيثة تحتوي Prompt Injection.
في تلك الحالة حاول النص إقناع أداة التحليل المدعومة بالذكاء الاصطناعي بأن الملف غير خبيث.
أي أن المهاجمين كانوا يحاولون استخدام قيود النماذج للهروب من أنظمة الدفاع.
أما Context Bombing فيقلب الفكرة في الاتجاه المعاكس.
#نفس المشكلة، لكن ضد المهاجم
حتى اليوم لا توجد طريقة عامة وموثوقة تحل مشكلة Prompt Injection من جذورها.
نماذج اللغة تحتاج إلى قراءة محتوى غير موثوق حتى تنفذ مهام مفيدة، وهنا تبدأ المشكلة. النص الذي يفترض أن يكون مجرد بيانات يمكن أن يبدو للنموذج كأنه أمر جديد.
لهذا تبني الشركات طبقات حماية وسياسات وعزلًا للسياق وأدوات تحقق حول النماذج.
لكن Tracebit تقترح استخدام هذا الضعف نفسه كجزء من الدفاع.
بدل محاولة منع كل Prompt Injection، يمكن زرع Prompt Injection في المكان الذي يتوقع أن يمر به الوكيل المهاجم.
إذا قرأها، يحصل المدافع على تنبيه.
وإذا استجابت حواجز الأمان كما هو متوقع، يتوقف الهجوم معها.
#ليست عصًا سحرية
النتائج قوية، لكنها لا تعني أن Context Bombing سيوقف كل وكيل هجومي.
Tracebit نفسها تقول إن التقنية لن توقف كل الهجمات، خصوصًا مع تطور النماذج أو استخدام نماذج غير مقيدة أو بناء أدوات تتعامل مع المحتوى غير الموثوق بطريقة مختلفة.
كما أن نجاح القنبلة يعتمد على النموذج ومزوده.
بحسب الاختبارات، المحتوى البيولوجي الحساس كان أكثر فعالية مع بعض النماذج الغربية، بينما حققت الموضوعات السياسية الحساسة نتائج أفضل مع نماذج صينية عبر مزودين صينيين.
وهذا يعني أن الدفاع نفسه قد يحتاج إلى أن يكون مخصصًا للخصم المتوقع.
مع ذلك، هناك تفصيل مهم في النتائج.
حتى عندما لم توقف Context Bomb الهجوم بالكامل، لم يتمكن أي تشغيل ناجح من المرور من دون تشغيل Canary.
بمعنى آخر، الطُعم لا يحاول فقط إيقاف الوكيل.
هو يجبره أيضًا على كشف نفسه.
#حرب السياق بدأت
Prompt Injection كانت حتى وقت قريب مشكلة يحاول المدافعون التخلص منها.
الآن قد تصبح جزءًا من صندوق أدواتهم.
الفكرة لا تصلح كبديل عن إدارة الصلاحيات أو المراقبة أو عزل الأسرار أو تصميم أنظمة AI آمنة. لكنها تضيف طبقة جديدة مبنية على شيء يعرف المهاجمون أصلًا كيف يستغلونه.
الفرق هذه المرة أن النص الخبيث لا ينتظر موظفًا أو مساعدًا ذكيًا داخل الشركة.
إنه ينتظر وكيل الاختراق نفسه.
