July 4, 2026
|
5 min read
حوكمة MCP للمؤسسات: كيفية التحكم في الوصول إلى خادم MCP وتدقيقه وتأمينه على نطاق واسع
By أشيش دوبي
Published: July 4, 2026
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
اسأل فريق الأمن لديك عن عدد خوادم MCP التي تعمل في مؤسستك الآن. إذا تمكنوا من الإجابة بثقة، فأنت متقدم على معظم المؤسسات. وإذا لم يتمكنوا، فلديك مشكلة حوكمة موجودة بالفعل في بيئة الإنتاج.
انتشر اعتماد MCP بسرعة. ربطت الفرق الوكلاء بـ GitHub وSlack وقواعد البيانات الداخلية وواجهات برمجة التطبيقات الخارجية عبر خوادم MCP، غالبًا دون مراجعة من قسم تكنولوجيا المعلومات، ودون سياسة بيانات اعتماد، ودون أي وسيلة لفريق الأمن لمعرفة ما يمكن لهذه الخوادم الوصول إليه. البروتوكول مفيد تحديدًا لأنه يسهل ربط الأدوات. هذه السهولة هي أيضًا ما يجعل عمليات نشر MCP غير المحكومة عرضة لمخاطر أمنية حقيقية.
خوادم MCP ليست واجهات برمجة تطبيقات سلبية. إنها تمنح وكلاء الذكاء الاصطناعي وصولاً مباشرًا ومبرمجًا إلى الأنظمة الحساسة. يتصرف هؤلاء الوكلاء بناءً على استدلال مستقل، وليس مسارات تعليمات برمجية تمت مراجعتها. وكما قال أحد قادة أمن المؤسسات في Medtronic: "يفتح MCP الكثير من الفرص لإحداث الكثير من الضرر بسرعة كبيرة." تتوقع Gartner أن 70% من فرق هندسة البرمجيات التي تبني تطبيقات متعددة الوسائط ستستخدم بوابات الذكاء الاصطناعي بحلول عام 2028، ارتفاعًا من 25% في عام 2025. الفرق التي تبني الحوكمة الآن هي التي ستتمكن من التوسع بأمان.
يغطي هذا الدليل متطلبات حوكمة خوادم MCP للمؤسسات، ولماذا تقصر أدوات الأمان القياسية، وكيفية بناء الإطار ذي الأركان الأربعة الذي يمكن لفرق الامتثال الاعتماد عليه، وكيف تقوم TrueFoundry بتطبيق كل ذلك داخل سحابتك الخاصة.
متطلبات حوكمة خوادم MCP للمؤسسات
حوكمة خوادم MCP للمؤسسات هي الإطار التشغيلي الكامل لإدارة خوادم MCP الموجودة في مؤسستك، ومن يمكنه الوصول إليها، وما يُسمح لهم بفعله، وما يتم تسجيله عند استخدامها. إنها ليست وثيقة سياسة. إنها بنية تحتية مطبقة.
تقلل معظم الفرق من تقدير النطاق. تغطي الحوكمة كل خادم MCP في البيئة: أدوات الطرف الثالث التي ربطها المطورون دون مراجعة من قسم تكنولوجيا المعلومات، والأدوات الداخلية التي بنتها ونشرتها فرق المنتجات، وخوادم MCP المضمنة داخل تكوينات بيئات التطوير المتكاملة (IDE) في Cursor وClaude Code وأدوات مماثلة. إذا كان خادم MCP يمكنه الوصول إلى نظام إنتاج، فهو ضمن النطاق.
تختلف حوكمة خوادم MCP أيضًا عن حوكمة واجهات برمجة التطبيقات القياسية بطريقة مهمة لكيفية بنائها. تنفذ استدعاء واجهة برمجة تطبيقات REST مسارًا برمجيًا محددًا كتبه المطور وراجعه. أما استدعاء أداة MCP فهو قرار مستقل يتخذه وكيل ذكاء اصطناعي في وقت التشغيل بناءً على استدلاله. يختلف نموذج التهديد ومتطلبات التدقيق والضوابط اللازمة للحفاظ على المساءلة. إن التعامل مع MCP كدمج واجهة برمجة تطبيقات تقليدية هو ما يؤدي بالمؤسسات إلى فجوات تدقيق لا يمكنها تفسيرها للمنظم.
- النطاق: جميع خوادم MCP. يشمل ذلك الخوادم الداخلية التي بنتها فرق المنتجات، والخوادم التي تعمل في مسارات CI/CD، وأي شيء قام المطور بتكوينه محليًا في بيئة التطوير المتكاملة (IDE) الخاصة به.
- الآلية: بوابة مركزية بين جميع العملاء وجميع خوادم MCP. تفرض البوابة السياسات. لا تقوم خوادم MCP الفردية بتطبيق ضوابط الوصول الخاصة بها، وهذا ما يجعل هذا النهج قابلاً للتطوير عبر مئات الخوادم.
- النتيجة: يتم التصريح بكل استدعاء أداة مقابل هوية موثقة وتسجيله بتنسيق منظم وقابل للاستعلام، يدعم مراجعة الامتثال والتحقيق في الحوادث.
مخاطر أمن خوادم MCP التي لا يمكن للمؤسسات تجاهلها
تعمل خوادم MCP ضمن حلقة استدلال وكيل الذكاء الاصطناعي. يتم تشغيل استدعاء واجهة برمجة التطبيقات التقليدية بشكل حتمي بواسطة رمز التطبيق. على النقيض من ذلك، يتم تشغيل استدعاء أداة MCP عندما يحدد الوكيل في وقت التشغيل أن الأداة مناسبة لمهمة معينة. يتأثر هذا القرار باستدلال النموذج بدلاً من تدفق التحكم المحدد صراحةً، مما يقلل من الرؤية التي يمتلكها المطورون عادةً حول كيفية ولماذا يتم استدعاء الأداة. في هذا النموذج، يصبح الاستدلال جزءًا فعالاً من مسار التحكم، ومع ذلك لا يمكن ملاحظته مباشرة من خلال أدوات أمان التطبيقات القياسية.
لقد وثق باحثو الأمن هذا في بيئات الإنتاج. تعمل هجمات حقن الأوامر (Prompt injection) التي يتم تسليمها عبر أوصاف أدوات MCP على إعادة توجيه سلوك الوكيل دون لمس سطر واحد من التعليمات البرمجية. يؤدي انكشاف بيانات الاعتماد من خلال خوادم MCP سيئة التكوين إلى إنشاء مسارات وصول لم يتم تصميم ضوابط المحيط لمراقبتها أبدًا. هذه ليست سيناريوهات هجوم نظرية من الأوراق البحثية. إنها حوادث موثقة من عمليات نشر مؤسسية حقيقية.
يمكن لعمليات نشر خوادم MCP الخفية تجاوز التحكم القياسي في الوصول
عندما يقوم المطورون بنشر خوادم MCP أو الاتصال بها دون مراجعة قسم تكنولوجيا المعلومات، فإنهم يتجاوزون كل ضوابط التحكم التي تنطبق عادةً على تكامل نظام جديد: تقييم أمان البائع، وتصنيف الوصول إلى البيانات، وسير عمل توفير الوصول. يدخل الخادم مرحلة الإنتاج دون أي من الوثائق أو المراقبة أو القيود التي يحملها أي نظام مؤسسي آخر.
بدون سجل مركزي، لا توجد إجابات موثوقة لأسئلة الأمان الأساسية. ما هي خوادم MCP التي تعمل؟ ما هي بيانات الاعتماد التي تحتفظ بها؟ ما هي قواعد البيانات التي يمكنها الاستعلام عنها؟ ما هي الخدمات الخارجية التي يمكنها استدعاؤها؟ هذا الغموض يبقي هذه الخوادم خارج نطاق تقييمات الثغرات الأمنية ومراجعات مخاطر البائعين واختبارات الاختراق تمامًا.
يُعد خادم MCP واحد غير معتمد يتمتع بإمكانية الوصول للقراءة إلى نظام CRM داخلي أو مستودع تعليمات برمجية مسار بيانات غير مدقق لن تتمكن ضوابط الحماية المحيطية من اكتشافه. ينشأ هذا التدفق من داخل الشبكة، من جهاز مطور من المفترض أن يكون موجودًا.
تسميم وصف الأداة يتجاوز دفاعات طبقة الشبكة
عندما يتصل وكيل بخادم MCP ويستدعي tools/list، يستجيب الخادم بأسماء الأدوات وأوصافها ومخططات المعلمات. يستخدم الوكيل هذه البيانات الوصفية لتحديد الأدوات التي سيتم استدعاؤها وكيفية استدعائها. تلاعب بهذه البيانات الوصفية وستعيد توجيه سلوك الوكيل دون استغلال أي ثغرة أمنية في التعليمات البرمجية.
يُضمّن تسميم وصف الأداة تعليمات ضارة داخل البيانات الوصفية للأداة تتسبب في قيام الوكيل بإجراءات غير مقصودة: مثل تسريب البيانات، أو استدعاء أدوات خارج نطاقها المقصود، أو تجاوز فحوصات الأمان بينما يبدو أنه ينفذ مهمته المخصصة. ينتقل المحتوى الضار داخل نص استجابة HTTP من خادم MCP، وتحديداً ضمن حمولة tools/list. تتمتع جدران الحماية لتطبيقات الويب وأدوات أمان واجهة برمجة التطبيقات (API) القياسية برؤية في نصوص استجابة HTTP، لكنها لا تستطيع اكتشاف هذا الهجوم لأن المحتوى الضار هو لغة طبيعية مضمنة دلاليًا، وليس شذوذًا نحويًا مثل توقيع استغلال معروف أو رأس (header) مشوه. ينجح الهجوم على طبقة الاستدلال، حيث يفسر الوكيل أوصاف الأداة كتعليمات مشروعة ويتصرف بناءً عليها.
تقوم حواجز حماية MCP Pre Tool من TrueFoundry بفحص معلمات الأداة ووسائط الاستدعاء قبل التنفيذ باستخدام اكتشاف حقن الأوامر (Prompt Injection) القائم على النموذج. إذا كانت وسائط استدعاء الأداة تحتوي على تعليمات معاد توجيهها، يتم حظر التنفيذ قبل تشغيل الأداة ويتم تسجيل الاكتشاف في تتبع الطلب.
بيانات اعتماد خادم MCP المشتركة تلغي مساءلة الامتثال
لا يمكن لخوادم MCP التي تستخدم مفاتيح API مشتركة أو رموز حسابات الخدمة إنتاج سجلات التدقيق القابلة للنسبة التي تتطلبها أطر الامتثال. إذا تشاركت عشرة وكلاء مجموعة واحدة من بيانات الاعتماد، فلا توجد طريقة لربط استدعاء أداة معين بمستخدم معين أو مثيل وكيل أو فريق. في بيئة منظمة، هذه الفجوة ليست إزعاجًا. إنها فشل مباشر في الامتثال.
يتطلب قانون HIPAA سجلات تدقيق تُنسب إلى مستخدم أو خدمة محددة لكل وصول إلى معلومات صحية محمية. يتطلب SOC2 CC6 ضوابط وصول مع دليل على التنفيذ. يتطلب مبدأ المساءلة في اللائحة العامة لحماية البيانات (GDPR) من المؤسسات إثبات أن معالجة البيانات كانت مصرحًا بها وموثقة. لا يمكن لعمليات نشر MCP ذات بيانات الاعتماد المشتركة تلبية أي من هذه المتطلبات. تستبدل TrueFoundry بيانات الاعتماد المشتركة برموز الوصول الشخصية (Personal Access Tokens) المرتبطة بالمستخدمين الأفراد ورموز الحسابات الافتراضية (Virtual Account Tokens) للوصول على مستوى التطبيق، بحيث يحمل كل استدعاء أداة هوية قابلة للتحقق.
الركائز الأربع لحوكمة MCP المؤسسية
يتطلب إطار عمل حوكمة MCP المؤسسية الكامل أربع قدرات تعمل معًا: كتالوج مركزي، وضوابط وصول قائمة على الهوية، وتسجيل تدقيق منظم، وتطبيق سياسات في الوقت الفعلي. كل منها يعتمد على الآخر. لا يمكنك فرض سياسات الوصول قبل أن تعرف ما هي الخوادم الموجودة. لا يمكنك بناء مسار تدقيق بدون إسناد الهوية. وسجلات التدقيق اللاحقة بدون تطبيق في الوقت الفعلي هي سجلات جنائية، وليست ضوابط أمنية.
الركائز الأربع: الوظيفة الأساسية، تطبيق TrueFoundry، وتغطية الامتثال
الركيزة 1: كتالوج خوادم MCP مركزي
الكتالوج هو السجل الموثوق لكل خادم MCP معتمد في مؤسستك. يحمل كل إدخال المعلومات التي تحتاجها فرق أمن المعلومات لتقييم المخاطر: اسم الخادم، الفريق المالك، نطاق الوصول إلى البيانات، طريقة المصادقة، حالة الموافقة، معلمات الاتصال، وأي قيود استخدام مثل مجموعات المستخدمين المعتمدة أو حدود المعدل.
تدخل الخوادم الجديدة من خلال سير عمل تدقيق. تقوم مراجعة وصف الأداة بفحص مخاطر التسميم قبل وصول الخادم إلى بيئات المطورين. يحدد تقييم الوصول إلى البيانات ما يمكن للخادم الوصول إليه. تمنع الموافقة الصريحة التوزيع. لا يتطلب أي من هذا تغييرات على خادم MCP نفسه. يحدث ذلك على طبقة الكتالوج، وتبقى تطبيقات الخادم الفردية دون مساس.
يتولى الكتالوج أيضًا عملية التوزيع. يسحب المطورون تكوينات الخادم المعتمدة مسبقًا مباشرةً إلى تكاملات بيئة التطوير المتكاملة (IDE) الخاصة بهم بدلاً من تكوين الخوادم يدويًا. تصل الخوادم المعتمدة من الكتالوج فقط إلى أجهزة المطورين. تمتد ميزة الخادم الافتراضي لـ MCP من TrueFoundry هذا: تقوم فرق المنصة بتكوين مجموعات فرعية من الأدوات المنسقة من خوادم متعددة مسجلة، مع عرض ما يحتاجه فريق معين أو حالة استخدام معينة فقط، دون نشر بنية تحتية جديدة.
الركيزة 2: تسجيل الدخول الموحد (SSO) والتحكم في الوصول إلى خادم MCP على طبقة البوابة
يجب أن يمر الوصول إلى MCP عبر نفس مزود الهوية الذي يحكم كل شيء آخر في المؤسسة. تدعم TrueFoundry تدفقات OAuth2 ثنائية وثلاثية الأرجل، وSAML 2.0، والتكامل المباشر مع Okta، وAzure Active Directory، وAuth0، وCognito، وأي مزود هوية متوافق مع JWKS. يتم توفير وإلغاء توفير الوصول إلى MCP من خلال نفس سير عمل الإعداد والإلغاء الذي يغطي البريد الإلكتروني، والمستودعات، ووحدات تحكم السحابة. عندما يغادر مطور، يذهب وصول MCP معه تلقائيًا.
تدعم البوابة ثلاث طرق مصادقة واردة حسب هوية المتصل. يتم إنشاء رموز الوصول الشخصية (PATs) من الإعدادات > مفاتيح API في واجهة مستخدم TrueFoundry، وهي مرتبطة بالمستخدمين الأفراد، وهي الخيار القياسي لسير عمل التطوير. رموز الحسابات الافتراضية (VATs) هي حسابات خدمة ذات أذونات محددة، ومناسبة لوكلاء الإنتاج وسير عمل الخادم إلى الخادم. تسمح رموز IdP الخارجية للمستخدمين الذين ليس لديهم حسابات TrueFoundry بالمصادقة باستخدام مزود الهوية الخاص بهم، مما يغطي تطبيقات B2B SaaS ونشر الوكلاء الموجهين للعملاء.
للمصادقة الصادرة إلى خوادم MCP النهائية، تدير TrueFoundry دورة حياة بيانات الاعتماد الكاملة عبر ستة أنماط. تتعامل تدفقات رمز تفويض OAuth مع وصول المستخدم الفردي إلى خدمات مثل GitHub و Slack، حيث تدير البوابة الموافقة وتخزين الرمز المميز والتحديث التلقائي. تتعامل تدفقات بيانات اعتماد عميل OAuth مع الوصول من خادم إلى خادم. تغطي أوضاع مفتاح API المشتركة والفردية الحالات الأبسط حيث تقوم البوابة بحقن بيانات الاعتماد الصحيحة لكل طلب. يقوم تمرير الرمز المميز (Token Passthrough) بإعادة توجيه الرمز المميز الوارد دون تغيير عندما يتمكن خادم MCP من التحقق منه مباشرة. يتعامل إعادة توجيه الرمز المميز (Token Forwarding) عبر رأس x-tfy-mcp-headers مع السيناريوهات التي يستخدم فيها خادم MCP نظام بيانات اعتماد منفصلاً.
التحكم في الوصول إلى خادم MCP: أنماط المصادقة عبر سيناريوهات المؤسسات الشائعة
تحدد سياسات التحكم في الوصول المستند إلى الأدوار (RBAC) الفرق أو الأفراد الذين يمكنهم استدعاء أي خوادم وأدوات. توجد هذه السياسات عند البوابة، وليس داخل خوادم MCP الفردية، لذا يسري تحديث السياسة على جميع العملاء فورًا دون إعادة نشر الخادم. يحصل فريق علم البيانات على إمكانية الوصول إلى أدوات التحليلات ولكن ليس إلى خوادم النشر. يحصل فريق الأمن على وصول للقراءة فقط إلى جميع الخوادم لأغراض التدقيق.
الركيزة 3: تسجيل تدقيق منظم مرتبط بكل استدعاء أداة
يتطلب كل استدعاء لأداة MCP إدخال سجل يلتقط سياق الاستدعاء الكامل: الطابع الزمني، هوية المتصل، معرف خادم MCP، اسم الأداة، معلمات الإدخال، ملخص الاستجابة، قرار السياسة مع السبب، نتائج الحواجز الوقائية لكل خطاف (hook) توضح وقت التنفيذ والنتائج، وإجمالي زمن الاستجابة. يجب أن تكون هذه الحقول بتنسيق JSON منظم حتى تتمكن أنظمة SIEM وأدوات إعداد تقارير الامتثال من الاستعلام عنها.
تتحكم TrueFoundry في التسجيل على مستويين. على مستوى الطلب، يلتقط رأس X-TFY-LOGGING-CONFIG مع enabled: true الطلب بالكامل. على مستوى البوابة في عمليات النشر المستضافة ذاتيًا، يحدد متغير البيئة REQUEST_LOGGING_MODE السلوك العام: ALWAYS يسجل كل طلب بغض النظر عن الرؤوس، وهو الإعداد الصحيح لبيئات الإنتاج المنظمة. HEADER_CONTROLLED يتبع إعدادات كل طلب على حدة. NEVER يمنع جميع عمليات التسجيل للبيئات التي يكون ذلك مناسبًا فيها.
سجلات الطلبات مرئية في واجهة مستخدم TrueFoundry ضمن AI Gateway > Monitor > Requests. تظهر نطاقات تنفيذ الحواجز الوقائية الفردية في AI Gateway > Monitor > Request Traces، وتوضح أي الحواجز الوقائية تم تشغيلها على أي خطاف (hook)، وحالة النجاح/الفشل، ووقت التنفيذ، والتعديلات المطبقة. بالنسبة للمؤسسات التي توجه السجلات إلى بنيتها التحتية الخاصة، تقوم TrueFoundry بالتصدير عبر OpenTelemetry إلى Grafana و Datadog و Splunk وأي وجهة متوافقة مع OTLP. في عمليات النشر المستضافة ذاتيًا، تُكتب بيانات السجل إلى تخزين AWS S3 أو GCS أو Azure Blob الخاص بك بتنسيق Parquet، ويمكن الاستعلام عنها عبر Spark أو DuckDB أو Athena.
تتطلب HIPAA الاحتفاظ بالوثائق المتعلقة بالأمان لمدة ست سنوات. عمليًا، غالبًا ما يتم الاحتفاظ بسجلات التدقيق لمدة مماثلة لدعم الامتثال والتحقيق في الحوادث. تتبع العديد من السجلات المالية معيار احتفاظ لمدة سبع سنوات. يجب أن تكون السجلات مقاومة للتلاعب، مع ضوابط وصول تمنع التعديل من قبل الفرق التي تنشئها. تحافظ خيارات النشر المستضافة ذاتيًا من TrueFoundry على جميع بيانات السجل داخل حساب العميل السحابي، مما يدعم متطلبات الاحتفاظ ومقاومة التلاعب.
الركيزة 4: تطبيق سياسة MCP في الوقت الفعلي قبل تشغيل الأداة
تسجيل ما حدث ليس هو نفسه منعه. يجب أن يتم تطبيق السياسة في وقت الاستدعاء، قبل أن يصل استدعاء الأداة إلى خادم MCP، بحيث يتم حظر الوصول غير المصرح به بدلاً من توثيقه بعد وقوعه.
يطبق نظام الحواجز الوقائية (guardrail) الخاص بـ TrueFoundry خطافين (hooks) لكل استدعاء أداة. تعمل الحواجز الوقائية MCP Pre Tool قبل تنفيذ الأداة. إذا فشل أي منها، فلن تعمل الأداة أبدًا، مما يتجنب التكلفة والآثار الجانبية وتعرض البيانات لاستدعاء خاطئ بالكامل. تشمل الحواجز الوقائية المدمجة قبل الأداة ما يلي: منظف SQL، الذي يكتشف أوامر DROP و TRUNCATE و DELETE و UPDATE بدون WHERE، وأنماط استيفاء السلاسل التي تشير إلى خطر الحقن؛ اكتشاف حقن الأوامر (Prompt Injection) باستخدام تحليل قائم على النموذج لمحاولات كسر الحماية والحقن في معلمات استدعاء الأداة؛ اكتشاف الأسرار الذي يكتشف مفاتيح API وبيانات اعتماد AWS ورموز JWT والمفاتيح الخاصة قبل وصولها إلى خدمات الواجهة الخلفية؛ وحواجز سياسة Cedar و OPA للتحكم في الوصول الدقيق والتصريحي وصولاً إلى وسائط الأداة المحددة.
تعمل الحواجز الوقائية MCP Post Tool بعد عودة الأداة، وقبل وصول النتيجة إلى الوكيل. تشمل الحواجز الوقائية المدمجة بعد الأداة: مدقق أمان الكود (Code Safety Linter)، الذي يحدد eval و exec و os.system واستدعاءات العمليات الفرعية وأوامر shell الخطيرة في مخرجات الأداة؛ اكتشاف معلومات التعريف الشخصية (PII)، الذي يجد ويحجب المعلومات الشخصية بفئات كيانات قابلة للتكوين؛ ومطابقة أنماط التعبيرات النمطية (Regex Pattern Matching) للأنماط المخصصة التي تغطي بطاقات الدفع والمعرفات الداخلية والبيانات الحساسة الخاصة بالمجال. يتكامل جميع المزودين الخارجيين بما في ذلك AWS Bedrock Guardrail و Azure Content Safety و Azure Prompt Shield و CrowdStrike و Google Model Armor من خلال نفس نظام الخطافات (hook system).
استراتيجيات التطبيق قابلة للتكوين لكل حاجز وقائي. يمنع "Enforce" عند الانتهاك وعند خطأ الحاجز الوقائي. يمنع "Enforce But Ignore On Error" عند الانتهاك ولكنه يسمح بمرور الطلبات إذا كان مزود الحاجز الوقائي غير متاح، وهو الإعداد الافتراضي الموصى به للإنتاج. "Audit" يسجل الانتهاكات دون حظر، وهو الوضع الصحيح أثناء النشر الأولي. التسلسل الموصى به هو "Audit" أولاً، ثم "Enforce But Ignore On Error"، ثم "Enforce" الكامل مع تزايد الثقة.
نشر بوابة MCP للمؤسسات: خطة تنفيذ من أربع خطوات
حوكمة MCP هي برنامج متسلسل. كل خطوة تبني على سابقتها. لا يمكنك فرض سياسات الوصول قبل أن تعرف ما هي الخوادم الموجودة. لا يمكنك بناء مسار تدقيق ذي معنى قبل تحديد الهوية.
الخطوة 1: جرد جميع عمليات نشر MCP الموجودة
ابدأ بتدقيق كامل لكل خادم MCP قيد التشغيل عبر بيئات المطورين، وخطوط أنابيب CI/CD، وعمليات نشر وكلاء الإنتاج، وتكوينات بيئات التطوير المتكاملة (IDE). يشمل ذلك الخوادم التي قام المطورون بتكوينها محليًا في Cursor أو Claude Code دون تدخل قسم تكنولوجيا المعلومات. يمنح الجمع بين المسح الآلي للبيئات السحابية وعملية الإبلاغ الذاتي لتكوينات المطورين المحليين الصورة الأكثر اكتمالاً للمؤسسات الكبيرة.
سجل لكل خادم: الاسم والغرض، الفريق المالك، نطاق الوصول إلى البيانات، طريقة المصادقة إن وجدت، ومدة تشغيله. الهدف هو الحصول على صورة دقيقة لما هو موجود قبل تطبيق الحوكمة، وليس قائمة منسقة بالأشياء التي تمت الموافقة عليها بالفعل.
الخطوة 2: بناء كتالوج خوادم MCP المعتمدة
قبل ترحيل أي خوادم، حدد مخطط البيانات الوصفية وسير عمل الموافقة. القرارات الرئيسية: من يملك صلاحية الموافقة لمستويات المخاطر المختلفة، وماذا تغطي قائمة مراجعة المراجعة، وما هي النتائج التي تمنع تسجيل الكتالوج. ضع هذه المعايير قبل تصنيف الخوادم لضمان تطبيقها بشكل متسق.
راجع المخزون وصنف كل خادم على أنه موافق عليه للفهرسة، أو قيد المراجعة، أو محظور بانتظار المعالجة. حدد موعدًا نهائيًا صارمًا يجب بموجبه تسجيل جميع خوادم الإنتاج في الفهرس، ووضح بشكل جلي أن الخوادم غير المفهرسة سيتم حظرها عند البوابة بعد ذلك التاريخ. الموعد النهائي يخلق الضرورة التي تدفع الفرق للمشاركة.
الخطوة 3: نشر بوابة MCP وتطبيق تسجيل الدخول الموحد (SSO)
وجه جميع حركة مرور MCP عبر البوابة قبل فرض سياسات الحظر. ابدأ بضبط REQUEST_LOGGING_MODE على ALWAYS. تمر جميع حركة المرور، ويتم تسجيل جميع الاستدعاءات، ولا يتم حظر أي شيء بعد. يمنحك التشغيل في هذا الوضع لمدة تتراوح بين أسبوعين وأربعة أسابيع خطًا أساسيًا لأنماط حركة المرور الحقيقية قبل بدء التنفيذ.
ادمج البوابة مع موفر الهوية الخاص بمؤسستك (IdP) عبر الوصول > المصادقة الخارجية > موفر الهوية في واجهة مستخدم TrueFoundry. بالنسبة لـ Okta التي تستخدم خادم التفويض الافتراضي، فإن URI الخاص بـ JWKS هو https://your-org.okta.com/oauth2/v1/keys. يجب على المؤسسات التي تستخدم خادم تفويض Okta مخصصًا استخدام https://your-org.okta.com/oauth2/{authServerId}/v1/keys بدلاً من ذلك. بالنسبة لـ Azure AD، هو https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys، مع تكوين معرف المستأجر ومعرف العميل كمصدر وجمهور. تحقق من أن كل استدعاء في سجل التدقيق يظهر هوية مستخدم أو وكيل محددة قبل الانتقال إلى التنفيذ. تعني هويات حسابات الخدمة المشتركة في السجلات أن تحديد الهوية غير مكتمل.
الخطوة 4: تمكين التنفيذ وتكوين التنبيهات
بعد فترة الأساس، قم بتمكين تطبيق السياسات: حظر خوادم MCP غير المفهرسة، وتفعيل سياسات التحكم في الوصول المستند إلى الدور (RBAC)، وتطبيق حدود المعدل. أبلغ فرق المطورين بتاريخ التنفيذ بوقت كافٍ لتسريع تسجيل الأدوات المشروعة في الفهرس.
قم بإعداد التنبيهات على بيانات OpenTelemetry المصدرة لأنماط غير طبيعية: أحجام مكالمات غير عادية من هوية وكيل واحدة، الوصول إلى أدوات عالية الحساسية خارج الساعات المعتمدة، انتهاكات السياسة من هويات لا ينبغي أن يكون لديها وصول إلى MCP. توفر لك نتائج الحماية في بوابة الذكاء الاصطناعي > المراقبة > تتبع الطلبات التفاصيل اللازمة لضبط العتبات بمرور الوقت. راجع قواعد التنبيه ربع سنويًا مع نمو نشر MCP الخاص بك.
متطلبات أمان MCP للمؤسسات حسب الصناعة
تظهر ثلاثة متطلبات باستمرار عبر جميع البيئات المنظمة: سجلات وصول قابلة للإسناد مرتبطة بهويات موثقة، وضوابط إقامة البيانات التي تحافظ على البيانات الحساسة ضمن حدود محددة، ووثائق مخاطر البائع للبنية التحتية للحوكمة نفسها.
- الرعاية الصحية (HIPAA): أي خادم MCP يمكنه استقبال معلومات صحية محمية في المعلمات أو الاستجابات يتطلب بوابة معزولة بشبكة VPC. تتطلب استدعاءات الأدوات التي تتضمن معلومات صحية محمية سجلات يتم فيها استبدال معرفات المرضى برموز مرجعية، ويجب توفير الوصول من خلال إدارة الهوية السريرية. يدعم نشر TrueFoundry المستضاف ذاتيًا على AWS GovCloud أعباء العمل المتوافقة مع HIPAA. تعالج Innovaccer ما يقرب من 17 مليون طلب استدلال للذكاء الاصطناعي السريري شهريًا بالكامل ضمن حدود AWS GovCloud الخاصة بها باستخدام TrueFoundry، مع تغذية OpenTelemetry للوحات معلومات Grafana وعدم مغادرة أي بيانات حساسة لمحيط سحابتهم.
- الخدمات المالية (SOC2, FINRA): تقع البنية التحتية لحوكمة MCP ضمن نطاق تدقيقات SOC2 من النوع الثاني إذا كانت تتعامل مع بيانات مالية أو لديها وصول إلى أنظمة السجلات. تشمل الضوابط المطلوبة التشفير أثناء النقل وفي حالة السكون، ومراجعات الوصول ربع السنوية مع أدلة موثقة، وإجراءات الاستجابة للحوادث التي تغطي أوضاع الفشل الخاصة بـ MCP. تحمل TrueFoundry شهادة SOC2 من النوع الثاني وتصدر سجلات تدقيق MCP منظمة بالتنسيق الذي يطلبه المدققون لتقديم أدلة التحكم CC6.
- التأمين والمؤسسات العالمية (GDPR، إقامة البيانات): يجب على المؤسسات المشمولة باللائحة العامة لحماية البيانات (GDPR) الاحتفاظ بسجل لأنشطة المعالجة بموجب المادة 30 يغطي المعالجة بمساعدة الذكاء الاصطناعي، بما في ذلك استدعاءات أدوات MCP. هذا السجل هو وثيقة امتثال منظمة تصف أغراض المعالجة، وفئات البيانات، وعمليات النقل، والضمانات. توفر سجلات تدقيق بوابة MCP بيانات الأحداث الأساسية التي تغذي هذا السجل، ولكن يجب الاحتفاظ بسجل أنشطة المعالجة (RoPA) نفسه بشكل منفصل بواسطة وظيفة حماية البيانات في المؤسسة. تحتاج سجلات البوابة أيضًا إلى التقاط بيانات وصفية كافية لدعم طلبات وصول أصحاب البيانات وتوثيق أي عمليات نقل عبر الحدود تحدث من خلال استدعاءات الأدوات. قد تحظر متطلبات إقامة البيانات حركة مرور MCP من مغادرة مناطق جغرافية محددة، مما يتطلب نشر بوابات إقليمية.
كيف تقدم TrueFoundry حوكمة MCP للمؤسسات
توفر بوابة MCP من TrueFoundry الركائز الأربع للحوكمة من خلال لوحة تحكم واحدة يتم نشرها داخل حساب العميل السحابي الخاص به. تدير فرق المنصة مكدس الحوكمة الكامل من خلال واجهة واحدة دون تعديل تطبيقات خادم MCP الفردية. لا يغادر أي من حركة مرور MCP محيط المؤسسة.
تستخدم شركات مثل NVIDIA وZscaler وSiemens Healthineers وAutomation Anywhere TrueFoundry للانتقال من عمليات نشر MCP المخصصة إلى بيئات محكومة ومنظمة. بالنسبة للمؤسسات التي تشغل أعباء عمل وكلاء الذكاء الاصطناعي على نطاق واسع، أدت ضوابط التكلفة المفروضة بالسياسات، وحدود الميزانية، وطبقة التخزين المؤقت من TrueFoundry إلى تخفيضات ملموسة في الإنفاق الشهري على الاستدلال واستدعاء الأدوات. اتصل بـ TrueFoundry للحصول على أرقام خاصة بالحالة بناءً على حجم الاستدعاء الفعلي ومزيج النماذج لديك.
- كتالوج MCP مركزي مع سير عمل التدقيق: تحتفظ لوحة تحكم TrueFoundry بالسجل الموثوق لخوادم MCP المعتمدة مع البيانات الوصفية وحالة الموافقة ومعلمات الاتصال. تدخل الخوادم الجديدة من خلال عملية تدقيق تتضمن مراجعة وصف الأداة لمخاطر التسمم قبل التوزيع على تكوينات بيئة التطوير المتكاملة (IDE) للمطورين. تتيح ميزة خادم MCP الافتراضي لفرق المنصة تجميع مجموعات فرعية من الأدوات المنسقة من خوادم مسجلة متعددة، مما يعرض فقط ما يحتاجه فريق معين دون نشر بنية تحتية جديدة.
- OAuth2 والتحكم في الوصول المستند إلى الدور (RBAC) في كل استدعاء أداة: يتم مصادقة كل استدعاء لـ MCP عبر OAuth2 باستخدام هوية المؤسسة للمتصل. تتعامل البوابة مع جميع أنماط المصادقة الصادرة الستة وتدير دورة حياة الرمز المميز الكاملة لتدفقات رمز التفويض، وتدفقات بيانات اعتماد العميل، وحقن مفتاح API. يتم تطبيق سياسات RBAC المفروضة عند البوابة فورًا عبر جميع العملاء عند تحديثها، دون الحاجة إلى إعادة نشر الخادم.
- سياسات بيانات وصفية قابلة للتكوين لكل استدعاء: تطبق TrueFoundry إخفاء البيانات عبر اكتشاف معلومات التعريف الشخصية (PII) وحواجز Regex، وحدود المعدل لكل فريق، وحدود التكلفة لكل جلسة وكيل، وقواعد الحظر لفئات الأدوات المقيدة عبر سياسات Cedar أو OPA. يتم تكوين كل ذلك في واجهة الإدارة. لا يلزم إجراء تغييرات على رمز خادم MCP.
- سجلات التدقيق تُبث إلى نظام SIEM الخاص بك: يتم تصدير سجلات تدقيق JSON منظمة لكل استدعاء MCP عبر OpenTelemetry إلى Grafana أو Datadog أو Splunk أو أي وجهة متوافقة مع OTLP. في عمليات النشر المستضافة ذاتيًا، تُكتب السجلات إلى تخزين AWS S3 أو GCS أو Azure Blob الخاص بك بتنسيق Parquet، ويمكن الاستعلام عنها عبر Spark أو DuckDB أو Athena. يضمن `REQUEST_LOGGING_MODE: ALWAYS` التقاطًا كاملاً للبيئات المنظمة.
- نشر معزول بشبكة VPC مع أربعة خيارات: SaaS مُدار بالكامل بدون أعباء بنية تحتية؛ بوابة SaaS مع تخزين بيانات مملوك للعميل؛ مستوى بوابة مستضاف ذاتيًا مع لوحة تحكم TrueFoundry بتكلفة بنية تحتية تبلغ حوالي 600 دولار شهريًا؛ لوحة تحكم كاملة مستضافة ذاتيًا بالإضافة إلى بوابة بتكلفة تتراوح بين 800 دولار و1000 دولار شهريًا. تضمن الخياران الأخيران عدم مغادرة أي حركة مرور لاستدعاء MCP لمحيطك للوصول إلى بنية TrueFoundry التحتية.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
Built for Speed: ~10ms Latency, Even Under Load
The fastest way to build, govern and scale your AI
Sign Up
How Can You Prevent GenAI Costs From Spiraling at Scale?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Discover More
No items found.
No items found.
Recent Blogs
.png)
.webp)
.webp)
Frequently asked questions
What is the difference between an MCP gateway and an MCP proxy, and which does my enterprise need?
An MCP proxy forwards requests from clients to servers with minimal processing. It might add basic routing or logging, but it does not enforce access policies, manage authentication lifecycle, apply guardrails, or maintain a server catalog. A gateway is the full control plane: it governs what is allowed to happen, not just what did happen.
For enterprise use, a proxy is not enough. HIPAA, SOC2, and GDPR all require enforced access controls and attributable audit records. TrueFoundry's MCP Gateway operates in aggregator mode, where a single gateway endpoint routes to multiple registered MCP servers, or in proxy mode where it fronts individual servers on different networks. The governance capabilities are consistent across both deployment patterns.
How does TrueFoundry's MCP governance integrate with our existing Okta or Azure AD identity provider?
Integration is done through Access > External Auth > Identity Provider in the TrueFoundry UI. Click New Identity Provider and enter your JWKS URI, issuer, and optionally the audience for additional token validation. For Okta: JWKS URI is https://your-org.okta.com/oauth2/v1/keys. For Azure AD: https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, with tenant ID as issuer and client ID as audience.
Once registered, create an External Identity mapping JWTs from your IdP to TrueFoundry access, add it as a collaborator on the relevant MCP servers with the appropriate permission level, and developers authenticate using their existing IdP token. The gateway validates the token, checks RBAC, and manages all downstream authentication. Developers never need TrueFoundry-specific credentials.
Can we govern MCP servers that our developers have already deployed without requiring them to rebuild from scratch?
Yes. TrueFoundry registers existing MCP servers through connection parameters: the server URL and outbound authentication configuration. No changes to the server's implementation are required. The server keeps running as-is. The gateway sits in front of it and applies governance controls at the request layer.
The migration path: register each existing server in the TrueFoundry catalog with its connection parameters and outbound auth type. Update client connections to point at the gateway endpoint instead of directly at the server. Enable REQUEST_LOGGING_MODE: ALWAYS in logging-only mode initially to build a traffic baseline. Developers change one URL in their IDE or agent configuration and everything else continues to work.
What audit log fields are captured for each MCP tool invocation, and are they compatible with our SIEM?
TrueFoundry captures: timestamp, caller identity (user ID, team, or Virtual Account name), MCP server identifier, tool name, input parameters, response summary, policy decision with reason, guardrail results per hook including which guardrails ran, pass/fail status, execution latency, and mutations applied, plus total invocation latency. All structured JSON.
For SIEM integration, TrueFoundry exports via OpenTelemetry compatible with Grafana, Datadog, Splunk, New Relic, and any OTLP destination. On self-hosted deployments, logs are written to S3, GCS, or Azure Blob in Parquet format, queryable via Spark, DuckDB, or Athena. The X-TFY-LOGGING-CONFIG header controls per-request logging. REQUEST_LOGGING_MODE controls global behavior at the gateway level.
How does TrueFoundry handle MCP tool description poisoning and prompt injection attacks at the gateway layer?
TrueFoundry addresses tool description poisoning through the MCP Pre Tool guardrail hook, which runs before any tool execution. The Prompt Injection guardrail applies model-based detection to identify manipulated instructions within tool parameters and call context. When call arguments contain redirected or malicious instructions, and enforcement is enabled, execution is blocked before the tool runs, and the detection is recorded in the request trace with a detailed finding.
For the broader prompt injection surface from documents, emails, or web content the agent processes, TrueFoundry's LLM Input guardrails scan the prompt before it reaches the model. Options include Azure Prompt Shield, CrowdStrike, and TrueFoundry's own prompt injection detector. The SQL Sanitizer pre-tool guardrail specifically catches injection attempts targeting database-connected MCP servers. All guardrail results appear in AI Gateway > Monitor > Request Traces.
What is the typical implementation timeline for deploying enterprise MCP governance across a 500-person engineering organization?
The implementation runs in four phases. Phase one covers inventory and catalog build over two to three weeks: auditing existing MCP deployments, defining the catalog schema and approval workflow, and registering discovered servers through the vetting process. Phase two covers gateway deployment and SSO integration over one to two weeks: deploying TrueFoundry in ALWAYS logging mode, connecting to the enterprise IdP, and verifying identity attribution is complete across all invocations.
Phase three runs for two to four weeks in logging-only mode: capturing real traffic patterns, running guardrails in Audit mode to see what would be caught before enabling blocking, and communicating the enforcement timeline to developer teams. Phase four takes approximately one week: switching guardrails from Audit to Enforce But Ignore On Error, enabling RBAC blocking for uncatalogued servers, and setting up alerting on the exported telemetry. Total timeline is typically six to ten weeks for a 500-person organization, with the largest variable being the size of the initial MCP server inventory.
