تأمين خادم Freight MCP: OAuth 2.1، تسميم الأدوات، وحالات التعرض

في الجزأين الأخيرين من هذه السلسلة، غطيت كيفية تطبيق بروتوكول سياق النموذج على واجهة برمجة تطبيقات الشحن ثم تم هدم خوادم شحن MCP التي تم شحنها في عام 2026. انتهى كلاهما بنفس السؤال المفتوح، لذا يجيب هذا الجزء عليه مباشرة: بمجرد أن يتمكن الوكيل من حجز شحن حقيقي، كيف توقفه من حجز الشيء الخطأ للشخص الخطأ؟ الأمن هو المكان الذي يتوقف فيه خادم MCP للشحن عن كونه لعبة للمطورين ويبدأ في الظهور كنظام يحرك المال والشاحنات.

أعمل من مقر سوق يوفر واجهة برمجة تطبيقات، لذا فإن تحيزي عملي وليس أكاديميًا. التهديدات أدناه هي تلك التي نقوم بنمذجتها فعليًا عند تحديد الأداة التي قد يستدعيها الوكيل دون تدخل بشري.

لماذا يرفع خادم الشحن مستوى المخاطرة

خادم MCP عام يقرأ تقويمك يسرب معلومات عند فشله. خادم شحن يحجز حمولة يفعل شيئًا أكثر تكلفة. مكالمة سيئة يمكن أن تٌرسل شاحنة إلى ساحة خاطئة، أو تغير المستلم على شحنة حية، أو تلغي حجزًا يعتمد عليه العميل، أو تسحب بوليصة شحن كان يجب ألا تغادر الحساب أبدًا. هذه ليست أخطاء كشف بيانات. إنها أموال وبضائع مادية تتحرك بتعليمات لم يكتبها أحد.

هذا الاختلاف يعيد صياغة المشكلة بأكملها. مع مساعد الدردشة، يكون أسوأ سيناريو إجابة محرجة. مع الشحن، يكون أسوأ سيناريو مرتبطًا بفاتورة شحن وشحنة في مكان لا ينبغي أن تكون فيه. لذلك السؤال ليس أبدًا "هل هذا الخادم آمن" بشكل مجرد. بل هو "ما هي الإجراءات المحددة التي يمكن للوكيل اتخاذها، وما تكلفة كل إجراء إذا ساءت الأمور."

وضعي الفشل اللذين يستحقان القلق بشأنهما

يقلّ خطر معالجة البيانات الطرفية (MCP) في عام 2026 إلى نمطين، ويزيد الشحن كليهما سوءًا.

حقن الأوامر هو مشكلة الويب القديمة بملابس جديدة. يقرأ الوكيل نصًا من مكان لا يتحكم فيه بالكامل، مثل مذكرة شحن، أو ملف PDF، أو نص بريد إلكتروني، ويحتوي هذا النص على تعليمات يطاعها النموذج. في الشحن، يصل النص المسموم عبر قنوات شرعية طوال اليوم: تعليق حجز، وصف جمركي، تحديث حالة شركة نقل. إذا كانت أداة الحجز الخاصة بك تثق بما يمرره لها النموذج، يمكن لجملة مدفونة في مذكرة تسليم أن تؤدي إلى إلغاء حقيقي.

تسميم الأدوات هو شيء أكثر خفاءً ويقتصر على MCP. يسمح البروتوكول للخادم بوصف أدواته الخاصة، ويقرأ الوكيل تلك الأوصاف لتحديد ما يجب استدعاؤه. يمكن للخادم الخبيث أو المخترق كتابة وصف يخبر النموذج بهدوء بتسريب مفتاح API أو إعادة توجيه شحنة، ولن يرى المستخدم هذا النص أبدًا. قضت Anthropic والباحثون المستقلون أوائل عام 2026 في توثيق متغيرات هذا، والدرس للشحن واضح: طبقة الوصف قابلة للتنفيذ، لذا تعامل مع وصف أداة طرف ثالث بنفس الشك الذي تتعامل به مع كود طرف ثالث.

القراءة مقابل الكتابة: الخط الفاصل الذي يجب أن يحدد صلاحياتك

كان القرار الأمني الأكثر فائدة الذي اتخذته هو التوقف عن التفكير في "خادم MCP" كحدود ثقة واحدة وتقسيمه حسب ما تفعله كل أداة في العالم.

