الفصل 12 — تَصلُّب البروتوكول والدفاعات

المقالة الثانية عشرة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. حيث يَحصل كل تهديدٍ من الفصل السابق على دفاع، ولا أيٌّ من الدفاعات رصاصة فضية، وتركيبها هو الشيء الوحيد الذي يُنتج وضعاً يُمكنك نشره فعلاً.

لماذا يوجد هذا الفصل

لا يَصير البروتوكول آمناً بنشره. يَصير آمناً بنشره داخل كومةٍ تُعَوِّض الافتراضات التي يَضعها البروتوكول العاري. فَهرَس الفصل 11 التهديدات؛ ويَمشي هذا الفصل على الدفاعات بعمقٍ هندسي. التَشهيد التَشفيري للقدرة يُغلق فئات الاكتشاف وتَصعيد القدرة. انضباط نطاق OAuth 2.1 مع رموزٍ مُفَوَّضة للمستخدم يُغلق فئات النائب والتَمرير. أعمار الجلسة المُقَيَّدة تُغلق فئة اختطاف الجلسة. العزل الصندوقي يَحوي الاختراقات التي تُفلت من المنع. موافقة الإنسان في الحلقة تَلتقط العمليات الهَدّامة التي كان على بقية الكومة أتمتتها لتكون مفيدة. كل دفاع يَترك مُجازفةً متبقية؛ التَركيب هو ما يَجعل المتبقيات صغيرةً بقدرٍ كافٍ للدفاع عنها عملياً.

في سطر واحد: وضعٌ قابلٌ للدفاع في MCP ليس دفاعاً واحداً بل أربعة — التَشهيد، انضباط النطاق، العزل الصندوقي، وHITL — مُرَكَّبة بتَعَمُّد، لأن لا طبقة مفردة كافية ولا نموذج موثوقٌ بقدرٍ كافٍ ليَحل محلَّ أيٍّ منها.

12.1 AttestMCP: التَشهيد التَشفيري للقدرة

الدفاع الأول يُعالج مشكلةً تَجري عبر كل تهديدٍ تقريباً: ليس للمُضيف طريقة للتَحقُّق من أن الخادم الذي يُكَلِّمه هو ما يَدَّعي. AttestMCP — يُسمى أيضاً MCPSec أو بيانات قدرةٍ مُوَقَّعة — يُضيف طبقة تَشهيدٍ تَشفيري فوق بنية رسائل البروتوكول. يَحمل الناشر مفتاح توقيعٍ طويل العمر مُسَجَّلاً في دليلٍ أو سجل شفافية. تُهَش بيانات القدرة الكاملة وتُوَقَّع وقت الإصدار. يَتَحَقَّق المُضيف من التوقيع عند initialize مقابل مفتاح الناشر المُسَجَّل، ويُدخل الخادم، يَحجُره، أو يَرفض الاتصال.

المنافع حقيقية. التَطفُّلات المطبعية لا تَستطيع إنتاج توقيعٍ صالحٍ من الناشر الشرعي. تَصعيد القدرة عبر إشعارات list_changed يَصير قابلاً للاكتشاف لأن بيانات قدرةٍ جديدة تَتطلَّب توقيعاً جديداً. سياسة دقيقة — «ثِق بخوادم GitHub المنشورة للمستودعات لا للبريد» — تَصير قابلة للإنفاذ لأن هوية الناشر صارت قابلة للتَحقُّق لا مُؤَكَّدة فقط. التكاليف حقيقية أيضاً: على الناشرين تشغيل بنية تحتية للتوقيع، سجلات الشفافية تَحتاج مُشَغِّلاً جديراً بالثقة، وعلى طبقة سياسة المُضيف فَهم الإبطال. التأطير الصادق أن AttestMCP هندسة جوهرية، لا مربع تأشير. ولديه فجوة جديرة بالتسمية: تُوَقِّع البيانات ما يقوله الخادم عن نفسه، لا ما يَفعله وقت التشغيل. إعلانٌ مُوَقَّع لأداةٍ حميدة لا يزال يَستطيع شَحن تنفيذٍ مُسَرِّب. التَشهيد لازمٌ لكن غير كافٍ، ولهذا يوجد بقية الفصل.

12.2 نطاقات OAuth 2.1 وأعمار جلسةٍ مُقَيَّدة

المجموعة الثانية تُشَدِّد نموذج الاعتماد والجلسة. تدفُّقات OAuth 2.1 ناضجة؛ والهندسة في استخدامها صحيحاً. الانضباط الأول نطاقاتٌ ضيقة — اطلب فقط ما يَحتاجه سطح الأداة المُعلَن. كلما ضاق النطاق، صَغُر نصف قطر الانفجار. الانضباط أصعب مما يَبدو لأن الخدمات النهائية كثيراً ما تُعَرِّف النطاقات خشناً والمسار الضيق مُمِلّ؛ النطاقات العريضة تَعمل من أول محاولة وتَشعر تَقَدُّماً. كلفة النطاقات الضيقة يَدفعها المهندس؛ وكلفة العريضة يَدفعها المستخدم حين يَسوء شيء.

