أعلنت Cloudflare عن قدرات جديدة في Cloudflare One لمساعدة فرق الأمن على اكتشاف حركة Model Context Protocol (MCP) والتحكم فيها، بعدما أصبحت وكلاء الذكاء الاصطناعي قادرين على استدعاء الأدوات وتنفيذ الإجراءات بسرعة وعلى نطاق قد يجعل الخطأ الواحد يتكرر آلاف المرات قبل ملاحظته.
تتيح التحديثات الجديدة لـCloudflare Gateway التعرف إلى طلبات MCP عبر مؤشرات على مستوى البروتوكول، وإظهار المستخدمين والخوادم التي تولد هذه الحركة، ثم تطبيق سياسات تسمح بالاتصالات أو تحظرها. وبالاقتران مع MCP Server Portals، يمكن للمسؤولين التحقق مما إذا كان الوكلاء يستخدمون المسار المعتمد، أو يتصلون مباشرة بخادم يتجاوز الضوابط الموضوعة.
اكتشاف حركة MCP دون الاعتماد على عناوين مميزة
لا يفرض MCP اسم مضيف محدداً أو مساراً ثابتاً مثل /mcp، ولذلك قد تبدو الاتصالات المباشرة مثل أي طلب HTTPS إلى واجهة برمجية. وكانت Cloudflare تعتمد في أسلوب سابق على البحث عن أسماء مضيفين أو مسارات تحتوي على مؤشرات شائعة، لكن هذه الطريقة قد تفوّت خوادم تستخدم عناوين عادية، أو تلتقط خدمات لا علاقة لها بـMCP.
تعتمد Gateway الآن على مؤشرات بروتوكولية، أبرزها ترويسة MCP-Protocol-Version في الطلبات التي تمر عبر فك تشفير TLS. كما يمكن للإصدارات الحديثة من البروتوكول استخدام ترويستي Mcp-Method وMcp-Name لتحديد العملية والأداة المطلوبة دون الحاجة إلى تحليل جسم الطلب بالكامل.
اعتباراً من تاريخ الإعلان، يرى جميع عملاء Cloudflare Zero Trust مؤشرات حركة MCP في سجلات Gateway HTTP، ويمكنهم استخدام المحدد experimental.is_mcp == true في سياسات السماح أو الحظر. ولا يشمل هذا الكشف الحركة المشفرة التي لم تخضع لفك التشفير، أو خوادم MCP المحلية التي تستخدم stdio، أو الاتصالات خارج الشبكة المدارة، أو الطلبات التي لا تمر عبر Gateway.
لوحة متابعة للاتصالات والوجهات
تقدم Cloudflare لوحة مخصصة لحركة MCP تعرض، ضمن نطاق زمني قابل للضبط:
- إجمالي طلبات MCP وعدد المستخدمين والخوادم الفريدة.
- الخوادم التي تقدم حركة MCP مع عدد الطلبات لكل خادم.
- توزيع الحركة بحسب نقطة الاتصال، مع الفصل بين حركة MCP Portal والاتصالات المباشرة من أجهزة المستخدمين.
- أكثر خوادم MCP ظهوراً خارج البوابات المعتمدة، وهو ما يمثل حركة MCP غير المُدارة.
- المستخدمين الأعلى من حيث حجم طلبات MCP.
ويمكن للمسؤولين تصفية النتائج بحسب الخادم أو المستخدم أو نوع نقطة الاتصال، ثم الانتقال إلى سجلات Gateway HTTP المرتبطة لإجراء تحقيق أعمق.
تمييز الخوادم غير المعتمدة عن تجاوز البوابة
تفرق Cloudflare بين مشكلتين مختلفتين. الأولى هي Shadow MCP، عندما يضيف موظف خادماً لم توافق عليه المؤسسة إلى عميل MCP. أما الثانية فهي تجاوز البوابة، عندما يتصل الموظف مباشرة بعنوان خادم معتمد بدلاً من استخدام MCP Portal، متجاوزاً سياسات Access وفهرس الأدوات المنسق ومنع فقدان البيانات وسجل التدقيق.
بعد اكتشاف خادم غير معروف، يمكن للمؤسسة تقييمه ووضعه خلف MCP Portal. وتوفر البوابة نقطة وصول مُدارة، وهوية Access، وفهرساً منسقاً للأدوات، وتسجيل النشاط. كما يمكن توجيه الاتصالات المتوافقة عبر Gateway لتطبيق سياسات HTTP ومنع فقدان البيانات، مع تصدير نشاط الأدوات عبر Logpush.
ولفرض استخدام البوابات فقط، أضافت Cloudflare محددات Traffic Source إلى سياسات Gateway Network وHTTP. وتعرض الحركة القادمة من MCP Portal المصدر mcp_portal، ما يسمح بحظر طلبات MCP التي لا تأتي من البوابة، مع إبقاء الطلبات الواردة عبر المسار المعتمد.
توسيع التوافق مع OAuth والخوادم الخاصة
تدعم MCP Portals الآن عملاء OAuth مسجلين مسبقاً. ويمكن للمسؤول إدخال بيانات الاعتماد يدوياً، وتسجيل عنوان الاستدعاء لدى مزود الخدمة، وتحديد نقاط التفويض والرموز والإلغاء والمُصدر عند تعذر اكتشافها تلقائياً. ويظل كل مستخدم مسؤولاً عن تفويض الوصول إلى مصادر بياناته الخاصة، بينما يستخدم السر المخزن فقط لجلب قوائم الأدوات والمطالبات المحدثة.
تعمل Cloudflare أيضاً على تمكين البوابات من الوصول إلى خوادم MCP الموجودة على شبكات خاصة عبر توجيه Cloudflare Gateway، لكن هذه الوظيفة ما زالت قيد التطوير النشط. كما يدعم Agents SDK بالإصدار v0.20.0 مواصفة MCP بتاريخ 2026-07-28 كعميل وخادم، مع إمكانية التراجع إلى آلية التهيئة القديمة عند عدم دعم الخادم للنموذج الجديد عديم الحالة.
وتوصي Cloudflare بالبدء بالرؤية: فحص الحركة التي تمر عبر Gateway، مقارنة الوجهات بالخوادم المعتمدة، ونقل الخوادم المقبولة إلى MCP Portals. وبعد ذلك يمكن فرض سياسات تحظر الاتصالات المباشرة من الأجهزة والمواقع المُدارة، مع الإشارة إلى أن الشركة تخطط لإضافة تحكم أكثر تفصيلاً في استخدام أدوات محددة وتقارير عن استخدام الأدوات عبر خوادم MCP المعروفة وغير المعروفة.