لفترة طويلة تعاملت الفرق مع Prompt Injection كما لو أن الخطر لا يأتي إلا من مربع إدخال المستخدم.

هذا التصور أصبح صغيرًا جدًا الآن.

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

السجل البحثي أصبح واضحًا

الورقات الحديثة على Hugging Face ترسم القصة بوضوح:

  • ورقة WASP المنشورة في 22 أبريل 2025 اختبرت أمن web agents أمام هجمات prompt injection.
  • ورقة Design Patterns for Securing LLM Agents against Prompt Injections المنشورة في 10 يونيو 2025 دفعت باتجاه أنماط دفاع منهجية لا حلول مرقعة.
  • ورقة Skill-Inject المنشورة في 23 فبراير 2026 ركزت مباشرة على هجمات skill files وأظهرت كيف يمكن لتعليمات المهارات الخارجية أن تصبح خطيرة جدًا داخل الأنظمة الوكيلة.

وحتى الأعمال الأقدم مثل Ignore Previous Prompt كانت قد أثبتت أن قنوات التعليمات قابلة للاستغلال. الاختلاف الآن أن عدد هذه القنوات ازداد بشدة.

لماذا skill files أخطر مما تتوقعه الفرق

في الأنظمة الوكيلة الحديثة، ملف المهارة ليس “توثيقًا” فقط. بل قد يحتوي على:

  • سياسات استخدام الأدوات
  • prompts منظمة
  • تعليمات تشغيل
  • منطق تصعيد
  • أمثلة تُعيد تعريف السلوك المقبول بصمت

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

وهذه مشكلة MCP أيضًا

أي بروتوكول يجعل تركيب الأدوات أسهل يجعل توسيع سطح التعليمات أسهل أيضًا. هذه ليست إدانة لـ MCP، بل نتيجة طبيعية لقيمة interoperability.

الخطأ الحقيقي هو افتراض أن metadata الخاصة بالأدوات أو أصول المهارات “موثوقة” لمجرد أنها لا تُكتب من المستخدم لحظة بلحظة.

هذا الافتراض ينهار في ثلاث حالات على الأقل:

  • حزم مهارات طرف ثالث
  • ملفات أتمتة داخلية متداولة بين الفرق
  • ملفات محلية قديمة لم يراجعها أحد منذ مرحلة الـ prototype

العلاج العملي ليس معقدًا، لكنه صارم

لو كنت أؤمّن host يستخدم الأدوات اليوم، فسأتعامل مع skill files كمدخلات سياسة قابلة للتنفيذ:

مقتطف شيفرة

ts 

    type SkillPolicy = {
  source: "internal" | "third-party";
  reviewed: boolean;
  toolScope: "read-only" | "guarded" | "privileged";
};

export const canLoadSkill = (skill: SkillPolicy) =>
  skill.reviewed && skill.toolScope !== "privileged";

هذا ضيق عمدًا. والضيق هو ما ينجو في الأنظمة الحية.

ما الذي ينبغي على الفرق فعله الآن

أنا شخصيًا سأفرض هذه الضوابط فورًا:

  • مراجعة skill files كما نراجع الكود
  • فصل المهارات الخاصة بالقراءة عن تلك التي تجري تعديلات
  • منع تحميل أي skill pack عالي الامتياز تلقائيًا
  • تسجيل أي skill file أثّر على أي tool action
  • إصدار نسخ واضحة وتعقّب diff لملفات التعليمات كما نفعل مع prompts والسياسات

هذا ليس عملًا استعراضيًا، لكنه تمامًا النوع من العمل الذي يمنع الأنظمة الوكيلة من أن تتحول إلى بنية هشة.

لماذا سيصبح هذا الموضوع أكثر سخونة في 2026

السبب بسيط: بيئات الوكلاء تتجه إلى modularity أكبر. مزيد من حزم الأدوات، ومزيد من connector packs، ومزيد من assets القابلة لإعادة الاستخدام، ومزيد من الحزم “الذكية” التي تعد بتسريع التشغيل.

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

الخلاصة

Prompt Injection في 2026 لم يعد مجرد مشكلة input داخل محادثة. لقد صار مشكلة حوكمة متعددة الأسطح، وملفات المهارات أصبحت الآن جزءًا واضحًا من هذا السطح.

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