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

يفترض أمان API التقليدي أن مطوّرًا كتب الكود الذي يستدعي نقطة النهاية الخاصة بك. MCP يكسر هذا الافتراض. فبروتوكول سياق النموذج يسمح لنموذج لغوي باختيار الأدوات أثناء التشغيل، استنادًا إلى نص يقرؤه. والنص يمكن تزويره، والنموذج لا يستطيع دائمًا أن يميّز التعليمة المشروعة من تعليمة مزروعة. لهذا يُعد أمان خادم MCP مشكلة مختلفة عن تأمين واجهة REST API.
النموذج هو المستدعي الجديد
في التكامل المعتاد، يراجع إنسان مسار الكود قبل نشره. أما في MCP، فالمستدعي نظام احتمالي يقرأ أسماء الأدوات وأوصافها ونتائجها كجزء من أمره النصي. جملة مخفية في وصف أداة تحمل تقريبًا الوزن نفسه الذي تحمله جملة في تعليمات النظام الخاصة بك. هذه الحقيقة وحدها تفسر معظم حوادث MCP.
كما أنها تغيّر من يُعدّ مهاجمًا. لا تحتاج إلى وصول إلى الخادم. يمكن لأي شخص يستطيع وضع نص أمام النموذج أن يحاول توجيهه: كاتب صفحة ويب، أو عميل يفتح تذكرة دعم، أو غريب يفتح مشكلة في مستودع عام. يبدأ أمان وكلاء الذكاء الاصطناعي بالاعتراف بأن قناة المدخلات مفتوحة للعالم.
أين تقع حدود الثقة
ارسم أربعة حدود قبل كتابة أي سطر من الإعدادات:
| الحد | ما الذي يعبره | من تثق به |
|---|
| من المستخدم إلى العميل | الأوامر النصية والموافقات | المستخدم المسجَّل دخوله |
| من العميل إلى الخادم | استدعاءات الأدوات والنتائج | الخوادم التي فحصتها فقط |
| من الخادم إلى الخلفية | الاستعلامات والملفات واستدعاءات API | هوية خدمة محددة النطاق |
| من الخادم إلى الإنترنت | الصفحات المجلوبة وروابط Webhook | لا أحد |
لطريقة النقل أهمية كذلك. الخادم المحلي الذي يعمل عبر stdio هو عملية على جهاز المستخدم تعمل بصلاحياته، لذلك فإن حزمة خبيثة تعني عمليًا تنفيذ كود تعسفي. أما الخادم البعيد عبر HTTP فيضيف تعرضًا للشبكة، والمصادقة، وإدارة الجلسات. يحتاج كل نقل إلى نموذج تهديد خاص به، والخادم الذي يدعم الاثنين يحتاج إلى مراجعتين.
💡 نصيحة: أخطر إعداد هو وكيل واحد يستطيع قراءة البيانات الخاصة، وقراءة محتوى غير موثوق، وإرسال البيانات إلى الخارج. يسمي باحثو الأمن هذا التركيب "الثلاثي القاتل". أزل ضلعًا واحدًا منه على الأقل، وستُغلق معظم مسارات تسريب البيانات.
المخاطر السبعة الأهم
لا تستحق كل التهديدات الاهتمام نفسه. تظهر هذه السبعة مرارًا في الأبحاث العامة حول MCP وفي تقارير الحوادث، ويرتبط كل منها ببنود في القائمة لاحقًا.
| # | الخطر | ماذا يحدث | الأثر المعتاد |
|---|
| 1 | حقن الأوامر | يتبع النموذج تعليمات مخفية في صفحة أو تذكرة أو ملف | تسريب بيانات، وإجراءات غير مرغوبة |
| 2 | تسميم الأدوات | تقبع تعليمات خبيثة داخل أوصاف الأدوات | سرقة بيانات بصمت |
| 3 | الانسحاب المفاجئ (Rug pull) | يغيّر الخادم أدواته بعد أن وافقت عليه | المعتمد لم يعد هو الحالي |
| 4 | بيانات اعتماد مسرّبة | تنتهي الرموز في الإعدادات أو السجلات أو سياق النموذج | الاستيلاء على الحساب |
| 5 | صلاحيات مفرطة | يعمل الخادم بنطاق المسؤول | خطأ واحد يتحول إلى خرق أمني |
| 6 | تمرير الرموز دون فحص (Token passthrough) | يعيد الخادم توجيه رموز لم تُصدر له | وصول يتجاوز المقصود |
| 7 | سلسلة التوريد | حزم خوادم متشابهة الاسم أو مزروعة بأبواب خلفية | تنفيذ كود على جهازك |
حقن الأوامر عبر مخرجات الأدوات