ما الذي يمكن أن يظل مفتوحًا

اقتباس خط ملاحي، سرد السعة، حساب تقدير العبور، البحث عن رمز ميناء. لا شيء من هذا يغير شيئًا. الهدف هو السماح للوكيل بالوصول إليهم بأقل قدر من الاحتكاك أو بدونه، وهذا هو المكان الذي تكمن فيه القيمة اليومية. القارئ الذي يرغب في مقارنة ثلاثة مسارات لا ينبغي أن يضطر إلى سك رمز مميز للقيام بذلك. عبر الخوادم في التفكيك، أبقى الأكثر جدية أدوات الاقتباس والمرجع منخفضة الاحتكاك لهذا السبب بالضبط.

ما الذي يجب أن يكون محصوراً

الحجز، الإلغاء، تغيير المرسل إليه، تعديل عنوان، سحب مستند، أي شيء يمس الفاتورة. كل واحد من هذه الأمور يؤدي إلى تعديل في العالم الحقيقي، وكل واحد منها يحتاج إلى اتصال مصادق عليه، ومفوض، وقابل للتدقيق من ورائه. القاعدة التي نتبعها بسيطة في قولها وأصعب في تطبيقها: أداة القراءة يمكن أن تكون مفتوحة، وأداة الكتابة لا تكون أبدًا.

OAuth 2.1 و PKCE، وليس مفتاحاً طويل الأمد في ملف إعدادات

استقرّت مواصفات تفويض MCP على OAuth 2.1 للخوادم البعيدة، وهذا الاختيار له وزن حقيقي للشحن. مفتاح API ثابت تم لصقه في ملف تكوين لا بأس به لمطور فردي يدير خادمًا عبر stdio على جهازه الخاص. إنه النموذج الخاطئ في اللحظة التي يمكن فيها الوصول إلى الخادم عبر HTTP ويعمل وكيل نيابة عن مستخدم مُسمى داخل حساب مشترك.

هناك ثلاث خصائص تقوم بالعمل الشاق. الرموز المقيدة تعني أن الرمز الذي تم إنشاؤه للاقتباس لا يمكنه الحجز. الرموز قصيرة الأمد تعني أن بيانات الاعتماد المسربة تنتهي صلاحيتها من تلقاء نفسها بدلاً من البقاء إلى الأبد في سجل. الرموز القابلة للإلغاء تعني أنه عندما يبدو شيء خاطئًا، يمكنك قطع الوصول في ثوانٍ بدلاً من تدوير مفتاح مشترك يعتمد عليه الجميع. يتطلب OAuth 2.1 أيضًا PKCE في تدفق رمز التفويض، والذي يغلق فجوة الاعتراض التي تركتها عمليات نشر OAuth القديمة مفتوحة. لا شيء من هذا غريب. إنه نفس التحصين الذي مرت به أي واجهة برمجة تطبيقات للدفع، مطبقًا على اللحظة التي يقول فيها الوكيل "احجز".

هذا هو شكل الحدود التي نطبقها، مكتوبة بالصيغة التي أتمنى أن تنشرها كل شركة شحن.

إجراء الوكيل	يقرأ أو يكتب	**المصادقة المطلوبة**	**إذا ساء الأمر**
احصل على عرض أسعار	اقرأ	مفتاح مفتوح أو أساسي	مكالمة ضائعة، لا ضرر
تحقق من السعة، العبور، التتبع	اقرأ	مفتاح مفتوح أو أساسي	إجابة راكدة في أسوأ الأحوال
حجز شحنة	اكتب	رمز OAuth مستهدف، خطوة تأكيد	تكلفة حقيقية، شاحنة حقيقية
إلغاء أو إعادة الحجز	اكتب	الرمز المقيد، مفتاح التفرّد	فقدان خانة، غرامة
تغيير المستلم أو العنوان	اكتب	رمز مقيد، تأكيد بشري	سوء التسليم، احتيال
اسحب فاتورة أو سند شحن	اقرأ حساس	رمز مقيد، فحص لكل مستند	تسريب البيانات والمستندات

النمط في هذا الجدول هو قرار المنتج الفعلي. القراءات تقع على اليسار وتبقى رخيصة. الكتابات تقع على اليمين وتكسب احتكاكها.

مشكلة الكائن المكشوف

