MCP 2026: مصادقة حقيقية لوكلاء الذكاء

في 28 يوليو 2026 يصل تحديث كبير لمعيار MCP (بروتوكول سياق النموذج) يحمل التاريخ نفسه: 2026-07-28. النسخة المرشّحة (RC) نزلت في 21 مايو، والإصدار النهائي يوم 28 يوليو. أبرز ما فيه؟ إعادة بناء طبقة المصادقة والتفويض لوكلاء الذكاء الاصطناعي، من منطق "أحضر رمزك بنفسك" إلى نموذج أمني موحّد على مستوى البروتوكول.

المشكلة اللي كبرت مع انتشار الوكلاء

في البدايات كان التفويض في MCP شبه غير معرّف: كل خادم يتدبّر أمره وحده. هذا يمشي مع خادم واحد، لكن الواقع اليوم وكيل واحد يتكلم مع عدة خوادم MCP في آنٍ واحد. هنا تصير دلالات التفويض الضعيفة الفرق بين وكيل مفيد وحادثة أمنية: رمز (token) صادر للخادم A ممكن يُساء استخدامه للوصول إلى الخادم B، أو يُعاد تشغيله عبر خوادم مختلفة. المسألة مو تفصيلًا صغيرًا في التنفيذ؛ هي جوهر الثقة.

وش تغيّر فعليًا

التحديث يجعل خوادم MCP خوادم موارد (resource servers) وفق OAuth 2.1، بقواعد واضحة:

بيانات المورد المحمي (RFC 9728): كل خادم يكشف نقطة .well-known/oauth-protected-resource أو يضيف resource_metadata في ترويسة WWW-Authenticate، عشان يعرف العميل من أين يطلب الإذن.
ربط الجمهور (RFC 8707): العميل يحدد صراحةً أي خادم يقصده الرمز، فما يقدر خادم خبيث ياخذ رمزًا مخصصًا لغيره.
التحقق من المُصدِر: العميل يتأكد من هوية خادم التفويض ويربط بيانات الاعتماد به، ويقفل باب إعادة التشغيل عبر الخوادم.
CIMD بدل التسجيل الديناميكي: صار المفضّل هو Client ID Metadata Documents بدل DCR (RFC 7591)، مع بقاء DCR للتوافق الخلفي.

وما وقف الأمر عند المصادقة: البروتوكول تحوّل إلى تصميم عديم الحالة (stateless)، ودعم JSON Schema 2020-12 كاملًا لمخططات الأدوات، وإطار إضافات بمعرّفات عكسية النطاق.

مثال عملي

يبدأ التدفّق برفض 401 يوجّه العميل إلى مكان الإذن:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

فيقرأ العميل بيانات المورد المحمي:

{
"resource": "https://mcp.example.com",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["tools.read", "tools.call"],
"bearer_methods_supported": ["header"]
}

ثم يطلب رمزًا مربوطًا بهذا الخادم تحديدًا عبر مُعرّف المورد:

POST /token HTTP/1.1
grant_type=authorization_code&code=...&resource=https://mcp.example.com

قيود لازم تعرفها

النسخة لا تزال مرشّحة حتى 28 يوليو، وفيه نافذة ~10 أسابيع لصُنّاع الـ SDK للتحقق والتوافق.
DCR ما زال مدعومًا، لكن CIMD هو المسار المفضّل؛ وعملاء سطح المكتب وواجهة الأوامر يحتاجون تسجيلًا يطابق واقع النشر (مثل عناوين localhost).
على الخوادم القائمة عبء ترحيل: كشف بيانات المورد، والتحقق من الجمهور والمُصدِر، وضبط النطاقات (scopes).

الخلاصة

نقل الأمان إلى مستوى البروتوكول يحوّل المصادقة من عبء يعيد كل خادم اختراعه إلى أساس مشترك جاهز للمؤسسات. الوكلاء الأكثر أمانًا يقدرون يعملون أكثر، والأدوات الآمنة تُضاعف قدرة المطوّر لا تُلغيها — تمامًا مثل ما تابعنا في ميثود QUERY الجديدة في HTTP: طبقة المعايير تنضج خطوة خطوة. من يجهّز خوادمه اليوم، يدخل 28 يوليو وهو جاهز.

المصدر الأساسي: مستودع مواصفة MCP الرسمي.