حقن الأوامر هو الخطر الرئيسي لأنه لا يحتاج إلى كود استغلال. في عام 2025، أظهر باحثون أن تكامل GitHub يمكن توجيهه عبر مشكلة خبيثة في مستودع عام لقراءة مستودعات خاصة ونشر محتوياتها مجددًا. فعل النموذج ما طُلب منه تمامًا. لكن الطلب جاء من مهاجم.
دفاعات تعمل فعلًا:
- تعامل مع نتائج الأدوات كبيانات، لا كتعليمات. غلّف النتائج بمحددات واضحة، واذكر ذلك صراحةً في تعليمات النظام.
- فصّل المهام. لا ينبغي للوكيل الذي يقرأ صفحات غير موثوقة أن يملك صلاحية الكتابة إلى أي شيء ذي قيمة.
- تحكّم في الإجراءات الصادرة. الإرسال والنشر والحذف تتطلب نقرة من إنسان.
- افحص الاتجاهين. شغّل مصنّف أمان على المدخلات والمخرجات، كما هو موضح في الدليل أدناه.
تسميم الأدوات والانسحاب المفاجئ
يخفي تسميم الأدوات التعليمات داخل وصف الأداة أو مخططها. ترى أداة بريئة اسمها "جمع رقمين". أما النموذج فيرى فقرة إضافية تطلب منه قراءة ملف بيانات اعتماد وتمرير محتواه كمعامل. أما الانسحاب المفاجئ فهو النسخة البطيئة: يتصرف الخادم بشكل سليم أثناء المراجعة، ثم يغيّر تعريفات أدواته بهدوء بعد أن وافقت عليه.
الحل بسيط وفعّال. احسب تجزئة (hash) لبيان الأدوات الكامل (الأسماء والأوصاف والمخططات) عند الموافقة، وقارنها في كل اتصال، وارفض التشغيل عند تغيّر التجزئة. اعرض على المستخدمين الوصف الكامل، لا ملخصًا مختصرًا.
تستحق سلسلة التوريد سطرًا خاصًا. في عام 2025، أُبلغ عن أن خادم بريد إلكتروني متشابه الاسم منشور على npm نسخ الرسائل الصادرة إلى عنوان خارجي بعد تحديث روتيني. الحماية منها تكون بتثبيت الإصدارات والاحتفاظ بقائمة سماح (البندان 9 و10 في القائمة).
بيانات الاعتماد والرموز المسرّبة

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

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

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

- شغّل الخوادم المحلية داخل حاوية أو بيئة معزولة لا تملك وصولًا إلى المجلد الرئيسي افتراضيًا.
- ثبّت الإصدارات والمجاميع الاختبارية (checksums)، وراجع الفرق قبل كل تحديث.
- احتفظ بقائمة سماح بالخوادم التي يُسمح لفريقك بتثبيتها. احظر البقية.
- أعد الموافقة على الخادم كلما تغيّرت قائمة أدواته أو أوصافها.
- تحقّق من كل وسيط لأداة على الخادم: المسارات، وSQL، وعناوين URL، وسلاسل الشل. لا تمرّر أبدًا مخرجات النموذج إلى الشل دون تهريب الأحرف الخاصة.
- اربط خوادم HTTP المحلية بالعنوان 127.0.0.1، وتحقّق من ترويسة Origin لمنع إعادة ربط DNS.
- أبقِ أدوات التصحيح مثل فاحصات البروتوكول بعيدة عن الشبكات المشتركة، وخلف المصادقة.
البيانات والشبكة
- خزّن الأسرار في مخزن آمن أو في مخزن بيانات الاعتماد لنظام التشغيل، ولا تضعها أبدًا في الأوامر النصية أو ملفات المستودع أو نتائج الأدوات.
- احذف الأسرار والبيانات الشخصية من نتائج الأدوات قبل وصولها إلى النموذج.
- قيّد حركة البيانات الصادرة بقائمة سماح للوجهات، حتى لا يتمكن وكيل مخترق من إرسال البيانات إلى مضيفين عشوائيين.
- فرض حدود معدل واستخدام وسقوف إنفاق لكل خادم ولكل مستخدم.
- سجّل كل استدعاء أداة مع المستخدم والخادم وتجزئة الوسائط وحجم النتيجة والطابع الزمني. انقل السجلات إلى تخزين لا يستطيع الوكيل تعديله.
- احتفظ بمفتاح إيقاف طارئ يعطّل أي خادم في أقل من خمس دقائق، وتدرّب عليه.
💡 نصيحة: البنود 5 و11 و17 هي الأرخص والأسهل في التنفيذ، وهي تغلق أخطر المسارات: الإجراءات غير المعتمدة، والتغييرات الصامتة في الأدوات، وخروج البيانات من الشبكة. إن كان أسبوعك قصيرًا، ابدأ من هنا.
كيف تُجري تدقيق MCP

