تقرير ميداني · دراسة معمّقة
تقرير ميداني من واقع VamiGRC
يُبقي خادم MCP الآمن كل قرار ذي أهمية خارج متناول وكيل الذكاء الاصطناعي. فخلال بناء خادم MCP الذي يربط مساعدي الذكاء الاصطناعي مثل Claude بـ VamiGRC، تعلّمنا أن التأكيد داخل المحادثة ليس ضابطًا أمنيًا: إذ يستطيع الوكيل المُتلاعَب به أن يجيب عنه بنفسه. ويعرض هذا التقرير كيف نقلنا الهوية والموافقات والاستقلالية وحدود المستأجرين إلى النظام الخلفي (Backend)، وكيف اختبرنا كلًّا منها، وما الحدود التي لا تزال قائمة.
منذ مراجعة يونيو 2025 لمواصفة MCP، أصبح خادم MCP المحمي خادمَ موارد وفق OAuth 2.1. غير أن التطبيق العملي متأخر عن ذلك، ومنصة GRC ترفع سقف المخاطر.
8.5%
من أكثر من 5,200 خادم MCP مفتوح المصدر جرى فحصها في أكتوبر 2025 كانت تستخدم OAuth.
State of MCP Server Security 2025: Research Report (أكتوبر 2025) (يفتح موقعًا خارجيًا)
Specification, Revision 2025-06-18: Authorization (يونيو 2025) (يفتح موقعًا خارجيًا)
يقرأ الوكيل المخاطر والحوادث وبيانات الموردين، ويستطيع تغييرها. والتغيير الخاطئ ليس مجرد خلل برمجي: فقد يزيّف أدلة الإثبات التي يعتمد عليها المدقق.
كيف يمكن لوكيل ذكاء اصطناعي أن يعمل على بيانات الامتثال دون أن يصبح الحلقة الأضعف في المنصة؟
نمذجنا ثلاثة مهاجمين، مستخدمين STRIDE لتحديد فئة الخلل، وOWASP MCP Top 10 كتالوجًا للمخاطر. اختاروا مهاجمًا لتروا الضوابط التي تحدّ منه، والاختبارات السلبية ذات الصلة، وما يتبقّى من مخاطر.
ما يتبقّى: في جلسة مختطفة، لا يزال بإمكان الوكيل التأكيد في المحادثة على المستوى L2، كما يستطيع كتابة مرجع الحذف بنفسه. لذلك تتطلب عمليات الحذف والقرارات موافقة داخل التطبيق. أما حقن الأوامر نفسه فلا يمكن منعه منعًا تامًا.
ما يتبقّى: يبقى ممكنًا كل ما تسمح به واجهة API العامة وحدود المؤسسة: لا تزال الجلسة المختطفة قادرة على أن تؤكد في المحادثة على المستوى L2 التغييرات غير الحذف والقرارات، كما أن التراجع ممكن جزئيًا فقط.
الخيط المشترك: الوكيل المُتلاعَب به لا يقتحم النظام، بل يستخدم صلاحيات يملكها بصورة مشروعة. لذلك يجب أن يقع كل ضابط حيث لا يستطيع الوكيل الوصول إليه.
لا يحمل الوكيل أبدًا رمزًا يقبله النظام الخلفي بوصفه جلسة مستخدم عادية. وهذه سلسلة تسجيل الدخول في أربع خطوات:
يكتشف المساعد خادمَ التفويض من خلال بيانات Protected Resource Metadata الخاصة بخادم MCP (RFC 9728).
يسجّل المستخدم الدخول إلى VamiGRC نفسه، ويرى شاشة لمنح الإذن تُبيّن أي مساعد، وهل الصلاحية قراءة فقط أم قراءة وتعديل، وأي مستأجر.
يتلقى المساعد رمز وصول صالحًا لدقائق لا لأيام، ومرتبطًا بخادم MCP بوصفه جمهوره (Audience)، إضافةً إلى رمز تحديث يتغيّر مع كل استخدام.
لا يقبل النظام الخلفي هذا الرمز إلا كما يقبل رمز API مقيَّدًا: واجهة API العامة فقط، ولا وظائف إدارية أبدًا، ولا صلاحيات تتجاوز دور المستخدم نفسه.
كان تصميمنا السابق يبادل تسجيل دخول المستخدم برمز للنظام الخلفي لدى مزوّد هوية خارجي. ونجح ذلك، لكن الجلسات الطويلة الأمد وتبادل الرموز (Token Exchange) لم يتوافقا جيدًا، فكان المستخدمون يرون «انتهت صلاحية تسجيل الدخول» بعد فترات الخمول. وحين أصبح VamiGRC نفسه خادم التفويض، زالت هذه الفئة من المشكلات.
تسبّب نطاق (Scope) واحد مفقود، هو offline_access، في إخفاق عميل ذكاء اصطناعي كبير قبل أن يعرض صفحة تسجيل الدخول أصلًا.
الأسس: RFC 9728: OAuth 2.0 Protected Resource Metadata (أبريل 2025) (يفتح موقعًا خارجيًا) · RFC 8707: Resource Indicators for OAuth 2.0 (فبراير 2020) (يفتح موقعًا خارجيًا) · RFC 9700: Best Current Practice for OAuth 2.0 Security (يناير 2025) (يفتح موقعًا خارجيًا) · The OAuth 2.1 Authorization Framework (Internet-Draft) (يفتح موقعًا خارجيًا)
كان إصدارنا الأول يطلب من المستخدم تأكيد كل تغيير داخل المحادثة. وبدا ذلك آمنًا، لكن الردّ على التأكيد كان يجري في القناة نفسها التي يتحكم فيها المهاجم.
الضابط يقع في قناة المهاجم.
لا يستطيع الوكيل تزييف هذه الطبقات. وتتطلب عمليات الحذف والقرارات فوق ذلك موافقة داخل التطبيق.
كل عملية كتابة استدعاء من خطوتين: الأولى تُعيد معاينة وتحفظها على الخادم، ولا تتم الكتابة إلا بتأكيدها. وإذا تغيّر السجل في الأثناء، يُرفض التأكيد.
في خطوة التأكيد، يوقّع خادم MCP الطلب بعينه. ويرفض النظام الخلفي أي عملية كتابة من دون هذا الإثبات، لذا لا يستطيع رمز وصول مسروق يُستخدم مباشرةً ضد واجهة API أن يكتب شيئًا.
مجرد «نعم» لا يحذف شيئًا. إذ يجب على المستخدم كتابة مرجع السجل، وتذكر المعاينة كل ما يرتبط بالسجل. أما السجلات القابلة للأرشفة فتُؤرشف بدلًا من محوها.
لا يستحق كل إجراء القدر نفسه من الثقة. فكل مسار كتابة في واجهة API العامة ينتمي إلى فئة إجراءات، وتحدّد المؤسسة أعلى مستوى استقلالية لكل فئة، وفق مستويات VamiGRC من L0 إلى L3.
L0
لا يُسمح للوكيل بالتصرّف.
في خادم MCPيُرفض الطلب مع سبب واضح، ويتصرّف المستخدم بنفسه في VamiGRC.
L1
يُعِدّ الوكيل، ويتصرّف المستخدم.
في خادم MCPمسودة يراجعها المستخدم ويحفظها.
L2
يتصرّف الوكيل بعد موافقة إنسان.
في خادم MCPمعاينة ثم تأكيد، أو موافقة داخل التطبيق لعمليات الحذف والقرارات.
L3
يتصرّف الوكيل وحده، ويُسجَّل كل شيء.
في خادم MCPلفئات منخفضة المخاطر فقط، مثل الملاحظات.
تحدّد المؤسسة الحد الأقصى، ولا يستطيع كل مستخدم إلا تضييقه لمساعديه. ويسري دائمًا الإعداد الأشدّ صرامة.
لا تُنفَّذ عمليات الحذف والقرارات باستقلالية أبدًا، ولا تمرّ القرارات الموقَّعة، مثل الموافقات، عبر المحادثة أبدًا.
يُعدّ المسار الذي لا فئة له محظورًا. ويفشل أحد الاختبارات فور ظهور مسار كتابة جديد بلا فئة.
اختاروا فئة إجراءات، والحد الأقصى للمؤسسة، والحد الشخصي. وتطبّق الحاسبة القواعد الثلاث.
المستوى الساري
L2تنفيذ بالذكاء الاصطناعي مع موافقة إلزامية
معاينة ثم تأكيد، أو موافقة داخل التطبيق لعمليات الحذف والقرارات.
يقيّده الحد الأقصى للمؤسسة.
نموذج مبسّط مبني على هذا التقرير الميداني، وليس نسخة من إعدادات المنتج.
يعمل المستشارون لصالح عدة عملاء، لذا كثيرًا ما يكون لشخص واحد حق الوصول إلى عدة مستأجرين. ويتبع خادم MCP المستأجرَ الذي اختاره المستخدم في تطبيق VamiGRC، مع التحقق منه عند كل استدعاء ودون تخزين مؤقت. غير أن هذه السهولة تُنشئ خطرًا جديدًا.
تحفظ المعاينة مستأجرها وشركتها، ويذكرهما الردّ.
يتبع خادم MCP هذا التبديل عند الاستدعاء التالي.
يُرفض التأكيد قبل إرسال أي شيء.
يرفض الخادم الطلب بدلًا من الانتقال بصمت إلى مستأجر آخر.
يحاول كل اختبار كسر أحد الضوابط، ويُنفَّذ من طرف إلى طرف على نظام خلفي حقيقي وعميل MCP حقيقي، لا في اختبارات الوحدات فحسب.
| الفحص | المتوقع | النتيجة |
|---|---|---|
| استخدام رمز التفويض مرتين | مرفوض، ويُنهى الاتصال الذي أنشأه | ناجح |
| إعادة استخدام رمز تحديث قديم بعد التدوير | مرفوض، ويُنهى الاتصال بأكمله | ناجح |
| مجرد «نعم» على معاينة حذف | لا يُحذف شيء، ويُطلب المرجع | ناجح |
| تبديل المستأجر بين المعاينة والتأكيد | يُرفض التأكيد، ولا يُكتب شيء | ناجح |
| عدة تبديلات متتالية للمستأجر | يتبع الاتصال كل تبديل | ناجح |
| الحذف عبر المعرّف في شركة أخرى | غير موجود، ويبقى السجل سليمًا | ناجح |
| الكتابة من دون إثبات التأكيد | مرفوض | ناجح |
| الحد الشخصي أشدّ صرامة من حد المؤسسة | يسري الحد الأشدّ صرامة | ناجح |
وما كشفها هو اختبار الضوابط كما يفعل المهاجم، لا اختبار الوظائف فحسب.
خمس خلاصات تنطبق على خوادم MCP الأخرى أيضًا، وخمسة حدود نذكرها بصراحة.
عشرة أسئلة مستمدة من هذا التقرير الميداني. وكلما أجبتم بـ «نعم» أكثر، قلّ اعتماد أمنكم على ما يفعله الوكيل.
تمت الإجابة: 0/10
النتيجة للاسترشاد فقط، وليست دليل إثبات للتدقيق. ولا تُرسَل إجاباتكم.
هكذا نطابق الضوابط مع كتالوجات المخاطر. والكتالوجان كلاهما حديث العهد، وستتغيّر المطابقة بتغيّرهما.
MCP01
OWASP MCP Top 10 (v0.1, Beta) (يفتح موقعًا خارجيًا)
لا تمرير للرموز، ورموز قصيرة العمر ومرتبطة بالجمهور (Audience)، ورموز تحديث دوّارة مع كشف إعادة الاستخدام، ووصول يقتصر على واجهة API العامة.
MCP10
OWASP MCP Top 10 (v0.1, Beta) (يفتح موقعًا خارجيًا)
تذكر الردود المستأجر والشركة، وتُوسَم البيانات المأخوذة من السجلات بوصفها غير موثوقة، ولا يرى الوكيل إلا ما يسمح به دور المستخدم.
LLM06:2025
OWASP Top 10 for LLM Applications 2025 (يفتح موقعًا خارجيًا)
مستويات استقلالية لكل فئة إجراءات، وسقوف صارمة، وموافقة داخل التطبيق لعمليات الحذف والقرارات.
قائمة OWASP MCP Top 10 إصدار Beta، وAgent Control Standard في الإصدار 0.1.0. المخاطر العشرة لـ MCP كاملةً في دراستنا المعمّقة
التقرير الميداني معدًّا لصنّاع القرار: نموذج التهديدات، والهوية دون تمرير الرموز، والموافقات في النظام الخلفي، ومستويات الاستقلالية والحوكمة، والربط بالمستأجر وسجل التدقيق، والاختبارات السلبية، وأسئلة للموردين، وخطة 30-60-90 يومًا.
نفحص خوادم MCP وتكاملات الوكلاء على النحو الذي يصفه هذا التقرير: بنموذج للتهديدات، وضوابط خارج متناول الوكيل، واختبارات سلبية.
المواصفات والمعايير والدراسات التي يستند إليها هذا التقرير الميداني.
إجابات موجزة
لأنه يجري في القناة نفسها التي يتحكم فيها المهاجم. فالوكيل المُتلاعَب به عبر حقن الأوامر يستطيع أن يجيب عن السؤال بـ «نعم» بنفسه، ومن يملك رمز وصول مسروقًا يتجاوز المحادثة كليًا. والأكثر فعالية هي الضوابط التي لا يستطيع الوكيل تزييفها: معاينات يفرضها الخادم، وإثبات تأكيد مرتبط بالطلب بعينه، وموافقة داخل التطبيق لعمليات الحذف والقرارات.
منذ مراجعة يونيو 2025، أصبح خادم MCP المحمي خادمَ موارد وفق OAuth 2.1. وتشترط المواصفة اكتشاف البيانات الوصفية عبر بيانات Protected Resource Metadata (RFC 9728)، وPKCE، ورموزًا تُصدَر لخادم MCP بوصفه جمهورها (Audience)؛ أما تمرير الرموز فمحظور. ويُبيّن التقرير الميداني ما يلزم فوق ذلك حالما يُسمح للوكيل بالكتابة.
تحدّد ما يجوز للوكيل فعله بمفرده: L0 يدوي، وL1 بمساعدة الذكاء الاصطناعي، وL2 تنفيذ بالذكاء الاصطناعي مع موافقة إلزامية، وL3 استقلالية كاملة وتدقيق كامل. وفي خادم MCP الخاص بـ VamiGRC، تحدّد المؤسسة أعلى مستوى لكل فئة إجراءات، ولا يستطيع كل مستخدم إلا تضييقه، ويُحظر المسار الذي لا فئة له. ولا تُنفَّذ عمليات الحذف والقرارات باستقلالية أبدًا.
لا. تُوسَم النصوص المأخوذة من السجلات بوصفها غير موثوقة، لكن النموذج قد يتبعها رغم ذلك. فالضوابط تحدّ مما يستطيع الوكيل المُتلاعَب به فعله، لكنها لا توقف التلاعب نفسه. لذلك تتطلب عمليات الحذف والقرارات موافقة داخل التطبيق.
باختبار سلبي لكل ضابط يحاول كسره عمدًا: استخدام رمز التفويض مرتين، وإعادة استخدام رمز تحديث قديم، وتبديل المستأجر بين المعاينة والتأكيد، والكتابة من دون إثبات التأكيد، والحذف عبر المعرّف في شركة أخرى. وكل ذلك من طرف إلى طرف على نظام خلفي حقيقي وعميل MCP حقيقي، لا في اختبارات الوحدات فحسب.
كلاهما في بداياته: فقائمة OWASP MCP Top 10 إصدار Beta يحمل الرقم 0.1، وAgent Control Standard في الإصدار 0.1.0. ونطابق ضوابطنا مع Token Mismanagement & Secret Exposure وContext Injection & Over-Sharing وExcessive Agency، وسنعدّل المطابقة مع نضج المعايير.
نفحص خوادم MCP وتكاملات الوكلاء كما يفعل المهاجم، ونُبيّن أي القرارات لا تزال في متناول الوكيل.
