البروتوكول هو المحيط
بُنيت وسائط النقل على نمط MCP لمتصل واحد موثوق يستدعي الأدوات. في هذا النموذج، النقل مجرد أنبوب: ينقل إطارات JSON-RPC بين عميل وخادم، وتحدث قرارات الأمان المهمة فوقه، في تنفيذ الأداة. وعندما تُستخدم الوسيطة نفسها لوكلاء أقران ذوي هويات متباينة، يصبح الأنبوب هو المحيط. وكل قفزة تعيد تسلسل الطلب هي موضع تُفقد فيه الأصالة. فالرسالة التي بدأت كطلب مستخدم، ثم أعاد وكيل التخطيط صياغتها، ثم مرّرها وكيل الاسترجاع، تصل إلى خادم الأدوات دون أي مؤشر موثوق على من طلب ماذا.
ويزيد الخلط بين اكتشاف القدرات وتفويض القدرات الأمر سوءًا. الاكتشاف يجيب عن سؤال «ما الذي يمكن لهذه النقطة الطرفية فعله؟» والتفويض يجيب عن سؤال «هل يُسمح لهذه الهوية باستدعاء تلك القدرة لهذه المهمة؟» عادةً ما تكشف سجلات نمط MCP الأول وتترك الثاني للمتصل. في نموذج المتصل الواحد، هذا مقبول. أما في نموذج وكلاء الأقران، فهذا يعني أن أي وكيل يستطيع الوصول إلى السجل يمكنه تعداد سطح القدرات بالكامل ومحاولة الاستدعاء، دون أن يكون لدى الوكيل المستقبِل أي أساس على مستوى النقل للرفض. فيتحول السجل إلى خريطة لسطح الهجوم، تُسلَّم إلى كل مشارك.
هذا ليس عيبًا في MCP كبروتوكول أدوات. بل هو خطأ تصنيفي أن توسّع بروتوكول أدوات ليشمل المراسلة بين الأقران دون إعادة فحص نموذج الثقة فيه. السؤال المهم ليس ما إذا كانت الإطارات سليمة البنية، بل ما إذا كان النقل قادرًا على إثبات من أرسلها، وباسم من، وتحت أي قيود.
انتحال الهوية بين وكلاء يتشاركون مساحة أسماء
عندما يُعرَّف الوكلاء بسلسلة نصية في حقل رسالة بدلًا من هوية تشفيرية، يستطيع أي وكيل ادعاء أي هوية. في سرب يخاطب فيه المخطِّط عاملًا بالاسم، يمكن لعامل مخترَق أو معطوب فحسب أن يرسل رسائل تبدو صادرة من المخطِّط. ولا يستطيع الوكلاء اللاحقون التمييز بين تعليمة حقيقية وأخرى مزوّرة، لأن النقل لا يحمل توقيعًا ولا ارتباطًا بالقناة. والفشل صامت: الرسالة المزوّرة سليمة البنية، والقدرة موجودة، والاستدعاء ينجح.
تدفقات النائب المُلبَّس
يمرّر وكيل منخفض الصلاحيات استدعاءً عالي الصلاحيات. يحدث هذا كلما فوّض النقل الاتصال بدلًا من الرسالة. فالوكيل الذي يحمل اعتمادًا واسعًا لعمله المشروع يمكن أن يُدفع لاستخدام ذلك الاعتماد نيابةً عن متصل لا ينبغي أن يملكه. النائب ليس خبيثًا؛ إنه يفعل ما يسمح به البروتوكول. والعلاج الكلاسيكي — التحقق من هوية المتصل — يفشل لأن المتصل هو النائب، والنائب مُفوَّض. وما ينقص هو ارتباط بين الهوية الأصلية والاستدعاء المحدد.
إعادة تشغيل الرسائل عبر التشغيلات الطويلة الأفق
تحفظ تشغيلات الوكلاء الطويلة الأفق حالتها وتستأنف. وإذا لم يحمل النقل قيمة nonce تنجو من نقطة الحفظ، يمكن إعادة تشغيل رسالة التُقطت في خطوة ما في خطوة أخرى. وقد تكون إعادة التشغيل صحيحة دلاليًا: القدرة لا تزال موجودة، والوسائط لا تزال تُحلَّل، والوكيل المستقبِل لا يتذكر أنه رأى الرسالة من قبل. وفي تشغيل يمتد ساعات ووكلاء كثيرين، تكون نافذة إعادة التشغيل واسعة، وغياب nonce دائم يعني أن النقل لا يستطيع التمييز بين إعادة محاولة وهجوم.
اربط كل رسالة بهوية ومعرّف مهمة
معرّف الجلسة لا يكفي. فالجلسات تُعاد استخدامها وتُجمَّع وأحيانًا تُشارَك بين المهام. يجب أن تحمل كل رسالة هوية صريحة (من يتصرف) ومعرّف مهمة (ما الذي يندرج هذا الإجراء ضمنه)، ويجب أن يغطي توقيع الرسالة كليهما. الهوية هي الطالب الأصلي، لا المرسل المباشر. ومعرّف المهمة يتيح للمستقبِل تطبيق سياسة مرتبطة بالعمل، لا بالاتصال.
آلية ملموسة: وقّع التسلسل القانوني لمغلّف الرسالة، بما يشمل الهوية ومعرّف المهمة واسم القدرة ورقم تسلسل متزايد رتيبًا، بمفتاح يحتفظ به الوكيل المرسل. يتحقق المستقبِل من التوقيع مقابل مفتاح مرتبط بالهوية، ويفحص رقم التسلسل مقابل آخر رقم شوهد لتلك المهمة، وعندها فقط يقيّم ما إذا كانت القدرة مسموحًا بها. هذه ليست تشفيرًا مبتكرًا؛ بل
حدّد نطاق القدرات للرسالة، لا للاتصال
تفويض الاتصال هو جذر تدفقات النائب المُلبَّس. فالاتصال المُفوَّض لاستدعاء قدرة يمكنه استدعاؤها لأي سبب. أما منح القدرة على مستوى الرسالة فيسمّي القدرة والمهمة والهوية وانتهاء الصلاحية. يفحص المستقبِل المنح، لا الاتصال. وهذا يعني أن النائب لا يستطيع التصعيد: لا يمكنه تقديم إلا المنح الصادرة له، للمهام التي أُعطيها.
المقايضة حقيقية. منح مستوى الرسالة تضيف رمزًا إلى كل استدعاء، وتتطلب مُصدِرًا، وتُدخل مشكلة إبطال. في الأسراب الداخلية عالية الإنتاجية، يكون الحمل الإضافي ملموسًا في زمن الاستجابة وفي تعقيد المُصدِر. البديل — الثقة بالاتصال — أرخص ويفشل مفتوحًا. والخيار التصميمي هو ما إذا كان ينبغي للنقل أن يفشل مغلقًا عند الأصالة. للتواصل بين الوكلاء عبر حدود الثقة، ينبغي ذلك.
اجعل سجل النقل هو السجل الموثوق
سجلات الوكلاء استشارية. فالوكيل يمكن اختراقه أو إعادة تشغيله أو ببساطة أن يخطئ في وصف ما فعله. وإذا كان السجل الوحيد لرسالة في الوكيل الذي أرسلها أو استقبلها، فالسجل ليس دليلًا. ينبغي للنقل أن يسجّل كل مغلّف موقّع مع نتيجة التحقق منه، وأن يكون ذلك السجل هو المرجع الموثوق للتدقيق ولكشف إعادة التشغيل. وهذا يمنح أيضًا موضعًا لفرض تفرد nonce عبر نقاط الحفظ: النقل، لا الوكيل، هو من يتذكر ما شوهد.
المقايضة الصادقة
كل قاعدة من هذه القواعد تنقل العمل من الوكيل إلى النقل. وهذا هو المقصود، وهو أيضًا التكلفة. فوسائط النقل التي تتحقق من التوقيعات وتتتبع أرقام التسلسل وتصدر المنح المرتبطة بالرسائل وتبطلها وتحتفظ بسجل دائم أكثر تعقيدًا من أنابيب تنقل البايتات. وهي تتطلب إدارة مفاتيح ومُصدِرًا وسجلًا ينجو من إعادة التشغيل. وتضيف زمن استجابة وأنماط فشل. في استدعاء أداة من متصل واحد، لا يُبرَّر هذا التعقيد. أما في سرب وكلاء أقران تتباين فيه الهويات وتُحفظ التشغيلات الطويلة الأفق وتُستأنف، فالتعقيد هو خاصية الأمان نفسها. السؤال ليس هل ندفعها، بل أين: في النقل، مرة واحدة، أم في كل وكيل، مرارًا وبشكل غير متسق.
ما الذي تفعله بعد ذلك
تعامل مع النقل كسطح هجوم ودقّق فيه على هذا الأساس. عدّد القفزات التي يُعاد فيها تسلسل الطلب واسأل ما الأصالة التي تنجو. افصل اكتشاف القدرات عن تفويضها واطلب منحًا عند وقت الاستدعاء. اربط الرسائل بالهويات والمهام، لا بالجلسات. اجعل سجل النقل موثوقًا واستخدمه لكشف إعادة التشغيل. لا شيء من هذا يتطلب التخلي عن وسائط النقل على نمط MCP؛ بل يتطلب توسيعها بأساسيات الثقة التي يحتاجها تواصل الأقران. للاطلاع على عمل ذي صلة بأمن بروتوكولات الوكلاء، راجع هذا التحليل.