يجيب التدقيق عن سؤال واحد: ماذا يستطيع النموذج أن يفعل الآن، ومن وافق على ذلك؟ خصص فترة عصر، واستدعِ مهندسًا واحدًا ومراجعًا أمنيًا واحدًا، واعمل في ثلاثة مرورات. قبل المرور الأول، اكتب نموذج تهديد من صفحة واحدة يتضمن أربع إجابات: ما البيانات التي يستطيع الوكيل الوصول إليها، وما المحتوى غير الموثوق الذي يقرؤه، وإلى أين يمكنه إرسال البيانات، وأي الإجراءات لا يمكن التراجع عنها.
جرد كل خادم
لا يمكنك حماية ما لا تستطيع حصره. اجمع الخوادم من ملفات إعداد العميل، وإعدادات بيئة التطوير، والمستودعات المشتركة للفريق، وخطوات CI، وأي إعدادات "مؤقتة" لم تُزَل أبدًا. سجّل التالي لكل خادم:
| الحقل | مثال |
|---|
| الاسم والمصدر | حزمة من المزوّد، أو مستودع داخلي، أو مشروع مجتمعي |
| النقل | stdio محلي أو HTTP بعيد |
| الهوية المستخدمة | حساب خدمة، أو رمز شخصي، أو لا شيء |
| النطاقات الممنوحة | قراءة التذاكر، كتابة الملفات، مسؤول |
| البيانات التي يستطيع الوصول إليها | سجلات العملاء، وكود المصدر، والويب العام |
| المالك | شخص محدد بالاسم، لا اسم مستعار للفريق |
توقع مفاجآت. تكتشف الفرق عادةً خوادم لا يتذكر أحد تثبيتها، وتعمل برمز مسؤول شخصي.
إعادة تشغيل السجلات ومراجعتها
اسحب سجلات استدعاءات الأدوات لثلاثين يومًا، وابحث عن أنماط لا ينبغي أن تكون موجودة: استدعاءات في ساعات غريبة، ونتائج كبيرة بشكل غير معتاد، وأدوات تُستدعى مباشرةً بعد أن يقرأ الوكيل صفحة خارجية، ووسائط تحتوي على مسارات ملفات أو عناوين URL لم يذكرها المستخدم أبدًا. ولفرز الكم الكبير، يمكن لنموذج مثل Claude Sonnet 5 تجميع آلاف الاستدعاءات في قائمة قصيرة من الحالات الشاذة، بشرط حذف الأسرار والبيانات الشخصية قبل إرسال أي شيء.
قيّم النتائج وأصلحها
أعطِ كل نتيجة درجة خطورة ومهلة. أبقِ المقياس صغيرًا حتى يستخدمه الناس فعلًا:
| الخطورة | نتيجة مثال | مهلة الإصلاح |
|---|
| حرجة | رمز مسؤول في ملف إعداد مشترك | 24 ساعة |
| مرتفعة | لا توجد خطوة موافقة على البريد الصادر | أسبوع واحد |
| متوسطة | إصدار خادم غير مثبّت | 30 يومًا |
| منخفضة | لا يوجد مالك لخادم اختبار | المراجعة التالية |
أعد تشغيل التدقيق بعد كل تغيير كبير، وعلى الأقل مرة كل ربع سنة. قائمة خوادم كانت نظيفة في يناير نادرًا ما تبقى نظيفة في يونيو.
المراقبة والاستجابة للحوادث