الدفاع ضد النائب المُلتبس الذي لا يُقَدِّمه انضباط النطاق وحده هو رموزٌ مُفَوَّضة للمستخدم. حيث يَدعمها النهائي، يُكمل كل مستخدمٍ تدفُّق OAuth خاصه، ويَعمل الخادم على رمز المستخدم لا على هوية خدمته. يَختفي النائب لأن الخادم لم يَعد يَعمل على صلاحيته. لتَمرير الرمز إصلاحٌ مختلف: لا تُمَرِّر الرموز. يَحمل الخادم اعتماداته الخاصة، مُؤَسَّسةً وقت التسجيل، ولا تَحمل الحدود بين المُضيف والخادم رمزاً أبداً. أعمار الجلسة المُقَيَّدة تُعالج الاختطاف: دقائق للعمليات عالية المُجازفة، ساعات للروتينية، مع هوية سير عملٍ متينة مُلصَقة فوق ليَستطيع مهمةٌ متعددة الساعات تَجديد جلسات النقل دون استنطاق المستخدم كل خمس عشرة دقيقة. ربط القدرة لكل جلسة وإعادة تأكيد القدرة عند تَجديد الجلسة تُكمل الانضباط — كلاهما عمل إدارة حالةٍ على المُضيف فعله صراحةً، وكثير من التنفيذات لم يَفعل.

12.3 العزل الصندوقي وعزل وقت التشغيل

المجموعة الثالثة تُدرك أن ليس كل تهديدٍ يُمكن منعه وأن وضعاً قابلاً للدفاع يجب أن يَحوي الضرر حين يَفشل المنع. عزل العملية الصندوقي للخوادم المحلية — seccomp على Linux، App Sandbox على macOS، AppContainer على Windows، gVisor للعزل الأقوى — يَرفض نظام الملفات والشبكة ووصول العمليات افتراضياً ويَمنح فقط الوصولات المحدَّدة التي يَحتاجها الخادم. خادمٌ مُختَرَق يُحاول قراءة ملف كلمة مرور أو تَسريب إلى نقطة المهاجم يَجد العملية مرفوضةً في طبقة نظام التشغيل، لا لأن شيفرة الخادم امتنعت بل لأن العزل الصندوقي فعل. سياسة الشبكة للخوادم البعيدة — TLS متبادل، نقاط نهايةٍ مسموحة، تَرشيح الخروج — تُضَيِّق السطح الذي يَستطيع خادمٌ بعيدٌ مُختَرَق بلوغه. عزل المحتوى داخل المُضيف يُعامل المحتوى المُعاد بشكٍّ مناسب قبل أن يَهبط في سياق النموذج: عَلامات غير موثوقة، تَطهير HTML، رفض اتباع روابط مُضَمَّنة. العزل الصندوقي لاستدعاءات الأدوات عبر سياساتٍ واعية بالقدرة يُتيح للمُضيف فحص وسائط الاستدعاء وقرار السماح، الرفض، أو التَصعيد لموافقة المستخدم. مُجازفةٌ بعينها جديرة بالتسمية هي تَسريب القناة الجانبية عبر أدواتٍ شرعية — نموذج خبيث يُرَمِّز اعتمادات في استعلام بحثٍ — تَلتقطه طبقة السياسة بفحص الوسائط لا نقاط النهاية. عزل سلسلة التَوريد يُغلق الحلقة: تُتَحَقَّق هَش الثنائي عند التثبيت والتحديث مقابل قيمةٍ مُوَقَّعة في سجل الشفافية، فلا يَستطيع ثنائيٌّ مُتَلاعَب به الجَري حتى لو نَجَحَت بيانات القدرة.

12.4 بوّابات موافقة الإنسان في الحلقة

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

يجدر بنا تذكُّره: مجموعات الدفاع الأربع ليست قابلة للتبديل، ولا أيٌّ كافٍ وحده. التَشهيد يُخبرك مَن الخادم؛ انضباط النطاق يَحدّ ما تَستطيع اعتماداته فعله؛ العزل الصندوقي يَحوي سلوكه وقت التشغيل؛ HITL يَلتقط العمليات التي كان على الثلاثة الأخرى أتمتتها. فريقٌ يَشحن واحدةً فقط يَشحن مسرحاً أمنياً. فريقٌ يَشحن الأربع لديه وضعٌ لا يَعتمد على تَصرُّف النموذج صحيحاً تحت الظروف الخصومية — وهذا النوع الوحيد من الأوضاع الجدير بالشحن، لأن لا نموذج يَفعل.

ما يُمهِّد له الفصل 12

النصف الأمني من الصورة الهندسية مكتملٌ الآن. النصف الآخر — الأُطُر، أنماط النشر، خصائص الأداء، والاختبار الذي يُؤَكِّد أن النظام يَعمل في الإنتاج — هو ما تَتولاه الفصول الباقية. يَفتح الفصل 13 ذلك القوس بالمشي على الأُطُر وتكاملات السحابة التي هَبَطَت خلال 2025 و2026: Strands مع Amazon Bedrock، أنماط طبقة الحالة في AWS، Microsoft Agent Framework، LangChain، وSemantic Kernel. الأُطُر تَهُمّ لأن لا أحد يَبني MCP إنتاجياً من البروتوكول الخام، والاختيارات بينها تُشَكِّل الوضع الهندسي والأمني بطرقٍ لا تُحَدِّدها طبقة البروتوكول وحدها.

التالي — الفصل 13: الأُطُر وتكامل السحابة. Strands مع Bedrock، طبقة حالة AWS، إطار وكلاء Microsoft، LangChain، Semantic Kernel، وأنماط التكامل الإنتاجي الثلاثة التي تَصل إليها الفِرَق مستقلَّة.

هل تريد الصورة الكاملة؟ يَمشي الكتاب على كل دفاعٍ بكلفه وفجواته المتبقية مُسَمَّاة بصدق، يُعالج بنية توقيع AttestMCP ومقايضات سجل الشفافية بعمق، ويُقَدِّم مثالاً عملياً لكيف يَنجو سياق موافقةٍ مُتدرِّجة من سير عملٍ طويلٍ متعدد الخطوات. عرض LLM Primer IV على أمازون ←