التحكم في الوصول إلى MCP للمؤسسات: إدارة الأدوات والخوادم والوكلاء.

إليك سيناريو يحدث في بيئات الإنتاج الآن.

تقوم بنشر خادم GitHub MCP القياسي مفتوح المصدر. الهدف بسيط: تريد أن يقرأ وكيل الدعم الهندسي الخاص بك تعليقات المشكلات ويلخصها للفريق. يعمل بشكل مثالي. يتصل الوكيل، ويجري مصافحة list_tools، ويبدأ في جلب البيانات.

بعد يومين، يخطئ نفس الوكيل بشكل كبير. فبدلاً من تلخيص سلسلة محادثات، يقرر أن المستودع "مهمل" بناءً على تعليق تم فهمه بشكل خاطئ ويستدعي delete_repo.

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

خادم GitHub MCP القياسي، مثل خوادم Stripe وPostgres وKubernetes التي تجدها على GitHub، هو ثنائي. يكشف عن كل نقطة نهاية API يغلفها. إذا كان الخادم يدعم delete_repo، وقمت بإعطاء الوكيل سلسلة الاتصال، فإن الوكيل يمتلك delete_repo. لا يوجد .gitignore أصلي لقدرات الأدوات. لا يوجد chmod لتعريفات أدوات JSON-RPC.

ومع ذلك، نقوم بشكل روتيني بنشر وكلاء يتمتعون "بوصول الجذر" إلى بنيتنا التحتية الأكثر أهمية لأن تطبيق MCP القياسي يفتقر إلى الدقة.

هذا أمر غير مقبول لتبني المؤسسات. لا نحتاج إلى المزيد من "وثائق سياسة الذكاء الاصطناعي" أو تحذيرات صارمة في مطالبات النظام. نحتاج إلى نمط معماري يقسم خوادم MCP إلى واجهات آمنة ومحددة النطاق.

نسمي هذا خادم MCP الافتراضي.

البنية المعمارية: المجمعات مقابل الوكلاء

لحل هذه المشكلة، يجب أن ننظر إلى كيفية توجيه حركة المرور بين نموذج اللغة الكبير (LLM) والأدوات. في الوقت الحالي، هناك نمطان سائدان يظهران في النظام البيئي (يُشار إليهما غالبًا في وثائق Gartner وTrueFoundry): المجمع والوكيل.

• نمط المجمع هذا هو نهج "البدء السريع". تقوم بإعداد نقطة نهاية واحدة تتفرع إلى عدة خوادم أساسية.
  
  • تدفق حركة المرور: Agent -> Aggregator -> [Server A, Server B, Server C]
  • المشكلة: على الرغم من سهولة إعداده، إلا أنه يصبح نقطة فشل واحدة. والأسوأ من ذلك، أنه عادة ما يمرر قائمة القدرات الكاملة لـ جميع الخوادم المتصلة مرة أخرى إلى الوكيل. إنه ينشئ وكيلاً "بوضع الإله" يرى كل أداة في مكدسك.
• نمط الوكيل (المعيار المؤسسي) هذا هو المطلوب. يعمل الوكيل كـ "sidecar" ذكي أو بوابة تقع بين الوكيل وطبقة التنفيذ. ينشئ ربطًا صارمًا بنسبة 1:1 أو 1:N، ولكن مع اختلاف جوهري: فهو لا يقتصر على توجيه الحزم.

يقوم الوكيل بفحص الحمولة (payload) قبل أن تصل الطلبات إلى الواجهة الخلفية، مما يسمح بإزالة الأدوات غير الآمنة وقت الاكتشاف. يسمح لنا باعتراض استجابة JSON-RPC الخاصة بـ tools/list وإزالة الأدوات التي لا ينبغي للوكيل معرفة وجودها بشكل دقيق.

التنفيذ: نمط "الخادم الافتراضي"

