نشر MCP مواصفة مستقرة لـ "Enterprise-Managed Authorization"؛ أما مسودات الهوية الأخرى من آلة إلى آلة (machine-to-machine)—بما في ذلك مسودة OAuth client-credentials ومقترحان مفتوحان—فلا تزال غير مكتملة. بالنسبة لأي شخص يحاول تشغيل وكلاء مستقلين (autonomous agents) باستخدام Model Context Protocol، فإن هذا يعني أن البروتوكول الحالي يمكنه التحقق من هوية مستخدم بشري، ولكنه لا يوفر وسيلة جاهزة للاستخدام لإثبات أن عملية غير خاضعة للإشراف هي بالفعل ما تدعي أنه هو.
لماذا تهم خارطة الطريق
تدرج خارطة طريق Model Context Protocol (MCP) هوية الوكلاء وأمنهم ضمن أولوياتها القصوى. كان من المقرر إصدار أربعة عناصر: تدفق عبر المتصفح متمحور حول الإنسان، وتدفق OAuth client-credentials للخدمات، وربط الرموز (token binding) القائم على DPoP، وآلية اتحاد هوية أعباء العمل (workload-identity federation). فقط العنصر الأول—Enterprise-Managed Authorization—وصل إلى الحالة المستقرة.
ما تفعله المواصفة المستقرة فعلياً
تسمح مواصفة Enterprise-Managed Authorization لمسؤولي تقنية المعلومات بمنح الوصول إلى الخادم من وحدة تحكم واحدة بدلاً من مطالبة كل موظف بالموافقة على كل اتصال. يستخدم هذا التدفق إعادة توجيه عبر المتصفح وتسجيل دخول المستخدم، بحيث يمكن لشخص ما عبر جهاز كمبيوتر محمول إجراء المصادقة، ومن ثم يثق الخادم في جلسة ذلك المستخدم.
القصور هنا واضح: العملية تتطلب وجود إنسان أمام لوحة المفاتيح. فالوكيل الذي يعمل طوال الليل، أو يعالج البيانات، أو يستجيب للتنبيهات، ليس لديه أحد ليضغط على زر تسجيل الدخول. وبناءً على ذلك، فإن أي عملية نشر تعتمد على وكلاء غير خاضعين للإشراف لا يمكنها استخدام المواصفة الوحيدة التي يضمنها MCP حالياً.
خيارات المسودة وعيوبها
تهدف ملحقتان من المسودات إلى منح الوكلاء هويتهم الخاصة:
- SEP-1932 (DPoP) – يربط الرموز (tokens) بزوج مفاتيح عام وخاص، مما يجعل الرموز المسروقة عديمة الفائدة.
- SEP-1933 (Workload Identity Federation) – يسمح للوكلاء بوراثة الهويات التي تم توفيرها بالفعل في المنصات السحابية.
كلاهما موجود كطلبات سحب (pull requests) مفتوحة؛ ولم يتم دمج أي منهما في المواصفة الرسمية بعد. وفي هذه الأثناء، الخيار الموثق الوحيد الآخر هو تدفق OAuth client-credentials الذي يتطلب أسراراً مسجلة مسبقاً. إن تخزين هذه الأسرار في مكان يمكن للوكيل قراءته يخلق سطح هجوم كلاسيكي: إذا تسرب السر، يمكن لأي مهاجم انتحال صفة الوكيل.
خطوات عملية للإنتاج اليوم
بما أن البروتوكول لا يوفر بعد هوية أصلية للوكيل، لا تزال بإمكان الفرق تأمين الوكلاء من خلال نقل إدارة الهوية خارج نطاق MCP:
- إصدار هويات قابلة للتحقق عند طبقة أعباء العمل. تقوم أنظمة مثل SPIRE بإنشاء شهادات قصيرة العمر مرتبطة بجذر الثقة (trust root) للمضيف، مما يلغي الحاجة إلى الأسرار الثابتة.
- إنهاء الاعتمادات عند بوابة (gateway). تحتفظ خدمة الواجهة الأمامية بمفتاح API أو الرمز (token) وتقوم بتوجيه الطلبات نيابة عن الوكيل، مما يبقي السر بعيداً عن بيئة التشغيل.
- التفويض بناءً على الهوية المتحقق منها، وليس محتوى الرمز. افصل بين المصادقة (من الذي يتصل) والتفويض (ما الذي يمكنهم فعله) حتى يمكن فرض السياسات حتى لو تغيرت طريقة المصادقة.
ما يجب مراقبته لاحقاً
يعد طلبا السحب المفتوحان—ربط DPoP واتحاد هوية أعباء العمل—المسارين الوحيدين للوصول إلى معيار حقيقي لهوية الآلة إلى الآلة (machine-to-machine) ضمن MCP. إذا دمج المجتمع هذين الطلبين، فسيتمكن الوكلاء من إثبات حيازتهم لمفتاح خاص أو وراثة هويات صادرة عن السحابة دون الكشف عن الأسرار. وحتى ذلك الحين، يجب أن يعتمد أي نشر في بيئة الإنتاج على أطر هوية خارجية أو قبول مخاطر الاعتمادات الثابتة.
الخلاصة واضحة: يمكن لـ MCP حالياً مصادقة الشخص الذي يقف وراء الطلب، لكنه لا يصادق بعد البرمجيات التي تقوم بالطلب. الفرق التي تحتاج إلى وكلاء مستقلين آمنين يجب ألا تنتظر وصول المواصفة؛ بل يجب عليها بناء الهوية عند طبقة أعباء العمل اليوم ومراقبة مقترحات DPoP والاتحاد المعلقة.