ستفشل الوقاية في نهاية المطاف، لذا خطط ليوم حدوث ذلك. الهدف أن تلاحظ الخلل خلال دقائق، وأن تحتويه خلال ساعة.
ما الذي يجب تسجيله
سجّل ما يكفي لإعادة بناء الجلسة دون تخزين الأسرار. التقط المستخدم والعميل والخادم واسم الأداة وتجزئة الوسائط وحجم النتيجة وزمن الاستجابة وقرار الموافقة. وأطلق التنبيه أولًا على ثلاث إشارات: موجة استدعاءات لأداة واحدة، وأي استدعاء لأداة لم تُستخدم من قبل، ونتائج كبيرة بعد وقت قصير من جلب الوكيل لمحتوى خارجي.
مفاتيح الإيقاف والتراجع
يحتاج كل خادم إلى مفتاح إيقاف يستطيع شخص واحد تشغيله دون نشر جديد. ألغِ رموزه، وأزله من قائمة السماح، وغيّر أي سر لمسه. ثم استعد تجزئة بيان آخر نسخة معروفة بأنها سليمة. تدرّب على ذلك مرة كل ربع سنة، حتى لا تكون المحاولة الحقيقية الأولى هي أيضًا التدريب الأول.
💡 يساعد أيضًا سقف على مستوى المنصة. فمثلًا، تحدّ PicassoIA كل حساب بحدّ 5 تنبؤات متزامنة عبر كل الاتصالات، فلا يستطيع وكيل خارج عن السيطرة إغراق الطابور. اسأل مزوّديك عن أسقفهم الخاصة.
كيفية استخدام Llama Guard على PicassoIA
لن يحل مصنّف الأمان محل الصلاحيات والموافقات، لكنه يضيف مرشحًا مفيدًا. يقرأ Llama Guard 4 12B النصوص أو الصور ويعيد حكمًا بالآمن أو غير الآمن مع فئة الضرر المطابقة، مثل العنف والكراهية والتعليمات الخطيرة. وهو ليس كاشفًا مخصصًا لحقن الأوامر، لذا استخدمه كطبقة إلى جانب الضوابط السابقة، مثلًا لفحص ما يرسله المستخدمون وما يوشك وكيلك على إعادته.
- افتح صفحة النموذج. انتقل إلى صفحة Llama Guard 4 12B على PicassoIA.
- املأ الحقول المطلوبة. ألصق المحتوى المراد فحصه في Prompt. وفي System Prompt، اذكر سياستك والمخرج الذي تريده، مثل "أجب فقط بالكلمتين safe أو unsafe، ثم الفئة."
- اضبط الإعدادات الاختيارية. اجعل Temperature يساوي 0 للحصول على أحكام قابلة للتكرار، وخفّض Max Completion Tokens من الافتراضي 512 إلى رقم قصير، وأرفق لقطات الشاشة عبر Image Input عندما تحتاج إلى فحص صورة.
- شغّله. انقر على توليد واقرأ الحكم. أي مدخل موسوم بأنه غير آمن يُحال إلى مراجع بشري بدلًا من الوكيل.
- احفظ وقارن. احتفظ بمجموعة صغيرة من المدخلات التجريبية، وأعد تشغيلها كلما غيّرت تعليمات النظام.
| المعامل | القيمة المقترحة | السبب |
|---|
| Temperature | 0 | المدخل نفسه يعطي الحكم نفسه |
| Max Completion Tokens | 64 إلى 128 | الحكم قصير |
| System Prompt | السياسة مع صيغة مخرجات صارمة | سهل التحليل في الكود |
| Top P | 1 (الافتراضي) | يُترك كما هو عندما تكون Temperature تساوي 0 |
| Image Input | لقطات شاشة للفحص | اختياري |
أخطاء تكررها الفرق
- الموافقة مرة واحدة وعدم النظر بعد ذلك. أوصاف الأدوات تتغير. إعادة الموافقة عند كل تغيير هي أرخص ضابط تملكه.
- الثقة في خادم لأنه شائع. الشعبية ليست مراجعة. تحقق من المشرفين على المشروع وسجل إصداراته وما الذي يستطيع الوصول إليه.
- وضع الأسرار في الأمر النصي "للاختبار فقط". أسرار الاختبار تصبح أسرار إنتاج خلال أسبوع.
- منح الوكيل كل الأدوات. حمّل فقط الخوادم التي تحتاجها المهمة. عدد أقل من الأدوات يعني فرصًا أقل للتوجيه.
- تخطي السجلات لأن شيئًا لم يحدث بعد. بدونها لن تلاحظ تسريبًا هادئًا.
أنشئ صورك الخاصة على PicassoIA

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