هذا يقودنا إلى نمط التنفيذ الأساسي: خادم MCP الافتراضي.

خادم MCP الافتراضي هو بناء منطقي. يشير إلى أدوات محددة من خوادم MCP المادية دون تكرار منطق تنفيذها أو إعادة نشر البنية التحتية. هنا حيث MCP مقابل API يصبح عمليًا لفرق المؤسسات: عادةً ما تقيد واجهات برمجة التطبيقات التقليدية الوصول على مستوى نقطة النهاية، بينما يجب على MCP أيضًا تحديد الأدوات المرئية أثناء الاكتشاف قبل أن يقوم الوكيل بإجراء أي استدعاء. فكر في الأمر كـ 'VIEW' في SQL: فهو يسمح لك بتقديم مجموعة فرعية مقيدة من البيانات (أو في هذه الحالة، الإمكانيات) لمستخدم معين (الوكيل) دون تغيير الجدول الأساسي (الخادم الفعلي).

إليك كيفية تطبيق هذا النمط في بنية بوابة إنتاجية:

الخطوة 1: اتصال الواجهة الخلفية (حساب الخدمة) أولاً، تقوم بتوصيل خوادم MCP الخام ذات الامتيازات العالية بالبوابة.

• الاتصال: تنشئ البوابة اتصالاً دائمًا بخادم MCP الخاص بـ postgres-master أو github-admin.
• إدارة بيانات الاعتماد: تحتفظ البوابة ببيانات اعتماد "حساب الخدمة" أو المسؤول المطلوبة للمصادقة مع هذه الخوادم.
• العزل: الأهم من ذلك، أن الوكيل لا يرى بيانات الاعتماد هذه. يتصل الوكيل بالبوابة، وليس بالأداة. تعمل البوابة كخزينة.

الخطوة 2: الشريحة (البيان) بعد ذلك، تقوم بتعريف بيان الخادم الافتراضي. هذا ملف تكوين (عادةً بصيغة YAML أو JSON) يحدد بدقة الأدوات من الخوادم المادية التي يتم كشفها لنطاق وكيل محدد.

بدلاً من منح الوصول إلى github-all، تقوم بإنشاء شريحة. هذا هو شكل تكوين الخادم الافتراضي النموذجي:

الخطوة 3: عرض العميل (المصافحة) عندما يقوم الوكيل بتهيئة اتصاله، فإنه يجري مصافحة JSON-RPC tools/list القياسية مع البوابة.

نظرًا لأن الوكيل متصل بالخادم الافتراضي support-agent-scope، تعترض البوابة هذا الطلب. تقوم بتصفية القائمة الرئيسية مقابل البيان المحدد في الخطوة 2 وتعيد قائمة منقحة.

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

أين تتناسب TrueFoundry 

إذن أين تقع TrueFoundry بالفعل في هذه البنية؟

ليس كطبقة استضافة، ولا كغلاف تسهيلي. في مكدس MCP الإنتاجي، تعمل TrueFoundry كبوابة بروتوكول وطبقة تحكم. تقع مباشرة في مسار التنفيذ بين بيئة تشغيل LLM والأدوات، حيث لا يزال الإنفاذ ممكنًا.

هذا التموضع مهم. نظرًا لأن البوابة تنهي اتصال MCP، يمكنها تحليل حمولة JSON-RPC وفهمها في الوقت الفعلي. إنها لا تقوم فقط بإعادة توجيه الطلبات. إنها تفسر النية والهوية والنطاق قبل تنفيذ أي أداة على الإطلاق.

وهذا يتيح ثلاث قدرات هندسية ملموسة.

• حقن الهوية (التنفيذ بالنيابة عن).