قدر كبير مفاجئ من مخاطر MCP ليس ذكيًا على الإطلاق. إنه خادم كان من المفترض تشغيله محليًا، وتم كشفه للإنترنت المفتوح بدون مصادقة، لأن شحنه بهذه الطريقة كان أسهل. يدعم البروتوكول وسيلتي نقل. يعمل خادم stdio كعملية محلية يقوم العميل بتشغيلها، مما يبقيه على جهازك وخارج الشبكة. يمكن لأي شيء يمكنه العثور على عنوان URL الخاص به الوصول إلى خادم HTTP المستضاف.

بالنسبة لخادم الأدوات للقراءة فقط، فإن التعرض لبروتوكول HTTP يكون غير ضار في الغالب. بالنسبة لخادم يحتوي على أدوات الحجز، فهذا هو الأمر برمته. إذا كانت أدوات الكتابة الخاصة بك متاحة عبر HTTP عام، فإن المصادقة ليست ميزة تضيفها لاحقًا، بل هي الشيء الذي يقف بين الغريب وطابور الإرسال الخاص بك. قاعدتنا هي أن أدوات الحجز والتوثيق لا يتم تقديمها أبدًا عبر نقطة نهاية HTTP غير مصادق عليها، بدون استثناء. عند الشك، يجب أن يعتمد الخادم القادر على الكتابة افتراضيًا على stdio والإطلاق المحلي، ولا ينتقل إلى HTTP المستضاف إلا بمجرد تطبيق تدفق OAuth أعلاه.

الدفاع عن طبقة الوصف ضد تسميم الأدوات

نظرًا لأن أوصاف الأدوات توجه النموذج، فهي تستحق نفس الضوابط التي تتمتع بها التعليمات البرمجية التي تنشرها. ثلاثة عادات تغطي معظم التعرض.

• **ثبّت وراجع الخوادم التي تتصل بها.** إنّ العميل المتصل بمجموعة من الخوادم المعروفة هو هدف أصغر من العميل الذي يقوم بتثبيت أي شيء تقدمه السجل. عامل الخادم الجديد مثل التبعية الجديدة، لأن هذا هو ما هو عليه.
• حافظ على وجود إنسان في كل عملية كتابة. خطوة تأكيد قبل الحجز أو الإلغاء أو تغيير المستلم تحول التعليمات المدخلة بصمت إلى طلب مرئي يمكن للمستخدم رفضه. إنها أرخص وسيلة تحكم بأعلى عائد.
• **التحقق عند واجهة برمجة التطبيقات، وليس في الاستعلام.** يجب على الخادم إعادة فحص كل معلمة يستلمها مقابل الأذونات الحقيقية للحساب والحالة الحقيقية للحجز، بدلاً من الثقة بأن النموذج قد قام بتجميع استدعاء منطقي. النموذج يقترح، وواجهة برمجة التطبيقات تقرر.

ما الذي يجب على خادم السوق إنفاذه بحيث يمكن لشركة شحن واحدة التخطي

يؤثر خادم الناقل الفردي على شبكته الخاصة فقط، لذا فإن دائرة تأثيره تقتصر على مشغل واحد. يقوم خادم السوق بالاستشهاد والحجز عبر العديد من شركات الاتصالات نيابة عن العديد من المستخدمين، مما يغير المهمة الأمنية بطريقتين.

أولاً، يجب نطاق المستخدم والناقل، وليس الخادم. الرمز الذي يسمح للوكيل بالحجز لدى ناقل واحد يجب ألا يصل بصمت إلى ناقل آخر، ويجب على وكيل أحد العملاء ألا يرى أبدًا مستندات عميل آخر. ثانيًا، الأهمية للمسار التدقيقي أكبر، لأنه عندما يحجز وكيل عبر سوق، تحتاج إلى الإجابة على "أي مستخدم، أي رمز، أي ناقل، في أي وقت" لكل عملية كتابة. نحن نتعامل مع هذا السجل كجزء من المنتج، وليس كفكرة لاحقة، نظرًا لأنه ما يسمح لنا بإلغاء التفويض بشكل انتقائي بدلاً من تعطيل الخدمة للجميع.

قائمة عملية قبل أن تقوم بالحجز

