مخاطر أمان MCP وأفضل الممارسات في عام 2026

عندما أطلقت Anthropic بروتوكول سياق النموذج في أواخر عام 2024، فقد عالج مشكلة حقيقية. فبدلاً من كتابة تعليمات برمجية تكامل مخصصة لكل أداة يحتاجها وكيل الذكاء الاصطناعي، أصبح بإمكان الفرق ربط الوكلاء بقواعد البيانات وواجهات برمجة التطبيقات والأنظمة الداخلية عبر واجهة موحدة. كان التبني سريعًا. وبحلول عام 2025، تم نشر عشرات الآلاف من خوادم MCP عبر بيئات المؤسسات.

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

وثّق باحثو الأمن العواقب بسرعة. أظهرت CVE-2025-49596، بدرجة CVSS 9.4، أنه يمكن استغلال مثيلات MCP Inspector غير المصادق عليها لتنفيذ أوامر عشوائية. وأظهرت Invariant Labs أن خادم MCP خبيث يمكنه سحب سجل رسائل واتساب بالكامل بصمت. كما أظهر حادث وكيل Supabase Cursor في يونيو 2025 كيف يمكن خداع وكيل مميز يعالج تذاكر الدعم المقدمة من المستخدمين لتسريب رموز التكامل من خلال حقن الأوامر.

هذه ليست حالات هامشية ناتجة عن تجارب سيئة التصميم. لقد حدثت في أنظمة إنتاج حقيقية لأن بنية MCP تخلق أسطح هجوم لم تُصمم أدوات الأمن التقليدية لرؤيتها. 

تتناول هذه المقالة مخاطر أمن MCP المحددة التي تواجهها المؤسسات، والضوابط التي تعالجها، ولماذا النهج الذي تستخدمه لفرض تلك الضوابط لا يقل أهمية عن الضوابط نفسها.

Your AI Agents Have Access to Everything, Does Your Security?

TrueFoundry enforces identity-aware execution and granular RBAC inside your private cloud environment.

Book Demo

أهم 5 مخاطر أمن MCP التي تواجه المؤسسات

هذه هي مخاطر أمن MCP الخمسة الأكثر شيوعًا في عمليات نشر MCP.

وصول الوكيل مفرط الامتيازات

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

يحدد مشروع OWASP MCP Top 10، الذي أُطلق خصيصًا لتتبع ثغرات MCP، الوصول مفرط الامتيازات كمخاطرة أساسية. فعندما يحمل وكيل دعم العملاء نفس بيانات الاعتماد التي يمتلكها مسؤول قاعدة البيانات، فإن هجومًا واحدًا ناجحًا ضد هذا الوكيل لا يكشف عن قائمة انتظار الدعم، بل يكشف قاعدة البيانات بأكملها. ويتناسب نطاق تأثير أي اختراق طرديًا مع مقدار الوصول الممنوح للوكيل.

هذا ليس مصدر قلق نظري. تضمن حادث Supabase وكيلًا يعمل بامتيازات وصول دور الخدمة ويعالج مدخلات تحتوي على محتوى يتحكم فيه المهاجم. مستوى الامتياز هو ما جعل الهجوم ممكنًا. وكيل مقيد بالوصول للقراءة فقط لبيانات الدعم لم يكن ليمتلك بيانات الاعتماد اللازمة لسحب رموز التكامل.

حقن الأوامر عبر المحتوى الخارجي

يُصنف حقن الأوامر كأهم ثغرة أمنية في قائمة OWASP Top 10 لتطبيقات LLM لعام 2025، وتتخذ طابعًا مختلفًا في بيئات MCP مقارنة بعمليات نشر روبوتات الدردشة البسيطة. فعندما يمتلك الوكيل القدرة على تنفيذ الإجراءات، فإن الحقن الناجح لا ينتج عنه مجرد مخرج سيء، بل يمكن أن يؤدي إلى عمليات حقيقية: إرسال رسائل بريد إلكتروني، استدعاء واجهات برمجة التطبيقات، تعديل السجلات، أو إعادة توجيه البيانات إلى عناوين خارجية.