تعاني معظم مكدسات الوكلاء ذاتية الصنع من مشكلة "المفتاح العام". تعمل الوكلاء باستخدام رمز API مشترك، لذا عندما يحدث خطأ ما، كل ما تراه في السجلات هو "الوكيل فعل ذلك". لا توجد مساءلة. تقوم بوابة TrueFoundry بفحص JWT العميل الوارد، وتربطه بالمستخدم البشري المصادق عليه، وتحقن رمز OAuth أو رمز الخدمة الصحيح في المراحل اللاحقة. إذا لم تتمكن أليس من حذف مستودع، فلا يمكن للوكيل الذي يتصرف نيابة عنها القيام بذلك أيضًا. سلطة الوكيل لم تعد نظرية. إنها مرتبطة تشفيريًا.

• إنفاذ وقت تشغيل الخادم الافتراضي.

البوابة هي المكان الذي تصبح فيه خوادم MCP الافتراضية حقيقية. تحتفظ TrueFoundry بجداول التوجيه التي تربط نطاق خادم افتراضي بخوادم MCP المادية والأدوات المسموح بها. إذا حاول وكيل استدعاء شيء خارج شريحته المعلنة، تعيد البوابة خطأ JSON-RPC منظمًا. لا يتلقى النموذج فشلاً صامتًا. بل يتلقى رسالة واضحة "الأداة غير موجودة"، مما يساعده على التصحيح الذاتي بدلاً من التخيل.

• فحص حركة المرور وإعادة تشغيلها.

نظرًا لأن البوابة تنهي الاتصال، يمكنها تخزين وتتبع حركة مرور MCP مؤقتًا. وهذا يتيح فحص تفاعلات الأداة على غرار PCAP. عندما يعلق وكيل في حلقة أو يتخذ قرارًا سيئًا، يمكنك إعادة تشغيل تسلسل استدعاء الأداة الدقيق دون إعادة تشغيل خطوات الاستدلال المكلفة التي أدت إلى ذلك. ينتقل تصحيح الأخطاء من التخمين إلى الفحص.

‍

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

دفاع متعمق: حواجز الحماية على طبقة البروتوكول

تتحكم الخوادم الافتراضية في الأدوات التي يمكن للوكيل رؤيتها. تتحكم الحواجز (Guardrails) في كيفية استخدام تلك الأدوات. مجرد أن الوكيل يكون مسموحًا له باستدعاء sql_query، لا يعني أنه يجب السماح له بتشغيل SELECT * FROM users وتفريغ قاعدة بيانات العملاء بأكملها في نافذة السياق الخاصة به.

هنا يأتي دور الحواجز (Guardrails). في بنية TrueFoundry، تعمل الحواجز كبرمجيات وسيطة (middleware) تعترض حمولة JSON-RPC على طبقة البروتوكول، وتفحص حركة المرور قبل تنفيذها.

حواجز الإدخال (جدار حماية تطبيقات الويب "WAF" للوكلاء) يمكننا كتابة برمجيات وسيطة بلغة بايثون أو قواعد تعبيرات نمطية بسيطة تتحقق من صحة وسائط الأداة قبل وصول الطلب إلى حاوية الواجهة الخلفية.

• السيناريو: يحاول وكيل تنفيذ استعلام يفتقر إلى بند LIMIT، مما قد يؤدي إلى تعطل قاعدة البيانات أو تكلفة باهظة في استخدام الرموز.
• الحل: تعترض حاجز إدخال أداة sql_query. تتحقق من حمولة الوسائط. إذا كان LIMIT مفقودًا، فإنها إما ترفض الطلب أو تقوم بحقن LIMIT 100 افتراضي تلقائيًا.
• حالة استخدام أمنية: يمكن لمرشحات التعبيرات النمطية اكتشاف أنماط مثل مفاتيح API أو المفاتيح الخاصة في وسائط الإدخال، مما يمنع الوكيل من تسريب الأسرار عن طريق الخطأ إلى أداة تسجيل تابعة لجهة خارجية.

حواجز الإخراج (منع فقدان البيانات) الوكلاء عرضة "للتسريب المطول" (verbose leaking)، حيث يجلبون بيانات أكثر مما يحتاجون إليه ويلخصونها.