• قسم الأدوات حسب القراءة والكتابة، واكتب التقسيم حيث يمكن لكل من العميل وفريقك رؤيته.
• اجعل أدوات الاقتباس والإشارة سهلة الاستخدام للحفاظ على القيمة اليومية.
• ضع كل عملية كتابة خلف رمز OAuth 2.1 مختصر، قصير الأجل، وقابل للإلغاء، مع PKCE.
• يلزم خطوة تأكيد عند إجراء تغييرات على الحجز أو الإلغاء أو المستلم أو العنوان.
• أعد التحقق من صحة كل معلمة في واجهة برمجة التطبيقات مقابل الأذونات الحقيقية وحالة الشحن الحقيقية.
• لا تقدم أدوات الكتابة أبدًا عبر HTTP غير المصادق عليه، واجعل الخوادم ذات القدرة على الكتابة افتراضيًا تستخدم الإدخال/الإخراج القياسي المحلي.
• ثبّت الخوادم التي يتصل بها وكيلك، وراجع الخوادم الجديدة مثلما تراجع التعليمات البرمجية الجديدة.
• سجّل كل عملية كتابة مع المستخدم، والرمز المميز، والحامل، والوقت، وتدرب على الإلغاء قبل أن تحتاجه.

لا يوجد أي من هذه الأمور فريد للذكاء الاصطناعي. إنها الضوابط التي تستخدمها الشحن والمدفوعات بالفعل، موجهة نحو المكان الجديد الذي يمكن أن ينشأ فيه الأمر. الوكيل هو متصل جديد، وليس مجموعة جديدة من القواعد.

أسئلة متكررة

هل من الآمن ترك وكيل ذكاء اصطناعي يقوم بحجز الشحن على الإطلاق؟

نعم، عند إجراء الحجز خلف مكالمة مصادق عليها ومصرح بها مع خطوة تأكيد، وعندما يعيد الخادم التحقق من كل معلمة بدلاً من الثقة بالنموذج. النسخة غير الآمنة هي أداة كتابة مفتوحة بدون تدخل بشري. تعامل مع الحجز مثل أي إجراء آخر لنقل الأموال، ويصبح الوكيل متصلاً مصادقًا عليه آخر.

لماذا نستخدم OAuth 2.1 بدلاً من مفتاح API بسيط؟

يميل المفتاح الثابت إلى أن يكون طويل الأمد، واسع النطاق، وصعب الإلغاء دون تعطيل كل من يشاركه. يوفر OAuth 2.1 رموزًا ذات نطاق محدود وقصير العمر وقابلة للإلغاء ويطلب PKCE في تدفق التفويض. بالنسبة لخادم stdio محلي، يمكن قبول المفتاح، ولكن يجب على أي شيء يمكن الوصول إليه عبر HTTP ويمكنه الكتابة استخدام نموذج OAuth.

ما هو تسميم الأدوات في MCP؟

تسميم الأدوات هو عندما يحتوي وصف أداة الخادم، التي يقرأها الوكيل لاتخاذ قرار بشأن استدعاء، على تعليمات مخفية توجه النموذج نحو إجراءات ضارة مثل تسريب مفتاح أو إعادة توجيه شحنة. نظرًا لأن الوصف يؤثر على السلوك، فإنك تدافع عنه بالطريقة التي تدافع بها عن الكود: قم بتثبيت خوادم موثوقة، احتفظ بإنسان للكتابة، وتحقق عند واجهة برمجة التطبيقات (API).

هل يجب أن يعمل خادم MCP للشحن كـ stdio أو HTTP مستضاف؟

خادم مساعد للقراءة فقط مقبول عبر HTTP المستضاف. الخادم الذي يتضمن أدوات للحجز أو المستندات يجب أن يستخدم تلقائيًا stdio المحلي وينتقل فقط إلى HTTP المستضاف بمجرد توفر OAuth ذات النطاق، لأن نقطة نهاية الكتابة المكشوفة بدون مصادقة يمكن لأي شخص يعثر على عنوان URL الوصول إليها.

هذا يغلق الحلقة التي فتحتها هذه السلسلة. إذا لم تكن قد قرأت الأجزاء السابقة، يوضح دليل البروتوكول كيف يصبح واجهة برمجة تطبيقات الشحن مجموعة من الأدوات، ويُظهر تفكيك أين رُسمت هذه الخطوط في الممارسة العملية لعمليات الشحن.