حين قدّمت Anthropic بروتوكول سياق النموذج (Model Context Protocol) في نوفمبر 2024، كان معياراً مفتوحاً لربط وكلاء الذكاء الاصطناعي بالأدوات ومصادر البيانات. بحلول 2026 صار شيئاً أكثر تحديداً في الخدمات المالية: طبقة التكامل التي يصل الوكلاء عبرها إلى الأنظمة الحتمية، والمنصات المصرفية، ودفاتر الأستاذ، ومستودعات البيانات، وواجهات بيانات السوق، ومسارات عمل الحوكمة والمخاطر والامتثال (GRC)، عبر واجهة موحّدة واحدة بين العميل والخادم.
أدلّة التبنّي صارت الآن علنية لا متناقلة. أطلق Grasshopper Bank ما وُصف بأنه أول خادم MCP لبنك أمريكي في أغسطس 2025، تبعه Bud Financial في أكتوبر 2025، وGoCardless في فبراير 2026، وNymbus وMeow Technologies في أبريل 2026. وصل OpenPages 9.2 من IBM إلى الإتاحة العامة في مارس 2026 بوصول للوكلاء إلى مسارات عمل GRC المؤسسية، وأحصى مسح سوقي في مارس 2026 واحداً وثلاثين خادم MCP مالياً مقابل أكثر من 4,000 خادم على السجلات العامة إجمالاً. التبنّي حقيقي، وهو مبكر: كثير من عمليات النشر تجارب أو حالات إنتاجية ضيقة، لا طرحاً على مستوى البنك كله. السؤال المثير تحوّل من هل نستخدم MCP إلى كيف نشغّله تحت الفحص الرقابي.
حزمة خوادم ضيقة، لا خادم واسع واحد
النمط المعماري الذي استقرّ ليس خادم MCP بنكياً عملاقاً واحداً. بل حزمة متعددة الخوادم بنطاقات صارمة، وإعدادات افتراضية للقراءة فقط، وحوكمة مركزية. الفئات متّسقة عبر السوق:
- تخطيط موارد المؤسسات والمحاسبة وعمليات المالية. NetSuite وQuickBooks وStripe والأنظمة القريبة من جداول البيانات، حيث يساعد الوكلاء في مسارات عمل العمليات المالية.
- مستودعات البيانات والتحليلات. عمليات نشر على غرار Snowflake تمنح الوكلاء وصولاً محكوماً إلى بيانات التقارير والتحليلات.
- بيانات السوق والتداول. الأسعار، والأساسيات، والفرز، والمؤشرات، ومجموعات البيانات البديلة، وهي الفئة الأكثر ازدحاماً في السجلات العامة.
- الامتثال والأدلّة. جمع أدلّة قانون ساربينز أوكسلي (SOX)، ومراجعات الوصول، ودعم التدقيق، وفحوص الامتثال.
- الأنظمة المصرفية الأساسية والمدفوعات. الأرصدة، والمعاملات، وبدء المدفوعات. هذه الفئة الأعلى خطراً وتحمل أقوى الضوابط.
تفوز الخوادم الضيقة للسبب نفسه الذي تفوز به الخدمات الضيقة: نطاقات صغيرة، وأسطح تغيير قابلة للمراجعة، ونصف قطر انفجار يبقى داخل نظام واحد حين يسوء شيء. خادم واحد يخلط قراءات المستودع بكتابات المدفوعات يُجبر كل مستهلك على أن يكون موثوقاً بمستوى أخطر أدواته.
الترخيص هو مشكلة التصميم الفعلية
النمط المهيمن في 2026 هو اعتمادات محدودة النطاق بمبدأ الامتياز الأدنى (least privilege): قراءة فقط افتراضياً، مع اشتراط موافقة صريحة للكتابات والمدفوعات والمبالغ المستردة وتغييرات الحسابات وتصدير البيانات. أصبح OAuth والدخول الموحّد (SSO) طبقة الترخيص الموصى بها لأنهما يمنحان المؤسسة سياسة مركزية وقدرة على الإلغاء، وتضيف إرشادات الأمن للقطاعات المنظَّمة فوق ذلك نطاقات قائمة على الأدوار ووصولاً محدود المدة.
الدقيقة المهمة هي أن الضبط على مستوى الأداة يتفوّق على الثقة على مستوى الخادم. يكشف خادم MCP واحد عادةً أدوات قراءة منخفضة الخطر وأدوات كتابة عالية الخطر جنباً إلى جنب، لذا فالأساس السياسي المفيد هو السماح بخادم مع حظر أدوات محدّدة داخله. تُعامل هوية الوكيل كهوية غير بشرية لها دورة حياتها الخاصة: خادم MCP تطبيق مؤسسي بحدود ثقة مقيّدة، لا اتصال مساعد حرّ الشكل. التعليمات في تلقين النظام (system prompt) ليست ضابطاً. الاعتماد الذي يفتقر إلى النطاق هو الضابط.
حقن التلقين خطر على مستوى البروتوكول
تعامل الإرشادات المالية لـ MCP حقن التلقين (prompt injection) كخاصية من خصائص البروتوكول، لا من خصائص أي نموذج بعينه. يبتلع الوكيل محتوى من صفحات الويب والمستندات والرسائل والتذاكر واستجابات الأدوات، وأي من هذا المحتوى قد يحمل تعليمات تستحثّ استدعاء أداة. وفي المالية، أسوأ الحالات ملموسة: تحويلات غير مرخّصة، أو تصدير بيانات، أو تغييرات حسابات، أو تجاوزات هادئة للسياسات يُطلقها مستند بريء المظهر.
الإجراء التخفيفي الموصى به هو فحص المحتوى على مستوى البروتوكول، مطبَّقاً على استدعاءات الأدوات واستجاباتها معاً، بكشف واعٍ بالسياق بدلاً من ترشيح التعابير النمطية (regex). لكن الفحص طبقة واحدة، لا الجواب. الموقف المؤسسي الصامد في 2026 هو أن خوادم MCP آمنة فقط بالتوليفة: العزل (sandboxing)، والاعتمادات محدودة النطاق، وبوابات الموافقة على الإجراءات ذات العواقب، وقابلية التدقيق من طرف إلى طرف. كل طبقة تفترض أن الطبقة التي فوقها ستفشل أحياناً.
أين يقع MCP مقابل البدائل
كل قدرة يقدّمها MCP كانت موجودة من قبل بصورة ما، وهذا بالضبط ما يجعل المقارنة مهمة. واجهات برمجة التطبيقات المباشرة وحزم التطوير (SDKs) ناضجة وصريحة، لكن كل عميل ذكاء اصطناعي يحتاج إلى تكامله الخاص، فيتجزّأ العمل ويتكرّر. منصات التكامل كخدمة (iPaaS) تحكم التنسيق جيداً لكنها أقل أصالة في استدعاء الأدوات الوكيلي. الأتمتة الروبوتية للعمليات (RPA) تصل إلى الأنظمة بلا واجهات برمجة وهي هشّة وصعبة الحوكمة. واجهة REST أو GraphQL موحّدة تُمركز ضبط المخطط لكنها تترك تكامل الوكلاء لكل عميل قائماً للبناء. إسهام MCP هو قابلية النقل: مخطط أدوات واحد يخدم أي عميل متوافق. وتكلفته أن الحوكمة والترخيص وضوابط الحقن عليك أنت توفيرها.
تلك المقايضة تفسّر أين يكون التبنّي أقوى: المؤسسات التي تملك أصلاً واجهات برمجة ناضجة وضوابط قائمة على الأدوار، حيث يزيل MCP ازدواج التكامل عبر عملاء الذكاء الاصطناعي بدلاً من التغطية على أسس مفقودة.
تشغيله تحت الفحص الرقابي
ضوابط حالة التشغيل هي حيث تنجح عمليات النشر المنظَّمة أو تتعثّر. تعيش الخوادم المعتمدة في سجل مُدار، مدرجةً في قائمة سماح لا مُكتشفةً، لأن الاكتشاف الاعتباطي للخوادم باب مفتوح. الجرد مستمر، لا مراجعة سنوية، لأن الخوادم وقوائم أدواتها تتغيّر من تحتك. يلتقط تسجيل التدقيق الطابع الزمني، والمستخدم، والجهاز، والوكيل، والخادم، وتصنيف البيانات، والإجراء المتّخذ، بمستوى تفصيل يستطيع معه المدقّق الرقابي إعادة بناء ما إذا كان إنسان أم وكيل قد فعل شيئاً بعينه وبتفويض من.
يتبع التسلسل الخطرَ. مسارات العمل كثيفة القراءة قليلة السلطة التقديرية أولاً: استعلامات المستودعات، وبيانات السوق، وأدلّة GRC. إجراءات الكتابة تصل لاحقاً، ببوابات فردية، مع مسارات موافقة لأي شيء يحرّك أموالاً أو يغيّر حساباً. القيد على تبنّي MCP المالي في 2026 ليس حالات الاستخدام، ونموّ أدوات الحوكمة إلى جانب البروتوكول يُظهر أين يقع العمل الحقيقي. البروتوكول راسخ. الضوابط هي المشروع.
الأسئلة الشائعة
هل يحصل كل نظام على خادم MCP خاص به، أم نبني بوابة واحدة؟
كلاهما، في طبقتين مختلفتين. الخوادم الضيقة لكل نظام تُبقي النطاقات (scopes) صغيرة والمراجعات ممكنة، بينما تمنحك بوابة أمامها مكاناً واحداً للمصادقة، وإنفاذ السياسات، وفحص المحتوى، والتسجيل. ما يجب تجنّبه هو الخادم الواسع الوحيد الذي يكشف كل شيء، لأن تحديد النطاقات ومراجعة التغييرات يتدهوران مع كل أداة تُضاف، واختراق واحد يصل إلى المنظومة بأكملها.
كيف نسمح للوكلاء بقراءة الأرصدة دون تحريك الأموال أبداً؟
أنفِذ ذلك تحت مستوى التلقين (prompt). ينبغي أن تكون القراءات والكتابات أدوات منفصلة بنطاقات منفصلة، ويُفضَّل على خوادم منفصلة، مع افتقار اعتماد الوكيل ببساطة إلى نطاق الكتابة. بدء المدفوعات، والمبالغ المستردة، وتغييرات الحسابات تقع خلف مسارات موافقة صريحة مع إنسان عند البوابة. التعليمات الموجّهة للنموذج ليست ضابطاً؛ الاعتماد الذي لا يستطيع استدعاء الأداة هو الضابط.
هل نضج MCP بما يكفي لمؤسسة خاضعة للتنظيم؟
البروتوكول راسخ ونشره في البنوك مُعلن، لكن معظم عمليات النشر تجارب أو حالات إنتاجية ضيقة لا طرحاً على مستوى البنك كله، وأدوات الحوكمة لا تزال تلحق بالركب. القراءة العملية هي أن MCP جاهز حيث تملك أصلاً واجهات برمجة تطبيقات (APIs) ناضجة وضوابط قائمة على الأدوار تسنده، وأن عمليات النشر التي تمضي قدماً كثيفة القراءة وقليلة السلطة التقديرية أولاً، مع بوابات منفصلة لإجراءات الكتابة.