• الآلية: تقوم حواجز الإخراج بتنقية استجابة JSON من الأداة قبل إعادتها إلى نموذج اللغة الكبير (LLM).
• التنفيذ: إذا أعادت أداة قاعدة البيانات عمودًا باسم ssn أو credit_card، يمكن للحاجز تشفير هذه البيانات أو إخفائها (على سبيل المثال، ****-1234) في استجابة JSON-RPC. يحصل نموذج اللغة الكبير (LLM) على السياق الذي يحتاجه ("بطاقة الائتمان موجودة") دون الاحتفاظ بالبيانات الحساسة في نافذة السياق الخاصة به.

قابلية المراقبة: تتبع "عملية التفكير"

في البرمجيات التقليدية، إذا فشلت مكالمة API، فإنك تتحقق من السجلات. سترى خطأ خادم داخلي 500 وتتبعًا للمكدس.

في الأنظمة الوكيلة، غالبًا ما يكون "الفشل" صامتًا. يستدعي الوكيل أداة، ويحصل على نتيجة، لكنه يسيء تفسيرها. أو يستدعي الأداة بحجج خاطئة قليلاً تعمل تقنيًا ولكنها تعيد بيانات غير صحيحة. تظهر سجلات التطبيق القياسية "200 OK"، لكن النتيجة خاطئة.

لتصحيح هذا، تحتاج إلى تتبع موزع لـ MCP.

توفر TrueFoundry تصورًا متتاليًا لسلسلة تنفيذ الوكيل. لا ترى فقط "فشل الطلب". بل ترى زمن الاستجابة وحمولة البيانات عند كل قفزة:

• النطاق أ (الاستدلال): يقضي نموذج اللغة الكبير (LLM) 200 مللي ثانية في توليد الفكرة.
• النطاق ب (البوابة): تستغرق البوابة 10 مللي ثانية للتحقق من JWT وتوجيه الطلب.
• النطاق ج (تنفيذ الأداة): تستغرق حاوية Postgres 1.5 ثانية لتشغيل الاستعلام.

لماذا هذا مهم: يمكنك التعمق في النطاق ج ورؤية الاستعلام الدقيق الذي أنشأه الوكيل. قد تدرك أن الوكيل يهلوس اسم جدول غير موجود، أو يستخدم معلمة API مهملة. بدون هذه الرؤية على مستوى البروتوكول، فإنك تقوم بتصحيح أخطاء صندوق أسود بالتخمين.

الخلاصة: الأمن كعامل تمكين

الانتقال من "الروبوت الدردشة" إلى "الوكيل" هو في الواقع الانتقال من "توليد النصوص" إلى "تنفيذ التعليمات البرمجية عن بعد". وهذا الواقع هو بالضبط ما يبقي معظم المشاريع التجريبية للمؤسسات حبيسة مرحلة إثبات المفهوم (PoC).

تسد TrueFoundry هذه الفجوة. عندما تطبق نمط خادم MCP الافتراضي عبر بوابة الذكاء الاصطناعي، تتوقف عن مطالبة فريق الأمان الخاص بك بالوثوق بنموذج احتمالي وتبدأ في عرض بنية حتمية عليهم. أنت لا تنشر مجرد أداة؛ بل تنشر واجهة محددة النطاق وواعية بالهوية تحد بطبيعتها من نطاق التأثير.

بالنسبة للمؤسسات، لا توفر TrueFoundry "الأنابيب" لـ MCP فحسب؛ بل توفر الصمامات والمقاييس والأقفال. إنها تحول وكيل "الوصول الجذري" المتهور إلى موظف رقمي موثوق به. لن تقوم بتشغيل مجموعة Kubernetes إنتاجية بدون RBAC؛ لذا لا ينبغي لك تشغيل مكدس وكلاء مؤسسي بدون TrueFoundry.