نمط الهجوم غير مباشر. لا يحتاج المهاجم إلى الوصول إلى أنظمتك. يقومون بتضمين تعليمات خبيثة داخل المحتوى الذي سيعالجه الوكيل كجزء من عمله الطبيعي: ملف PDF يُطلب منه تلخيصه، بريد إلكتروني لعميل يقوم بتوجيهه، صفحة ويب يقرأها للبحث. يقرأ الوكيل المحتوى، ويصادف التعليمات المضمنة، ولأنه لا يوجد حد فاصل صارم بين البيانات والتعليمات في كيفية معالجة نماذج اللغة للسياق، فإنه يفسر تلك التعليمات على أنها مشروعة ويتصرف بناءً عليها.

كتب باحث الأمن سيمون ويليسون، الذي تتبع هذه المشكلة منذ عام 2022: ""لا تزال لعنة حقن الأوامر تتمثل في أننا نعرف هذه المشكلة منذ أكثر من عامين ونصف، ولا يزال ليس لدينا حلول تخفيف مقنعة."

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

تسميم الأدوات وهجوم سحب البساط

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

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

أظهرت Invariant Labs نوعًا مختلفًا من هذا في عام 2025، موضحًا كيف يمكن لخادم MCP ضار في نفس سياق الوكيل مثل خادم WhatsApp MCP شرعي، أن يستخدم تسميم الأدوات لقراءة وتصدير سجل رسائل المستخدم بالكامل بصمت. لم يتطلب الهجوم أي خطأ من المستخدم ولا استغلالًا على مستوى الشبكة.

هجوم ذو صلة هو "سحب البساط" (rug pull)، حيث تتصرف الأداة بشكل مشروع عند التثبيت ثم تغير سلوكها بصمت بعد أن يمنحها المستخدم الأذونات. يمكن لخوادم MCP تحديث تعريفات الأدوات دون إخطار العميل، ومعظم العملاء لا يشيرون إلى هذه التغييرات أو يكتشفونها. 

انتشار بيانات الاعتماد عبر خوادم MCP غير الخاضعة للرقابة

في البيئات التي تفتقر إلى إدارة مركزية لبيانات الاعتماد، يحتفظ كل خادم MCP بتكوين المصادقة الخاص به. يقوم المطورون بتخزين مفاتيح API في متغيرات البيئة، ويقومون بتضمينها بشكل ثابت OAuth الرموز المميزة في ملفات التكوين، ويستخدمون بيانات اعتماد حسابات الخدمة طويلة الأمد لأنها أسهل في الإدارة من الرموز المميزة قصيرة الأمد ومحدودة النطاق. كشفت الأبحاث التي تتبعت عمليات نشر MCP عن 492 خادم MCP مكشوفًا للعامة يفتقر إلى المصادقة الأساسية أو التشفير.

CVE-2025-6514، ثغرة أمنية حرجة في حقن أوامر نظام التشغيل (OS command injection) في mcp-remote، وهو وكيل OAuth بأكثر من 437,000 عملية تنزيل يُستخدم في عمليات التكامل من Cloudflare و Hugging Face و Auth0، أظهرت البعد المتعلق بسلسلة التوريد لهذا الخطر. 

يمكن لنقطة نهاية MCP ضارة إرسال عنوان URL مصمم للمصادقة (authorization URL)، والذي يقوم mcp-remote بتمريره مباشرة إلى غلاف النظام (system shell)، مما يحقق تنفيذ التعليمات البرمجية عن بعد على جهاز العميل، ويوفر الوصول إلى مفاتيح API وبيانات اعتماد السحابة والملفات المحلية ومفاتيح SSH المخزنة على هذا الجهاز.

نقاط عمياء في التدقيق تخل بالامتثال

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

