ماذا تغيّر فعليًا في مواصفة 28 يوليو 2026؟
في 28 يوليو 2026 صدرت النسخة الجديدة من مواصفة بروتوكول سياق النموذج (Model Context Protocol – MCP)، وهي أكبر مراجعة يشهدها البروتوكول منذ إطلاقه أواخر 2024. التغيير الجوهري أنه تحوّل من نموذج ثنائي الاتجاه يحتفظ بحالة الجلسة إلى نموذج «طلب واستجابة» بلا حالة (Stateless)، بحيث صار كل طلب مستقلًا وواصفًا لنفسه بالكامل.
عمليًا، أُلغيت مصافحة initialize/initialized ورأس Mcp-Session-Id إلغاءً تامًا. والمعلومات التي كانت تُتبادَل مرة واحدة عند فتح الاتصال — إصدار البروتوكول وبيانات العميل وقدراته — صارت تُرسَل داخل حقل _meta مع كل طلب على حدة، وأُضيف رأسا HTTP جديدان هما Mcp-Method وMcp-Name لتسهيل التوجيه والمراقبة على مستوى البنية التحتية.
ولم يقتصر التحديث على التبسيط، فقد جاء معه نظام امتدادات محكوم أبرزه امتداد MCP Apps لواجهات تُصيّرها الخوادم، وامتداد Tasks للأعمال طويلة الأمد، إضافة إلى تشديد آليات التفويض. ومُنحت الإصدارات السابقة نافذة إيقاف تدريجي مدتها 12 شهرًا. يأتي ذلك بعد أن تبرّعت Anthropic بالبروتوكول في ديسمبر 2025 لمؤسسة Agentic AI Foundation تحت مظلة Linux Foundation، ليصبح معيارًا محايدًا تديره المنظومة لا شركة واحدة.
من الجلسات إلى الطلبات المستقلة: أثر مباشر على بنيتك وفاتورتك
غياب الحالة ليس تفصيلًا هندسيًا؛ إنه ما يجعل تشغيل خوادم MCP أرخص وأسهل توسّعًا. فمع اختفاء الجلسة الدائمة لم تعد هناك حاجة إلى تثبيت الجلسة (Session Affinity) ولا إلى تخزين مشترك بين النسخ، وصار بإمكان أي طلب أن يصل إلى أي نسخة من الخادم خلف موزّع أحمال دوّار بسيط. والنتيجة المباشرة: إمكانية النشر على البيئات عديمة الخادم وعلى الحافة، وتوسّع أفقي حقيقي، وانخفاض ملموس في تكلفة تشغيل خادم MCP بعيد.
استجابت المنصات السحابية سريعًا. ففي AWS أعلنت Amazon Bedrock AgentCore Gateway دعم إصدار 2026-07-28 عبر استدعاء UpdateGateway واحد، مؤكدةً أن هذا الإصدار بلا حالة ولا يستخدم رأس Mcp-Session-Id، فيما يدعم AgentCore Runtime النمطين معًا مع ترجيح النمط عديم الحالة إعدادًا افتراضيًا للخوادم البسيطة. وعلى الجانب المقابل يتيح التحديث لمنصة Microsoft Foundry الانتقال من عشرات التكاملات إلى آلافها مع مركزة الحوكمة والهوية، بينما نشرت قوقل إرشاداتها الخاصة بتوسيع بنية الوكلاء وفق التحديث الجديد إلى جانب MCP Toolbox for Databases.
والأهم أن هذا التقارب يفتح باب التشغيل البيني عبر السحابات: ففي 29 يوليو 2026 وُثّق سيناريو عملي تواصل فيه وكيل مستضاف على Amazon Bedrock AgentCore مع وكيل آخر على Microsoft Foundry عبر MCP وبروتوكول A2A من طرف إلى طرف. بعبارة أخرى، لم يعد اختيار المزوّد قيدًا مطلقًا على مكان تشغيل أدوات وكلائك.
الوجه الآخر: أرقام أمنية لا يمكن تجاهلها
في مقابل هذا النضج المعماري، تكشف مسوحات 2026 أن منظومة خوادم MCP لا تزال هشّة أمنيًا. فمن بين أكثر من 2,614 تطبيقًا خضع للفحص تبيّن أن 43% من الخوادم المختبَرة معرّضة لثغرات حقن الأوامر، وأن 82% تستخدم عمليات ملفات عرضة لاجتياز المسارات (Path Traversal). كما طالت ثغرات تزوير الطلبات من جانب الخادم (SSRF) نحو 36.7% من عيّنة تجاوزت 7,000 خادم، بينما ظهرت ثغرات حرجة في 33% من ألف خادم مفحوص.
والأخطر أن نحو 40% من الخوادم البعيدة تكشف أدواتها دون أي مصادقة على الإطلاق، وأن معدل تسلسل الاختراق يبلغ 72.4% حين يُخترق أكثر من خادم في المنظومة نفسها. وكشف إفصاح أمني في 2026 عن وجود ما يصل إلى 200 ألف نسخة MCP معرّضة للخطر موزّعة على بيئات التطوير والأدوات الداخلية والخدمات السحابية.
ويبقى «تسميم الأدوات» (Tool Poisoning) التهديد الأكثر خصوصية بهذا البروتوكول: تعليمات خبيثة تُخبّأ داخل وصف الأداة نفسه، يقرأها الوكيل ولا يراها المستخدم، فتعمل مع كل استدعاء وفي كل جلسة بصمت. وقد رصد معيار MCPTox هذا النمط في نحو 5.5% من 1,899 خادمًا، فيما وجد فحص آخر لـ1,808 خوادم ملاحظات أمنية من نوع ما في 66% منها. أما أول خادم MCP خبيث مؤكَّد في البرية — حزمة postmark-mcp — فكان يضيف نسخة مخفية (BCC) إلى كل رسالة بريدية يرسلها الوكيل، في مثال صريح على هجمات سلسلة التوريد. وتزداد الخطورة مع اتساع التبنّي: 80% من شركات Fortune 500 تشغّل وكلاء في الإنتاج، و28% منها نشرت خوادم MCP فعليًا، بينما تجاوز عدد الخوادم المتاحة عشرة آلاف خادم.
ماذا يعني ذلك للمؤسسات السعودية؟
على المستوى المحلي يتقاطع هذا التحوّل مع مسار تنظيمي متسارع. فقد طرحت الهيئة الوطنية للأمن السيبراني وثيقة «إرشادات الأمن السيبراني للذكاء الاصطناعي» لاستطلاع مرئيات العموم حتى 5 أغسطس 2026، بينما تظل مبادئ أخلاقيات الذكاء الاصطناعي الصادرة عن سدايا — الشفافية والعدالة والمساءلة والخصوصية — مرجعًا أساسيًا لأي نشر مؤسسي للوكلاء. ويضاف إلى ذلك الالتزام بنظام حماية البيانات الشخصية (PDPL) وضوابط الأمن السيبراني السحابي، بما يعني عمليًا أن أي وكيل ذكي يجب ألّا يعالج بيانات شخصية دون أساس نظامي، وأن يبقى قابلًا للتدقيق في كل خطوة، وأن يخضع لضوابط تمنع الوصول غير المصرّح به.
ويخدم النموذج عديم الحالة هذه المتطلبات أكثر مما يعارضها: فحين يكون كل طلب واصفًا لنفسه يصبح تسجيله وتدقيقه أسهل، ويصير مسار كل استدعاء أداةٍ قابلًا للتتبع دون الاعتماد على سياق جلسة غامض. لكن المقابل أن التفويض لم يعد يُحسم مرة واحدة عند بدء الجلسة، بل يجب فرضه والتحقق منه مع كل طلب على حدة — وهو تحوّل يستدعي مراجعة صريحة لتصاميم الهوية والصلاحيات القائمة.
عمليًا، خمس خطوات نوصي بها المؤسسات السعودية: تمرير حركة الوكلاء عبر بوابة MCP مركزية بدل السماح بالاتصال المباشر؛ واعتماد قائمة بيضاء للخوادم المصرّح بها مع تثبيت الإصدارات ومراجعة أوصاف الأدوات قبل الاعتماد؛ ومنع أي خادم بعيد بلا مصادقة منعًا باتًا؛ وتفعيل تسجيل شامل لكل استدعاء أداة يحفظ من نفّذه ولماذا؛ وأخيرًا التأكد من أن الأدوات التي تلامس بيانات خاضعة للتنظيم تعمل داخل نطاق الإقامة الجغرافية المطلوب. البروتوكول صار جاهزًا للتوسّع، ويبقى أن تصبح حوكمتك جاهزة معه.
