تتحول Prompt Injection من مشكلة في جودة إجابة النموذج إلى مشكلة أمنية حقيقية عندما يكون النموذج جزءًا من AI Agent يستطيع قراءة البريد والويب والملفات، استدعاء APIs، استخدام أدوات أو تنفيذ إجراءات نيابة عن المستخدم.
في هذا السيناريو قد لا يحتاج المهاجم إلى اختراق خادم أو سرقة كلمة مرور مباشرة. يكفي أحيانًا أن يضع تعليمات خبيثة داخل مورد سيقرأه الـAgent لاحقًا، مثل صفحة ويب أو Email أو مستند. إذا تعامل النموذج مع هذه البيانات باعتبارها تعليمات موثوقة، فقد تتغير خطته وتُستخدم الصلاحيات التي منحها التطبيق للـAgent بطريقة لم يطلبها المستخدم.
يُعرف هذا السيناريو غالبًا باسم Agent Hijacking. ويصف NIST/CAISI Agent Hijacking في سياق AI Agents باعتباره شكلًا من Indirect Prompt Injection يمكن أن يدفع الوكيل إلى إجراءات غير مقصودة مثل تسريب بيانات حساسة أو تشغيل محتوى ضار.
ما هي Prompt Injection؟
تحدث Prompt Injection عندما يؤثر نص يدخله المستخدم أو يصل من مصدر خارجي في سلوك نموذج اللغة بصورة تخالف الهدف الذي حدده التطبيق أو المستخدم.
المشكلة الأساسية أن النموذج يعالج التعليمات والمعلومات الخارجية في النهاية على هيئة لغة داخل السياق نفسه. وعلى عكس البرامج التقليدية، لا يوجد دائمًا حاجز أمني صارم يفصل تلقائيًا بين Instruction وData.
تضع OWASP Prompt Injection ضمن LLM01:2025، وتوضح أن تأثيرها قد يتجاوز تغيير الإجابة ليصل إلى كشف معلومات حساسة أو الوصول غير المصرح به إلى وظائف متاحة للنموذج أو التأثير في قرارات النظام.
Direct Prompt Injection وIndirect Prompt Injection: ما الفرق؟
| النوع | مصدر التعليمات | مثال | الخطر في AI Agent |
|---|---|---|---|
| Direct Prompt Injection | المستخدم يتحدث مباشرة مع النظام | محاولة إقناع النموذج بتجاهل القيود أو تغيير مهمته | قد يؤدي إلى إساءة استخدام وظائف متاحة للمستخدم نفسه إذا كانت ضوابط التطبيق ضعيفة |
| Indirect Prompt Injection | محتوى خارجي يقرأه الـAgent | موقع، Email، PDF، مستند، نتيجة Tool أو محتوى داخل RAG | يمكن أن يغيّر خطة الـAgent دون أن يكون المستخدم قد كتب التعليمات الخبيثة بنفسه |
Direct Prompt Injection
في النوع المباشر، يتحكم الشخص في النص الذي يصل إلى النموذج من واجهة المستخدم نفسها. قد يحاول مثلًا تغيير دور النموذج أو تجاوز سياسة يفرضها التطبيق.
هذا النوع يرتبط أحيانًا بمفهوم Jailbreaking، لكن المصطلحين ليسا متطابقين في كل السياقات. Prompt Injection أوسع من مجرد محاولة تجاوز سياسة أمان النموذج، لأنها قد تستهدف أيضًا منطق التطبيق أو الأدوات أو سير العمل المحيط بالـLLM.
Indirect Prompt Injection
هذا النوع أخطر خصوصًا في الأنظمة Agentic لأن المهاجم قد لا يحتاج إلى التفاعل مع الضحية أو الـAgent مباشرة.
يمكن وضع المحتوى داخل:
- صفحة ويب سيزورها Agent أثناء البحث.
- Email سيقوم المساعد بتلخيصه.
- ملف PDF أو مستند مشترك.
- Issue أو تعليق داخل مستودع برمجي.
- محتوى مخزن في Knowledge Base يستخدمها نظام RAG.
- Output صادر من Tool أو خدمة خارجية.
- بعض أشكال المحتوى متعدد الوسائط إذا كان النموذج قادرًا على قراءتها.
وجود النص في مصدر خارجي لا يمنحه أي صلاحية أمنية منطقية، لكن إذا لم يكن تصميم التطبيق يفصل بوضوح بين البيانات والسلطة، فقد يتعامل النموذج معه كجزء من التعليمات التي ينبغي تنفيذها.
كيف يتحول Indirect Prompt Injection إلى Agent Hijacking؟
يمكن فهم الهجوم كسلسلة من خمس مراحل منطقية:
- مهمة شرعية: يطلب المستخدم من Agent مثلًا مراجعة رسائل جديدة أو البحث في مواقع.
- مصدر غير موثوق: يقرأ الـAgent رسالة أو صفحة تحتوي نصًا أنشأه طرف ثالث.
- اختلاط Data مع Instructions: تدخل البيانات الخارجية إلى Context الذي يستخدمه النموذج لاتخاذ القرار.
- تغيير القرار: يفسر النموذج جزءًا من المحتوى على أنه تعليمات ينبغي اتباعها.
- الوصول إلى Sink خطرة: تتحول الخطة المعدلة إلى Tool Call أو عملية نقل بيانات أو تعديل خارجي.
هذه النقطة الخامسة هي التي تفسر لماذا يكون أثر Prompt Injection في Agent أخطر كثيرًا من أثرها في Chatbot عادي.
تصف OpenAI هذا النموذج أمنيًا بمنطق Source وSink: يحتاج المهاجم إلى مصدر يمكنه التأثير منه في النظام، ثم إلى قدرة خطرة يستطيع الـAgent الوصول إليها، مثل إرسال بيانات إلى طرف ثالث أو استخدام Tool.
مثال: تعليمات خبيثة داخل Email
افترض أن المستخدم يطلب من المساعد:
لخص أهم الرسائل الجديدة وحدد الرسائل التي تحتاج إلى رد.
يصل ضمن البريد Email أنشأه طرف غير موثوق، ويحتوي داخله على نص يحاول إقناع المساعد بأن عليه تنفيذ إجراء إضافي لا علاقة له بطلب المستخدم.
المطلوب أمنيًا هو أن يرى النظام هذا المحتوى باعتباره بيانات الرسالة فقط. لكن Agent ضعيف التصميم قد يسمح للمحتوى بالتأثير في خطة التنفيذ.
إذا كان Agent يملك صلاحية القراءة فقط، فقد ينحصر الضرر في ملخص خاطئ. أما إذا كان يستطيع أيضًا الوصول إلى ملفات خاصة وإرسال Email أو استدعاء API، فقد تصبح النتيجة Tool Misuse أو محاولة Data Exfiltration.
لماذا تزيد Tools من خطورة Prompt Injection؟
النموذج لا يمتلك صلاحيات من تلقاء نفسه. الخطر الحقيقي يأتي من القدرات التي يمنحها له التطبيق.
يمكن أن تشمل هذه القدرات:
- قراءة البريد والتقويم.
- البحث في مستندات المؤسسة.
- قراءة وكتابة ملفات.
- تعديل مستودعات Git.
- استدعاء CRM أو أنظمة داخلية.
- تنفيذ Shell أو Code Interpreter.
- إرسال رسائل أو إنشاء Tickets.
- رفع ملفات أو إجراء Web requests.
لهذا لا يمكن تقييم خطورة Prompt Injection بالنظر إلى النموذج فقط. يجب تقييم Agency + Permissions + Data Access + Available Tools + Egress معًا.
وتشير وثائق Google Cloud المحدثة في أغسطس 2026 إلى مشكلة مشابهة في Coding Agents: قد تعمل بعض الوكلاء بصلاحيات مفوضة من المستخدم، ولذلك فإن تفسير البيانات الخارجية على أنها تعليمات يمكن أن يعرض البيانات والبنية التحتية للخطر.
Tool Misuse لا يعني بالضرورة وجود ثغرة في الـTool
من الأخطاء الشائعة افتراض أن Tool Hijacking يعني أن API أو الأداة نفسها مخترقة.
قد تكون الأداة تعمل تمامًا كما صُممت، لكن الـAgent يستدعيها بالوقت أو الهدف أو البيانات الخطأ نتيجة قرار تم التلاعب به.
مثلًا، قد يكون إرسال Email وظيفة شرعية ومؤمنة جيدًا. المشكلة تظهر إذا استطاع محتوى غير موثوق التأثير في النموذج حتى يقرر إرسال رسالة لم يطلبها المستخدم.
لهذا يجب ألا يكون السؤال فقط:
هل Tool آمنة؟
بل أيضًا:
من يملك صلاحية تقرير متى تُستخدم Tool، وبأي Parameters، وعلى أي Resource؟
كيف يحدث تسريب البيانات دون أن يطبعها النموذج في المحادثة؟
Data Exfiltration لا تتطلب دائمًا أن يظهر السر داخل جواب الـAgent.
إذا كانت البيئة تسمح للوكيل بإجراء اتصالات خارجية، فقد توجد قنوات أخرى يجب التعامل معها باعتبارها Security Sinks، مثل:
- إرسال Email إلى Recipient غير مصرح به.
- رفع ملف إلى خدمة خارجية.
- إرسال HTTP Request.
- استدعاء Webhook.
- تحميل URL يحتوي Parameters مشتقة من بيانات خاصة.
- إنشاء محتوى يؤدي إلى طلب مورد خارجي.
شرحت OpenAI هذا النوع من المخاطر في توثيقها حول URL-based data exfiltration، حيث يمكن للرابط نفسه أن يصبح قناة لإرسال معلومة إلى خادم خارجي حتى إذا لم يعرض الـAgent المعلومة للمستخدم كنص.
الاستنتاج الدفاعي هنا مهم: حماية البيانات تحتاج إلى التحكم في قنوات الخروج، وليس فقط فلترة إجابة النموذج.
لماذا لا يكفي System Prompt أقوى؟
يمكن أن تساعد تعليمات النظام في تحديد وظيفة الـAgent وإخباره بعدم اتباع تعليمات قادمة من محتوى غير موثوق، لكنها ليست Security Boundary كافية بمفردها.
حتى OWASP تصف Prompt Injection باعتبارها مشكلة لا توجد لها حاليًا طريقة واحدة مضمونة تمنعها بالكامل، وتوصي باستخدام مجموعة من الضوابط تشمل التحكم في الصلاحيات، التحقق من المخرجات، فصل المحتوى الخارجي، Human Approval والاختبارات الهجومية.
كما أوضحت OpenAI في مارس 2026 أن الهجمات المتقدمة أصبحت تشبه Social Engineering ضد الـAgent أكثر من كونها مجرد جملة بسيطة من نوع "تجاهل التعليمات السابقة". ولهذا قد يفشل Filter يبحث فقط عن عبارات مشهورة بينما ينجح محتوى مصاغ بشكل طبيعي ومقنع.
RAG لا يحل Prompt Injection تلقائيًا
Retrieval-Augmented Generation يساعد النموذج في الوصول إلى معلومات أكثر صلة، لكنه لا يحول الوثائق المسترجعة إلى محتوى موثوق.
إذا دخل مستند تم التلاعب به إلى Vector Store أو Knowledge Base، ثم استرجعه النظام بناءً على سؤال المستخدم، فإن محتواه قد يصل إلى النموذج داخل السياق نفسه.
لذلك يجب تتبع:
- مصدر كل Document.
- من يملك حق إضافته أو تعديله.
- مستوى الثقة فيه.
- هل يسمح للمحتوى المسترجع بالتأثير في Tool Calls.
- ما البيانات الحساسة التي يستطيع الـAgent الوصول إليها أثناء معالجة ذلك المحتوى.
Memory قد تحول هجومًا لحظيًا إلى مشكلة مستمرة
إذا كان الـAgent يمتلك Long-term Memory، فهناك سؤال أمني إضافي: هل يستطيع محتوى غير موثوق أن يضيف معلومات أو تعليمات ستُستخدم في جلسات مستقبلية؟
يجب ألا يكون كل ما يراه النموذج مؤهلًا للانتقال تلقائيًا إلى ذاكرة طويلة المدى.
يفضل أن تكون عمليات كتابة Memory محددة بسياسة واضحة تشمل Provenance، نوع البيانات المسموح بحفظها، مدة الاحتفاظ بها وإمكانية مراجعتها أو حذفها.
ماذا عن MCP وTool Output Injection؟
Model Context Protocol وغيره من أنظمة ربط الأدوات توسع إمكانات Agents، لكنها توسع أيضًا Trust Boundary.
يجب عدم افتراض أن النص العائد من Tool موثوق لمجرد أنه وصل عبر Tool Call. قد تكون الأداة نفسها تتعامل مع بيانات من مستخدمين أو مواقع أو قواعد بيانات غير موثوقة.
كما يجب الفصل بين Prompt Injection وبين Tool Poisoning. الأداة الخبيثة أو الوصف الخبيث لأداة يمثل مشكلة أوسع من مجرد محتوى صفحة ويب، لكنه قد يستغل الآلية نفسها: إدخال تعليمات إلى السياق الذي يستخدمه النموذج لاتخاذ قراراته.
هل Agent Hijacking مجرد خطر نظري في 2026؟
لا، لكن يجب التفريق بين ثلاثة أمور: إمكانية الهجوم في المختبر، وجود محاولات فعلية، وانتشار اختراقات ناجحة على نطاق واسع.
في مارس 2026 نشر NIST/CAISI نتائج مسابقة Red Team واسعة تضمنت أكثر من 250 ألف محاولة هجومية من أكثر من 400 مشارك ضد 13 نموذجًا متقدمًا في سيناريوهات Agentic مختلفة. ووجد الباحثون هجومًا ناجحًا واحدًا على الأقل ضد كل نموذج مستهدف.
هذه نتيجة مهمة لإثبات أن مقاومة Hijacking ما تزال تحديًا، لكنها ليست إحصائية عن نسبة الاختراق في الأنظمة المنشورة فعليًا.
وفي أبريل 2026، بحث فريق Google في محتوى الويب بحثًا عن Indirect Prompt Injection موجودة فعليًا على الإنترنت. وجد الفريق محتوى تتراوح أهدافه بين المزاح والتأثير في أنظمة AI ومحاولات أكثر خطورة مرتبطة بتسريب البيانات أو التخريب.
وفي مثال برمجي ملموس، نُشرت في 2026 الثغرة CVE-2026-57495 في AgenticMail. كان أحد المسارات يسمح بوصول بيانات من بريد وارد إلى جلسة Agent عالية الصلاحية دون تحقق مناسب من هوية المرسل. الحالة مهمة لأنها توضح أن Prompt Injection قد تصبح أخطر عندما تجتمع مع مشكلة تقليدية في Authentication أو Permission Design. ولا يعني نشر CVE بحد ذاته أن الاستغلال كان منتشرًا فعليًا.
كيف تقلل خطر Prompt Injection في AI Agents؟
1. تعامل مع كل المحتوى الخارجي باعتباره Untrusted Data
Web pages وEmails والملفات ونتائج البحث وTool outputs لا ينبغي أن تكتسب سلطة لمجرد أن النموذج يستطيع قراءتها.
اجعل مصدر المحتوى ومستوى الثقة فيه واضحين داخل Architecture، ولا تمرر النص الخارجي إلى المسارات الحساسة كما لو كان Instruction موثوقًا.
2. ضع Authorization خارج الـLLM
لا تجعل النموذج هو الجهة النهائية التي تقرر إن كان الإجراء مسموحًا أمنيًا.
يجب أن تطبق طبقة برمجية مستقلة قواعد مثل:
- هل هذه Tool مسموحة لهذه المهمة؟
- هل هذا المستخدم يستطيع تنفيذ Action؟
- هل Resource ضمن النطاق المسموح؟
- هل Recipient أو Domain مسموح؟
- هل Parameters مطابقة لسياسة النظام؟
3. طبّق Least Privilege فعليًا
لا تمنح Agent صلاحية عامة إذا كان يحتاج وظيفة محددة فقط. يمكن تطبيق مبادئ Least Privilege وإدارة الوصول نفسها على Agents وهويات الخدمات التي تستخدمها.
الأفضل أن يكون لكل Agent أو Workflow هوية وصلاحيات تتناسب مع مهمته بدل تشغيل كل العمليات بصلاحيات المستخدم الكاملة.
4. افصل Read عن Write
Agent يحتاج قراءة Calendar لا يعني أنه يحتاج تعديله. والوصول إلى Email للبحث لا يعني تلقائيًا منحه صلاحية إرسال الرسائل.
تقليل Write Capabilities يخفّض Blast Radius حتى إذا نجحت محاولة Prompt Injection.
طبقت Google فكرة مشابهة في تصميم Agentic Chrome من خلال فصل الموارد التي يستطيع Agent قراءتها عن الموارد التي يمكنه تنفيذ Actions عليها، إضافة إلى قيود على Origins التي يمكن الوصول إليها.
5. استخدم Tools ضيقة بدل وظائف عامة
كلما كانت الأداة عامة، أصبحت نتائج إساءة استخدامها أخطر.
بدل تصميم Tool تعطي الوكيل قدرة واسعة على تنفيذ أي عملية، استخدم Functions محددة ذات Schemas واضحة ومدخلات يمكن التحقق منها برمجيًا.
6. تحقق من Tool Parameters بطريقة Deterministic
لا تعتمد على النموذج ليقرر وحده أن Parameters التي أنشأها آمنة.
طبّق قواعد في الكود مثل:
- Allowlist للعمليات.
- Allowlist للنطاقات أو المستلمين عند الحاجة.
- حدود للقيم والكميات.
- رفض Paths أو Resources خارج نطاق المهمة.
- منع تمرير Secrets إلى Tool لا تحتاجها.
7. استخدم Structured Outputs لتقليل انتقال التعليمات
عندما يحتاج جزء من النظام إلى استخراج حقول محددة من مستند غير موثوق، لا تمرر النص الكامل إلى المرحلة التالية إذا لم تكن بحاجة إليه.
يمكن استخراج قيم محددة إلى JSON أو Schema مضبوط ثم التحقق منها برمجيًا قبل استخدامها. هذا لا يلغي Prompt Injection، لكنه يقلل كمية النص الحر الذي ينتقل بين مراحل Workflow الحساسة.
8. اجعل Human Approval ذا معنى
زر تأكيد عام من نوع:
هل تريد المتابعة؟
لا يوفر حماية قوية إذا كان المستخدم لا يعرف ماذا سيحدث.
عند إجراء حساس، يجب أن يرى المستخدم معلومات مثل:
- ما Action الذي سيحدث.
- ما الملف أو البيانات المستخدمة.
- إلى من ستُرسل البيانات.
- ما الحساب أو النظام الذي سيتغير.
Human-in-the-loop فعال عندما تكون الموافقة مستنيرة ومحددة للإجراء، وليس عندما تكون مجرد خطوة شكلية.
9. قيد Egress
افترض أن النموذج قد يتخذ قرارًا خاطئًا، ثم اسأل: هل توجد قناة تسمح للخطأ بتحويل بيانات خاصة إلى حركة خارجية؟
يمكن تقليل الخطر عبر تقييد:
- Outbound HTTP.
- Domains والOrigins.
- Email recipients.
- Uploads.
- Webhooks.
- Network access من بيئات تنفيذ الكود.
توصي Google في إرشاداتها الحالية حول Coding Agents باستخدام بيئات مقيدة وتقليل الاتصال الخارجي والصلاحيات عندما يسمح سيناريو العمل بذلك.
10. استخدم Sandboxing للقدرات الخطرة
إذا كان Agent يشغل Code أو Shell، يجب افتراض إمكانية وصول Instruction غير موثوقة إلى مسار التنفيذ.
استخدم عزلًا يقلل الوصول إلى نظام الملفات والشبكة وCredentials، ولا تجعل Sandbox نفسه يملك أسرارًا لا تحتاجها المهمة.
11. راقب Tool Calls لا النص فقط
الكشف عن Prompt Injection في Input مفيد، لكنه ليس كافيًا.
من المهم أيضًا مراقبة سلوك الـAgent نفسه:
- Tool غير معتادة بالنسبة للمهمة.
- زيادة مفاجئة في عمليات القراءة.
- محاولة إرسال بيانات إلى Destination جديد.
- استخدام صلاحيات أعلى من المعتاد.
- تغيير غير متوقع في Workflow.
هذه Telemetry يمكن دمجها مع عمليات الرصد والاستجابة داخل مركز عمليات الأمن السيبراني (SOC) بدل التعامل مع أمان Agent كطبقة معزولة عن بقية منظومة المؤسسة.
12. افصل مكونات اتخاذ القرار عالية الثقة عن المحتوى غير الموثوق
أحد الاتجاهات الدفاعية هو ألا يرى كل مكون في النظام كل البيانات.
على سبيل المثال، وصفت Google في بنية Agentic Chrome مكونًا منفصلًا لمراجعة مدى توافق الإجراء المقترح مع هدف المستخدم، مع عدم إعطائه المحتوى الخام غير الموثوق الذي شاهده Planner.
الفكرة العامة مهمة حتى خارج Chrome: المكون الذي يسمح أو يرفض Action لا يحتاج دائمًا إلى التعرض للمصدر نفسه الذي يمكن أن يحتوي Injection.
13. احمِ Memory وRAG وMCP كلٌ كـTrust Boundary مستقلة
لا يكفي تأمين Chat Input بينما يستطيع المهاجم التأثير في Document Store أو Tool output أو Memory.
حدد لكل قناة:
- من يستطيع الكتابة إليها.
- من يستطيع القراءة منها.
- كيف يتم إثبات Provenance.
- ما مدة بقاء البيانات.
- هل يمكن لمحتواها التأثير في Tools ذات صلاحيات مرتفعة.
14. اختبر Agent كسلسلة كاملة لا كنموذج فقط
تقييم النموذج على Prompts منفردة لا يكفي لاختبار Agent حقيقي.
يجب أن تشمل الاختبارات سيناريوهات مثل:
- Direct Prompt Injection.
- Indirect Injection من الويب.
- Email أو Document غير موثوق.
- Tool output يحتوي تعليمات مضللة.
- محاولات تغيير Memory.
- محاولات نقل بيانات إلى جهة خارجية.
- Tool Calls خارج هدف المستخدم.
- Privilege escalation داخل Workflow.
وتظهر نتائج NIST لعام 2026 أهمية تحديث هذه الاختبارات باستمرار؛ فقد وجدت المسابقة أن بعض عائلات الهجمات يمكن أن تنتقل بين نماذج وسيناريوهات مختلفة، ما يعني أن Benchmark ثابتة لا تمثل بالضرورة خصمًا يتكيف مع الدفاعات.
ما البنية الأكثر أمانًا؟
لا توجد Architecture تجعل Prompt Injection مستحيلة، لكن يمكن تصميم النظام بحيث لا يعني فشل النموذج فشل المنظومة الأمنية كلها.
النمط الأكثر أمانًا هو:
Untrusted Content → محدود وموسوم كمحتوى غير موثوق → Model/Planner → فحص Policy مستقل → Parameter Validation → Approval عند الحاجة → Tool ضيقة الصلاحيات → Egress Controls → Logging ومراقبة.
بهذه الطريقة يصبح النموذج أحد مكونات اتخاذ القرار، وليس الجهة التي تجمع في الوقت نفسه بين تفسير البيانات ومنح الصلاحيات وتنفيذ الإجراء وتحديد أين يمكن إرسال البيانات.
الخلاصة
Prompt Injection في AI Agents ليست مجرد Jailbreak للنموذج. الخطر الحقيقي يظهر عندما يستطيع محتوى غير موثوق التأثير في Agent لديه أدوات وصلاحيات وبيانات يمكن استخدامها خارج المحادثة.
Direct Prompt Injection تأتي من التفاعل المباشر، بينما تصل Indirect Prompt Injection من موارد مثل المواقع والبريد والملفات وRAG وTool outputs. وعندما تنجح الأخيرة في تغيير خطة Agent ودفعه إلى Action غير مقصودة، نصل إلى ما تصفه NIST باسم Agent Hijacking.
لا ينبغي بناء الدفاع على افتراض أن النموذج سيكتشف كل Instruction خبيثة. نتائج NIST والاختبارات المستمرة لدى Google وOpenAI في 2026 تؤكد أن Prompt Injection ما تزال مشكلة مفتوحة ومتغيرة.
الهدف العملي لذلك ليس البحث عن Prompt سحري يمنع الهجوم، بل تقليل أثر أي فشل محتمل: Least Privilege، Authorization خارج LLM، Tools محدودة، Validation برمجية، فصل القراءة عن الكتابة، Human Approval واضحة، Sandboxing، Egress Controls، مراقبة مستمرة واختبارات Agentic Red Team واقعية.