بالنسبة للمؤسسات التي تعمل بموجب SOC 2 أو HIPAA أو GDPR، هذه ليست فجوة بسيطة. يتطلب SOC 2 دليلًا على ضوابط إدارة البيانات ومعالجتها. تتطلب HIPAA مسارات تدقيق لكل وصول إلى النظام يمس معلومات صحية محمية، تُنسب إلى مستخدم أو خدمة قابلة للتحديد. يتطلب GDPR القدرة على إظهار البيانات التي تمت معالجتها، ومتى، ومن قبل من. يفشل نشر MCP بدون تسجيل تدقيق منظم في تلبية كل هذه المتطلبات في وقت واحد.

كشف استطلاع أُجري عام 2025 حول استخدام أنظمة الذكاء الاصطناعي في بيئات الشركات أن أقل من 30% من أنظمة الذكاء الاصطناعي لديها مسارات تدقيق منظمة لوصول أدوات الوكيل. وأقل من 15% يمكنها إعادة بناء مسار القرار الكامل لإجراء الوكيل.

عندما يقع حادث أمني في تلك البيئة، يعتمد التحقيق على إعادة البناء الجنائي من سجلات غير مكتملة، مما يضيف أسابيع إلى وقت الاستجابة للحوادث، ويجعل من شبه المستحيل تقديم أدلة جاهزة للمدققين.

أفضل ممارسات أمان MCP الأساسية

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

فرض التنفيذ المدرك للهوية

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

النهج الصحيح هو المصادقة بالنيابة عن (OBO)، حيث يحمل كل طلب من وكيل الذكاء الاصطناعي ويمارس الصلاحيات الدقيقة للمستخدم البشري الذي بدأه. عندما يستعلم مطور عن مصادر البيانات من خلال وكيل متصل بـ MCP، تتم العملية بمستوى وصول المطور، وليس ببيانات اعتماد مستوى المسؤول التي قد تكون مهيأة على الخادم. يكون الوصول مقيدًا بما هو مصرح لذلك الشخص بفعله في أي مكان آخر في المؤسسة.

يتطلب هذا التكامل مع موفر الهوية الخاص بمؤسستك، سواء كان Okta أو Azure AD أو إعداد تسجيل دخول موحد (SSO) مخصصًا. وهذا يعني تسجيل عميل ديناميكي وتدفقات رمز التفويض حيث تكون الرموز المميزة محددة النطاق للمستخدم، وقصيرة الأجل، ويتم تحديثها تلقائيًا بدلاً من المفاتيح الثابتة طويلة الأجل التي تستمر حتى يقوم شخص ما بإلغائها يدويًا.

تطبيق التحكم الدقيق في الوصول المستند إلى الدور على مستوى الأداة

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

المتطلب العملي هو: يجب أن يكون وكيل دعم العملاء قادرًا على استدعاء عمليات القراءة على خادم CRM، ولكن ليس عمليات الحذف. يجب أن يكون وكيل المالية قادرًا على الاستعلام عن سجلات الدفع، ولكن ليس بدء تحويلات صادرة. لا يمكن التعبير عن هذه الفروقات من خلال سياسات الوصول على مستوى الخادم. إنها تتطلب التحكم في الوصول المستند إلى الدور (RBAC) على مستوى الأداة، حيث تحمل كل أداة داخل الخادم متطلبات التفويض الخاصة بها ويتم تقييم تلك المتطلبات لكل عملية استدعاء.

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

طلب موافقة بشرية للإجراءات التي لا رجعة فيها

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

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

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

دمج اتصالات الأدوات في سجل مركزي مُدار واحد

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

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

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

الاحتفاظ بسجلات تدقيق شاملة ومنظمة

يجب تسجيل كل حدث مصادقة، وإصدار رمز مميز، واستدعاء أداة، وقرار سياسة ببيانات وصفية منظمة تتضمن من قام بالطلب، والوكيل الذي نفذه، والأداة التي تم استدعاؤها، والوسائط التي تم تمريرها، وما تم إرجاعه، وما إذا تم تطبيق أي سياسة أو تم تجاوزها.

