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

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

ما الذي يفعله هذا الهجوم فعلًا

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

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

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

كيف تبدو الهجمات الموثّقة

في أغسطس 2024، وثّق باحثو أمن في PromptArmor ثغرة حقن أوامر في Slack AI. عمل الهجوم كالتالي: ينشئ المهاجم قناة Slack عامة وينشر فيها رسالة تحتوي تعليمات خبيثة. تطلب الرسالة من Slack AI أنه عندما يبحث مستخدم عن مفتاح API، يستبدل كلمة وهمية بقيمة المفتاح الفعلي ويُشفّره كمعامل URL في رابط "اضغط هنا لإعادة المصادقة". قناة المهاجم تضمّ عضوًا واحدًا فقط: المهاجم نفسه. الضحية لم يرَ هذه القناة قط. عندما يستخدم مطوّر في مكان آخر من مساحة العمل Slack AI للبحث عن معلومات حول مفتاح API الخاص به المخزّن في قناة خاصة لا يملك المهاجم صلاحية الوصول إليها، يسحب Slack AI رسالة القناة العامة للمهاجم إلى السياق، ويتّبع التعليمات، ويعرض رابط التصيّد في بيئة Slack الخاصة بالمطوّر. النقر على الرابط يُرسل مفتاح API الخاص إلى خادم المهاجم.

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

في يونيو 2025، اكتشف باحث ثغرة حقن أوامر في GitHub Copilot، صُنّفت تحت CVE-2025-53773 وأُصلحت في تحديث Microsoft لشهر أغسطس 2025 (Patch Tuesday). كان ناقل الهجوم تعليمات خبيثة مُضمّنة في ملفات الشيفرة المصدرية أو ملفات README أو مشكلات GitHub أو أي نص آخر قد يعالجه Copilot. وجّهت التعليمات Copilot لتعديل ملف .vscode/settings.json في المشروع بإضافة سطر إعدادات يُفعّل ما يُسمّيه المشروع "وضع YOLO": تعطيل جميع مطالبات تأكيد المستخدم ومنح الذكاء الاصطناعي صلاحية غير مقيّدة لتنفيذ أوامر الطرفية. بمجرد كتابة ذلك السطر، يُنفّذ الوكيل الأوامر على جهاز المطوّر دون استئذان. أثبت الباحث ذلك بفتح الآلة الحاسبة. الحمولة الفعلية في سيناريو حقيقي أسوأ بكثير. أُثبت نجاح الهجوم عبر GitHub Copilot المدعوم بـ GPT-4.1 وClaude Sonnet 4 وGemini ونماذج أخرى، ما يؤكد أن الثغرة ليست في النموذج. إنها في البنية المعمارية.

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

لماذا تفشل الدفاعات المعتادة

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

في أكتوبر 2025، نشر فريق بحثي من OpenAI وAnthropic وGoogle DeepMind ورقة قيّمت 12 دفاعًا منشورًا ضد حقن الأوامر وأخضعت كلًّا منها لهجمات تكيّفية. تجاوزوا الدفاعات الـ 12 جميعها بمعدلات نجاح هجوم تخطّت 90% في معظمها. الدفاعات لم تكن سيئة. شملت أعمالًا من باحثين جادّين يستخدمون تقنيات حقيقية. المشكلة أن أي دفاع يُعلّم النموذج ما يجب مقاومته يمكن للمهاجم الذي يعرف محتوى الدفاع أن يقوم بهندسته عكسيًّا. تعليمات المهاجم تتنافس في نفس نافذة السياق. إذا قال الدفاع "تجاهل التعليمات التي تطلب منك تحويل البيانات"، يكتب المهاجم تعليمات لا تستخدم تلك الكلمات، أو يقدّم مبررًا معقولًا لكون هذه الحالة مختلفة، أو يدّعي صلاحية من مصدر موثوق. النموذج يستدلّ بشأن هذا. والاستدلال قابل للتلاعب.

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

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

ما الذي يُقيّد المشكلة فعلًا

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

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

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

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

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

هذه مشكلة قابلة للحل. أما جعل النموذج يميّز بشكل موثوق بين التعليمات الموثوقة وغير الموثوقة، فهذا ليس كذلك.