أمن الوكلاء وخوادم MCP والتفويض المستقل للأدوات

ماذا تضيف الأنظمة الوكيلة

يناقش OWASP GenAI Red Teaming Manual v1.0 في القسم 4.5 أسطحاً جديدة تظهر عندما يستطيع الوكيل اكتشاف أدوات وقراءة تعليمات خارجية وتفويض مهام إلى وكلاء آخرين والاحتفاظ بذاكرة. لا يقتصر الأمر على سلوك مخرجات النموذج؛ فالمطلوب أن يعرف مالك النظام من يملك السلطة التي تستخدمها الأداة وماذا يحدث إذا وصل محتوى أقل ثقة إلى سياق الوكيل. يؤكد المصدر ضرورة فحص تفويض مستقل عن النموذج، مع الانتباه إلى أن العملية قد تكون مسموحة تقنياً لدور المستخدم لكنها غير متسقة مع مقصده الأصلي. يركز الدرس على ضوابط الهوية والأدوات والخدمات، وعلى الأدلة التي ينبغي جمعها لتقييمها بسلام.

سلسلة التفويض الفعلية

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

الوَكيل بوصفه نائباً مرتبكاً

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

صلاحية الكائنات في API

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

تطبيق صلاحيات على الجانب الخادمي

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

مخاطر اكتشاف الأدوات

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

نتائج الأدوات ومصدر الثقة

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

أدوات متعددة ومصادر مختلفة

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

الذاكرة والحالة المستمرة

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

الرصد والتكلفة

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

معايير تقييم الأفعال

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

المراجعة البشرية والسلطة

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

مخطط معالجة مؤسسي

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

حالة تدريبية

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

تمرين التحقق

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

ما لا يثبته التقييم

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

المرجع

المصدر: OWASP GenAI Security Project, GenAI Red Teaming Manual v1.0، أكتوبر 2026، القسم 4.5 Agentic System Attack Vectors من الصفحة 80، بما فيه API Object-Level Authorization وClient & Edge Inspection وEndpoint Telemetry & Extraction Controls وModel Context Protocol Servers. يدمج الدرس تحليل السلطة والحوكمة من سيادة AI، ولا يمثل ترجمة رسمية أو إثبات امتثال عام. جميع الأمثلة دفاعية ومحكومة بنطاق اختبار مصرح، ويجب احترام شروط CC BY-SA 4.0 للمصدر عند تكييف مادته.