الفرق بين وجود سجلات ووجود سجلات جاهزة للامتثال كبير. سجلات التدقيق التي تسجل أسماء الأدوات والطوابع الزمنية تلبي متطلبًا تقنيًا ضيقًا. أما السجلات التي تسجل هوية المستخدم، وهوية الوكيل، وسياق الطلب الكامل، والسياسات المطبقة، ومحتوى الإخراج بتنسيق منظم يمكن الاستعلام عنه وتصديره عند الطلب، فإنها تلبي متطلبات SOC 2 و HIPAA و GDPR. هذه أمور مختلفة، والفجوة بينها هي حيث تحدث معظم إخفاقات التدقيق.

يجب الاحتفاظ بالسجلات ضمن بيئتك الخاصة. السجلات الموجودة في نظام SaaS تابع لجهة خارجية ليست تحت سيطرتك الكاملة، ولا يمكن إنتاجها عند الطلب بيقين تام، وقد تخضع هي نفسها لقيود معالجة البيانات التي تتعارض مع ما يتطلبه إطار الامتثال الخاص بك.

عيوب حلول السوق الحالية

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

• بوابات API القديمة لا يمكنها قراءة نية الوكيل. صُممت بوابات API التقليدية لحركة مرور HTTP بين الخدمات. فهي تفحص الرؤوس، وتفرض تحديد المعدل، وتطبق مصادقة MCP على طبقة النقل. مهمة وكيل الذكاء الاصطناعي التي تؤدي إلى استدعاءات أدوات لـ 20 أداة MCP مختلفة تولد حركة مرور تبدو، على مستوى الشبكة، كسلسلة من الطلبات المشروعة والموثقة. لا يوجد شيء في غلاف HTTP يكشف ما إذا كانت تلك الطلبات مدفوعة بإجراء مستخدم أو بتعليمات محقونة مدفونة في مستند قرأه الوكيل قبل ثلاث خطوات. البوابات التي لا تستطيع تحليل دلالات بروتوكول MCP لا يمكنها اكتشاف أو إيقاف متجهات الهجوم على الطبقة الدلالية ضد تطبيقات الذكاء الاصطناعي.

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

• تنهار التكوينات مفتوحة المصدر التي تُصنع ذاتيًا عند التوسع. يجنب بناء وكيل مخصص من مكونات مفتوحة المصدر رسوم البائعين ويمنح فرق الهندسة أقصى قدر من التحكم، ولكنه يخلق التزامات صيانة تنمو بشكل أسرع من الفرق التي تديرها. تسجيل الأدوات من خلال ملفات YAML أو JSON الثابتة يعني أن كل تكامل جديد يتطلب تعديلاً يدويًا، ومراجعة للتعليمات البرمجية، ونشرًا. لا يمكن تغيير سياسات RBAC المكتوبة في ملفات التكوين في الوقت الفعلي. يتطلب تسجيل التدقيق أدوات مخصصة لكل خادم. عندما تدير عددًا قليلاً من الوكلاء، يكون هذا قابلاً للإدارة. عندما تدير العشرات، يصبح مشكلة هندسة منصات بدوام كامل.

Legacy Gateways Cannot Read Agent Intent, Your MCP Security Layer Must

Get semantic-aware governance, credential vaulting, and SOC 2 audit trails built in with TrueFoundry.

Book Demo

تأمين سير عمل الوكلاء باستخدام TrueFoundry

بوابة TrueFoundry لـ MCP مبنية على فرضية أن الضوابط التي تحتاجها الشركات لتشغيل MCP بأمان في الإنتاج لا يمكن إضافتها إلى البنية التحتية الحالية. بل يجب أن تكون جزءًا من البنية التحتية.

يتم نشر البوابة بالكامل ضمن بيئة العميل على AWS أو GCP أو Azure. يبقى كل طلب أداة، وكل مكالمة اكتشاف، وكل زوج من المطالبة والاستجابة داخل حدود شبكة المؤسسة. لا توجد طبقة توجيه SaaS أو بنية تحتية لجهة خارجية في مسار البيانات. لا توجد تبعية خارجية تخلق خطر خروج البيانات. هذا مهم ليس فقط للامتثال ولكن لنموذج التهديد: البيانات التي لا تغادر بيئتك لا يمكن اعتراضها أثناء النقل.

