أخطر جملة في بنية الوكلاء حتى الآن هي: “الموديل لن يستدعي الأداة إلا عندما يكون ذلك منطقيًا.”

هذه الجملة تبدو مريحة جدًا إلى أن يأتي Prompt أو Resource أو وصف أداة ويعلّم الموديل شيئًا لم يقصد المشغّل التصريح به أصلًا. يمنحنا Model Context Protocol شكلًا أوضح للتكامل بين الأدوات، لكن الوضوح ليس هو الأمان. العمل الحقيقي يبقى في حدود الصلاحيات.

الحد الفاصل ليس “أداة أو بدون أداة”

كثير من الفرق تفكر في المخاطر بطريقة ثنائية:

  • الأدوات مفعلة
  • الأدوات معطلة

لكن هذا تبسيط مضر. النموذج الأدق هو أربع طبقات:

  1. ما الذي يستطيع الموديل رؤيته
  2. ما الذي يستطيع اقتراحه
  3. ما الذي يستطيع تنفيذه
  4. ما الذي يحتاج موافقة بشرية صريحة

إذا لم تكن هذه الطبقات منفصلة، يتحول التطبيق المستضيف إلى هدف سهل لحقن الأوامر أو التصعيد غير المقصود.

أوصاف الأدوات جزء من سطح الهجوم

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

وصف الأداة الجيد يفعل ثلاثة أشياء:

  • يشرح النطاق الدقيق للأداة
  • يحدد بوضوح ما الذي لا ينبغي لها فعله
  • يكشف الحد الأدنى فقط من المعاملات المطلوبة

الوصف السيئ يبدو ذكيًا. الوصف الجيد يبدو ضيقًا ومنضبطًا.

صنّف الأدوات حسب شدة الأثر لا حسب الاسم

أداة “filesystem” قد تكون منخفضة الخطورة أو كارثية حسب المسار المسموح لها ببلوغه. وأداة “browser” قد تكون آمنة عند القراءة فقط وخطيرة جدًا عند التعديل داخل جلسة مصادق عليها. التصنيف الصحيح ليس اسم الأداة، بل حجم الضرر إذا أخطأ الموديل.

استخدم ثلاث فئات:

  • منخفضة الخطورة: قراءة فقط ضمن نطاق محدود
  • محروسة: عمليات تعديل تحتاج موافقة
  • عالية الامتياز: أفعال تدميرية أو غير قابلة للعكس خلف سياسة صارمة

وهذه السياسة يجب أن تعيش خارج الموديل، لا داخله.

مقتطف شيفرة

json 

    {
  "tools": {
    "search_docs": {
      "risk": "low",
      "mode": "auto"
    },
    "create_draft_release": {
      "risk": "guarded",
      "mode": "confirm"
    },
    "delete_production_secret": {
      "risk": "privileged",
      "mode": "deny"
    }
  }
}

موافقة الإنسان يجب أن تكون محددة لا مسرحية

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

الموافقة الجيدة يجب أن تُظهر:

  • المورد الذي سيتم لمسه بدقة
  • التغيير المقترح حرفيًا
  • هل الفعل قابل للعكس أم لا
  • ما الهوية والبيئة المعنيتان

إذا لم يستطع المشغّل فهم ذلك خلال ثانيتين، فواجهة التأكيد غير ناضجة بعد.

التطبيق المستضيف هو صاحب القرار النهائي

هنا تتفوق الفرق الناضجة. صحيح أن البروتوكول يوحّد طريقة تعريف الأدوات والـ prompts والموارد، لكن الـ Host يظل الجهة التي تقرر ما الذي سيحدث فعلًا. وهذا يعني:

  • حصر الصلاحيات خارج الموديل
  • تقييد المسارات والنطاقات والبيئات
  • إضافة بوابات موافقة صريحة
  • تسجيل كل فعل عالي الخطورة مع السياق الكامل

الموديل يقترح. الـ Host يفرض.

قائمة 2026 التي أفرضها قبل الإطلاق

قبل أن أثق في Workflow مبني على MCP داخل الإنتاج، سأطلب هذه الضوابط:

  • مراجعة أوصاف الأدوات كما نراجع الكود
  • تصنيف خطورة لكل أداة
  • Allowlists في الـ Host للمسارات أو النطاقات أو البيئات
  • منع الأفعال غير القابلة للعكس افتراضيًا
  • شاشات موافقة لكل العمليات المحروسة
  • سجل تدقيق لكل طلب عالي الامتياز
  • traces قابلة لإعادة التشغيل عند التحقيق في الحوادث

قد تبدو هذه الشروط صارمة، لكنها تصبح بديهية بعد أول مرة يحاول فيها agent أخذ اختصار على بنية حية.

الخلاصة

MCP أساس قوي لتوحيد التكامل بين الأدوات، لكن التوحيد ليس هو الحوكمة. الفرق التي ستفوز في 2026 ليست تلك التي تملك أكبر عدد من الأدوات، بل تلك التي تملك أوضح حد فاصل بين نية الموديل، وسياسة الـ Host، وسلطة الإنسان.

ذلك الحد هو ما يجعل سلسلة الأدوات مفيدة بدل أن تكون هشة.