قام فريق Model context Protocol بترقية امتداد التفويض المُدار للمؤسسات إلى حالة مستقرة، مما يضيف طريقة مركزية للمؤسسات للتحكم في الوصول إلى خوادم MCP من خلال موفر الهوية الخاص بهم. ينص المشروع على أن الهدف هو استبدال مطالبات الموافقة لكل خادم بتدفق بدون لمس حيث يقوم المستخدمون بتسجيل الدخول مرة واحدة ثم الوصول إلى الخوادم المعتمدة دون مزيد من الإعداد.
في إعلان الإطلاق، قال فريق MCP إن الامتداد أصبح الآن مستقرًا وقد تم اعتماده من قبل Anthropic وMicrosoft وOkta وعدد متزايد من خوادم MCP. يقول المنشور أن المجتمع كان واضحًا أن مطالبات التفويض المتكررة تمثل نقطة ألم رئيسية في عمليات نشر MCP للمؤسسات، حيث أن النموذج القياسي مخصص لنطاق المستخدم ومرتبط باتفاقيات المصادقة التفاعلية التي لا تتوسع بشكل جيد في المؤسسات الأكبر.
ويتمثل التأثير العملي في نقل قرار الترخيص إلى موفر هوية المؤسسة، بدلاً من تركه لكل موظف وكل خادم. تقول منشورات المؤسسة أن النتيجة هي تجربة “تسجيل دخول واحد” للخوادم المتصلة وإعداد حيث يرث المستخدمون الوصول إلى الخوادم التي وافقت عليها مؤسستهم. يتم وصف التدفق على أنه يستخدم منحة تفويض JWT لتأكيد الهوية، أو ID-JAG، والتي يتم استبدالها برمز وصول بواسطة خادم ترخيص خادم MCP.
يسلط هذا المنشور الضوء على أهمية تلك الهندسة المعمارية؛ فهو يفصل سياسة الهوية عن استدعاء الأداة نفسها. تقرر الطبقة التي تديرها المؤسسة ما إذا كان يمكن للمستخدم توصيل العميل بالخادم، وفي أي نطاق، ولكنها لا تقوم بفحص حركة مرور MCP بعد إصدار الرمز المميز. يحذر الدليل صراحةً من أن هذا ليس ترخيصًا في وقت التشغيل للإجراءات الفردية، مما يعني أن المؤسسات لا تزال بحاجة إلى ضوابطها الخاصة لما يحدث بمجرد دخول الوكيل داخل النظام.
“يمكن للمؤسسات إدارة الترخيص لخوادم MCP مركزيًا، ويمكن للمستخدمين النهائيين الوصول إلى جميع خوادم MCP المتصلة من خلال تسجيل دخول واحد.”
– مدونة بروتوكول السياق النموذجي
ويشكل هذا الإعلان استجابة للطريقة التي تم بها اعتماد MCP في الممارسة العملية. وتقول إن النموذج القديم لكل مستخدم يخلق عملاً يدويًا للتأهيل، ويجعل من الصعب على فرق الأمان فرض السياسة، ويطمس الخط الفاصل بين الحسابات الشخصية وحسابات العمل. على النقيض من ذلك، يتيح الامتداد الجديد للمسؤولين تحديد السياسة مرة واحدة وتطبيقها من خلال عناصر التحكم في الهوية الحالية.
وقد توصلت العديد من الكتابات الخارجية إلى نفس النتيجة. يصف إحسان حسيني EMA بأنها الحل لـ “الفوضى” التي أنشأها OAuth لكل مستخدم ولكل خادم، ويجادل بأن موفري هوية المؤسسة يصبحون السلطة التي تحدد العملاء الذين يمكنهم الوصول إلى أي خوادم. تفرق هذه المقالة أيضًا بين التحكم على مستوى الاتصال والتحكم في كل إجراء، بحجة أن EMA لا تحل محل تطبيق سياسة منفصلة لقرارات وقت التشغيل الحساسة. تعتبر Okta أول مزود هوية تم ذكره عند الإطلاق، وذلك باستخدام نهج Cross App Access الخاص بها كأول مسار مدعوم للمؤسسات. وهذا يجعل الطرح الحالي خطوة ذات معنى ولكنها لا تزال جزئية، نظرًا لأن النموذج يعتمد على كل من موفر الهوية وخادم MCP الذي يدعم الامتداد. ويشير حسيني إلى أن البروتوكول يظل إضافيًا، لذا فإن المنظمات التي لا تستخدم مزود هوية داعمًا ستظل بحاجة إلى مسار احتياطي.
وكان رد فعل المجتمع إيجابيا على نطاق واسع، وخاصة فيما يتعلق بالوعد بتقليل الاحتكاك. كتب Jiquan Ngiam على LinkedIn أن الامتداد يساعد في معالجة أحد الأجزاء الأكثر فوضوية في استخدام الوكلاء مع البيانات ويمكنه تحسين الأمان وإمكانية المراقبة من خلال تجنب تدفقات المصادقة غير الملائمة. وصفت منشورات أخرى EMA بأنه إصلاح هيكلي للوصول إلى خادم MCP، مشيرة إلى الانتقال من المطالبات لكل مستخدم إلى مستوى التحكم المشترك في المؤسسة.
“لقد سمعنا من المجتمع أن مطالبات التفويض والموافقة المتكررة من خوادم MCP المتصلة هي إحدى أكبر نقاط الضعف عندما يتعلق الأمر بإدارة الاتصال في بيئات المؤسسات.”
– مدونة بروتوكول السياق النموذجي
يسلط الإطلاق الضوء أيضًا على النظام البيئي حول الامتداد الجديد. يقول الإعلان أن Anthropic قامت بتنفيذ الدعم في طبقة MCP المشتركة الخاصة بها لـ Claude وClaude Code وCowork، بينما أضاف Visual Studio Code أيضًا دعمًا في IDE. على جانب الخادم، تم إدراج Asana وAtlassian وCanva وFigma وGranola وLinear وSupabase على أنها تدعم EMA، مع استمرار Slack وغيرها. يشير هذا الاتساع إلى أن المشروع يحاول جعل مصادقة المؤسسة المركزية تبدو وكأنها افتراضية وليست تكاملًا خاصًا. يزيل هذا الإصدار إحدى المشاكل التشغيلية الأكثر وضوحًا في اعتماد المؤسسات لـ MCP والتي قد تكون مهمة للفرق التي تحاول توصيل المساعدين بالأدوات الداخلية على نطاق واسع.