• حقن هوية OAuth 2.0 مع تدفقات "بالنيابة عن": يعمل الوكلاء بموجب الأذونات الدقيقة للمستخدم الطالب، الموروثة من خلال مزود الهوية الحالي للمؤسسة. يتم دعم إعدادات Okta و Azure AD و SSO المخصصة بشكل جاهز. لا توجد حسابات خدمة مشتركة. يُنسب كل استدعاء أداة إلى هوية بشرية محددة، مما ينتج عنه سلسلة مساءلة تصمد أمام أي مراجعة امتثال.

• تطبيق RBAC على مستوى الأداة عند طبقة البوابة: تُطبق سياسات الوصول قبل وصول الطلبات إلى أي نموذج أو أداة. يعرض السجل الأدوات المصرح لكل دور أو فريق باستخدامها فقط، وليس كامل مساحة السطح لكل خادم متصل. يرى وكيل الدعم أدوات البحث في إدارة علاقات العملاء (CRM)، ولا يرى أوامر إدارة قواعد البيانات. يتم فرض هذا التمييز على مستوى المنصة، وليس بموجب اتفاق المطورين.

• تجريد خادم MCP الافتراضي لحماية سلسلة التوريد: تقع تطبيقات الأدوات الخلفية خلف طبقة تجريد افتراضية في السجل. عندما تتغير التطبيقات الأساسية لأداة ما، أو عندما تحتاج أداة مخترقة إلى الاستبدال، يحدث التغيير في السجل دون المساس بأي من الوكلاء الذين يعتمدون عليها. هذا أيضًا يحمي الوكلاء من هجمات سحب البساط (rug pull attacks): يتم التحكم في إصدار تعريفات الأدوات عبر السجل، ويتم تتبع التغييرات في بيانات تعريف الأداة وتدقيقها.

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

• سجلات التدقيق المهيكلة المحتفظ بها داخل بيئتك الخاصة: يتم تسجيل كل طلب ببيانات وصفية كاملة: هوية المستخدم، هوية الوكيل، النموذج، الأداة، الوسائط، الاستجابة، السياسات المطبقة، زمن الاستجابة، والتكلفة. يتم الاحتفاظ بالسجلات في البنية التحتية الخاصة بالعميل ويمكن تصديرها بتنسيق JSON مهيكل للتكامل مع Grafana، Splunk، Datadog، أو أي خط أنابيب مراقبة موجود. تستخدم Innovaccer، التي تعالج ما يقرب من 17 مليون طلب استدلال للذكاء الاصطناعي شهريًا بموجب HIPAA في AWS GovCloud، القياس عن بعد المهيكل من TrueFoundry عبر OpenTelemetry وتعرضه في Grafana، دون أن تغادر أي بيانات حساسة حدود سحابتها على الإطلاق.

هل ترغب في تجربة بوابة الذكاء الاصطناعي من TrueFoundry؟ احجز عرضًا توضيحيًا اليوم!

الخلاصة: جعل MCP آمنًا للإنتاج

حل MCP مشكلة التكامل، لكنه لم يحل مشكلة الحوكمة. عشرات الآلاف من خوادم MCP المنتشرة في بيئات الشركات في عام 2025 خلقت قدرًا هائلاً من الإمكانيات الجديدة، وتوسعًا كبيرًا بنفس القدر في سطح الهجوم لم تكن معظم المؤسسات مجهزة لحوكمته.

الحوادث التي وقعت بالفعل، بما في ذلك Supabase، Asana، Atlassian، و mcp-remote CVE، لم تكن ناجمة عن هندسة سيئة. بل كانت ناجمة عن بنية لم تأخذ في الاعتبار متطلبات الأمان لبيئات الإنتاج المؤسسية. لم يتم بناء البروتوكول الأساسي مع وضع تلك المتطلبات في الاعتبار.

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

TrueFoundry تنشر جميع هذه الضوابط داخل سحابتك الخاصة. تبقى بياناتك حيث تنطبق حوكمتك. سجلات التدقيق الخاصة بك هي ملكك لإنتاجها والاستعلام عنها وتصديرها وفقًا لجدولك الزمني.