تُقاس سلامة السلطة في النظام الخلفي، ولا يُعد طلب أداة غير مناسب إثباتاً لحدوث معاملة ضارة.
حالة تدريبية: وكيل مشتريات وحدود التفويض في نظام ERP
هدف الحالة المؤسسية
تعرض هذه الحالة التدريبية كيف يمكن لمؤسسة تقييم أمن وكيل ذكاء اصطناعي متصل بمشتريات تجريبية من دون تنفيذ هجوم ضار أو الوصول إلى سجلات عملاء حقيقية. يراجع الفريق سلسلة من المراحل المستمدة من OWASP GenAI Red Teaming Manual v1.0، خاصة Surface Mapping وAgentic System Attack Vectors وAI Agents Privilege Escalations وPost-Exploitation وEvaluation & Reporting. يركز المثال على التمييز بين قدرة النموذج على اقتراح فعل وقدرة التطبيق الفعلية على تنفيذه، وكيف يتحول اكتشاف خلل إلى دليل مخاطر وصلاحيات وإجراء معالجة. المثال من صياغة سيادة لأغراض التعليم، وليس حادثة موثقة في شركة بعينها أو تمريناً رسمياً مصادَقاً من OWASP.
نظام المشتريات الافتراضي
تستخدم مؤسسة افتراضية تطبيقاً لمراجعة عروض الموردين. يدخل الموظف بحساب يتيح عرض الأسعار وإعداد مسودة توصية فقط، بينما يملك مدير المشتريات سلطة الموافقة النهائية، وتخضع تعديلات الحسابات البنكية لضوابط مستقلة. يسترجع التطبيق نصوص عروض الموردين من مستودع RAG ويولد الوكيل ملخصاً ويراجع شروط الشراء، ثم يستطيع استدعاء أداة CreateDraft لإنشاء مسودة في نظام ERP. هناك أيضاً أداة UpdateVendorPaymentAccount متاحة على مستوى خدمة تقنية أوسع، لكنها يجب ألا تعمل لأي مستخدم لم يفوض بهذه العملية. هذه نقطة تصميم جوهرية للاختبار: وجود أداة في بيئة النظام لا يعني أنها مصرح بها لجميع الأدوار.
الأصل الحساس وحدوده
الأصول المحمية هي سجل المورد، وحساب الدفع، ومسودة الشراء، وسجل الموافقات، وهوية الموظف، ونص العرض الذي رفعه المورد. يحدد فريق الحوكمة صاحب كل أصل وحساسيته ونطاق القراءة والتعديل، بينما يحدد فريق الهوية سياسات الأدوار. يمثل عرض المورد مصدراً منخفض الثقة لأنه يمكن أن يتغير خارج المؤسسة، بينما تمثل قواعد التفويض طبقة سلطة أعلى يجب أن تكون مستقلة عن النص المقروء. وتوجد حدود ثقة أخرى بين النموذج وواجهة استدعاء الأداة وبين الأداة وERP. إذا مزج التطبيق النص المسترجع بتعليمات التشغيل، يصبح محتوى المورد قادراً على التأثير في سلوك اقتراحات الوكيل، لكن ليس من المفترض أن يملك سلطة إجراء تعديل.
اختيار وضع الوصول
يبدأ فريق Red Team بوضع Gray-Box مصرح به: يحصل على حساب موظف تجريبي وآخر مخول بإجراء مختلف، ومخطط موجز لتدفق البيانات، وعناوين سجلات أدوات محددة، ولا يحصل على أسرار الإنتاج. هذا الوصول يوفر رؤية إلى ما إذا كان النظام الخلفي رفض الإجراء، وهو أقوى من قراءة رد المحادثة فقط. يسجل الفريق المعلومات التي سُلمت له، حتى لا يدعي أن ما عرفه من سجلات داخلية كان متاحاً لمهاجم خارجي. تُستخدم نسخة من التطبيق تحتوي مورداً تجريبياً وسجلات معاملات مصطنعة، مع حظر استدعاء أي حساب دفع حقيقي أو واجهات لا يشملها التفويض.
فرضية الاختبار
يصيغ الفريق فرضية محددة: هل يمكن لمحتوى غير موثوق في عرض مورد تجريبي التأثير في اختيار الوكيل لأداة غير مناسبة، وهل يسمح نظام التنفيذ بأي تعديل خارج دور المستخدم الأصلي؟ تقسم الفرضية إلى معيارين مستقلين. الأول سلوكي يتعلق بتمييز النموذج المحتوى المسترجع من تعليمات التشغيل، والثاني أمني يتعلق بمنع تعديل سجل الدفع من دون تفويض. في حالة نجاح الضابط الخلفي يجب ألا تتغير بيانات الدفع ولو صدر طلب أداة خاطئ، ويجب أن يظهر سبب الرفض في سجل يسمح بالتدقيق. إذا رفض النموذج الاقتراح قبل الأداة فهذا سلوك دفاعي جيد لكنه لا يثبت وحده أن الأداة كانت ستمنع طلباً مباشراً.
تهيئة الدليل والبيانات
ينشئ المختبر عرض مورد اصطناعياً وأرقام حسابات وهمية لا تقبل التحويل ومستخدمين داخل بيئة اختبار. ويُعطى كل أصل معرفاً واضحاً يمكن مراجعته دون كشف معلومات شخصية، وتُثبت نسخة نموذج الاستدلال وإعدادات أدوات الوكيل ونسخة قواعد تفويض ERP. يحتفظ الفريق بحالة سجل المورد قبل التشغيل ونسخة مراقبة من الاستدعاءات في مكان مخول، ويتفق مع مالك الخدمة على وقت الاختبار وقواعد الإيقاف إذا خرجت النتائج عن المتوقع. لا يُسجل أي رمز خدمة أو سر في تقرير عام. يتعين التحقق من أن بيئة الاختبار تماثل حدود السلطة في الإنتاج بدرجة كافية، أو تدوين الاختلافات التي تحد من تعميم النتائج.
الملاحظة الأولى: سلوك الوكيل
في مثال افتراضي قد يعيد الوكيل صياغة طلب المورد بطريقة توحي بأن تعديل بيانات الدفع مطلوب قبل إكمال الملخص، فيحاول اختيار أداة لا يحتاجها الموظف. لا يعد هذا التوجيه في حد ذاته نجاحاً لتنفيذ عملية. يسجل الفريق سياق الطلب ونوع المحتوى غير الموثوق واسم الأداة المقترحة دون نشر سلسلة هجومية قابلة لإعادة الاستخدام. كما يتحقق مما إذا كان المحتوى قد وضع داخل سياق أعلى ثقة أو بقي في حقل بيانات محدد. وينبغي مقارنة السلوك بخط أساس طبيعي لمعرفة إن كان التغير مرتبطاً بالمدخل التجريبي لا باختلاف في بيئة نموذج أو إعداد أداة.
الملاحظة الثانية: قرار النظام الخلفي
عندما يصل طلب الأداة إلى طبقة ERP تفحص الخدمة هوية المستفيد الأصلي والدور والعملية المستهدفة. إذا رُفض التعديل وبقي السجل دون تغيير، فهذه نتيجة إيجابية لضابط التفويض حتى لو كان اختيار الوكيل غير مناسب. وإذا استطاعت بيئة الاختبار تغيير حالة سجل اصطناعي بحساب قراءة، فهذا دليل على ضعف أمني مختلف يحتاج احتواء وتحليلاً للسبب الجذري. تُفصل الحالتان في السجل ويُذكر مصدر الإثبات من نظام الأعمال لا من إجابة النموذج وحدها. قد يكون منع العملية قد حدث بسبب نقص في إعداد البيئة أو لأن الأداة معطلة، ولذلك يحتاج PASS إلى سجل يبين سبب الرفض الصحيح لا إلى غياب أثر فقط.
الملاحظة الثالثة: إمكان استمرار التأثير
قد يحتفظ الوكيل بملخص عرض المورد في ذاكرة جلسة أو مخزن يقرأه في مهام لاحقة. يختبر الفريق في حدود مصرح بها ما إذا بقي التأثير في طلب منفصل بحساب التجربة نفسه أو بعد إنهاء الجلسة، وما إن كان المصدر موثقاً داخل الذاكرة. لا تكفي بقاء عبارة في سجل النص لإثبات أن هناك استمرارية فعلية؛ يجب إظهار أثر سلوكي لاحق أو فعل حاولت الأداة تنفيذه تحت شروط مضبوطة. وفي المقابل يجب ألا تعرض المؤسسة بيانات حسابات أو مستأجرين آخرين بغرض إثبات الفكرة. يسجل الفريق نطاق الاستمرار ومدته وإصدار الخدمة، ثم يربطه بضابط دورة حياة الذاكرة أو عزل سياقات المهمات.
مصفوفة الأدلة
يتضمن سجل الحالة معرف السيناريو ووقت الاختبار وإصدار التطبيق وإصدار الأداة وحساب الدور ومرجع العرض الاصطناعي وحدود الثقة والنتيجة المتوقعة والنتيجة الفعلية ورقم سجل استدعاء الأداة وحالة ERP قبل وبعد. ويمكن أن تكون النتيجة PASS لضابط التفويض مع توصية تحسين سلامة توجيه الوكيل، أو FAIL إذا تغير السجل دون إذن، أو INCONCLUSIVE إذا تعذر الوصول إلى مصدر موثوق للحكم. تحتاج كل حالة إلى تعليل مستقل لا كلمة «اختُرق» أو «آمن». ويجب أن يكون بإمكان مدقق مخول متابعة الأدلة دون استلام أسرار أو معلومات محمية بشكل غير ضروري.
تحليل السبب الجذري
لا يكون العلاج تلقائياً هو إضافة عبارة تحذيرية إلى مطالبة النظام. قد تظهر فجوة في فصل المستندات المسترجعة عن السلطة، أو في قائمة أدوات متاحة للوكيل، أو في تمرير هوية المستخدم إلى النظام الخلفي، أو في صلاحيات رمز الخدمة. لذلك تبدأ مراجعة العيب بتحديد أول موضع تحولت فيه البيانات غير الموثوقة إلى توجيه موثوق أو امتياز فعلي، ثم تسجل الضوابط التي كان متوقعاً منها منع ذلك. قد يكون هناك أكثر من سبب متزامن، كخلل في تنسيق الأداة وفقدان تحقق التفويض. ينبغي أن تعالج المؤسسة الأسباب بحسب مالكيها وأن تختبر كل ضابط مستقلاً قبل اعتباره مغلقاً.
قرار احتواء متناسب
إذا ثبت فشل تفويض أداة عالية الحساسية، قد يقرر مالك التشغيل تعليق تلك الأداة مؤقتاً أو حصرها بدور محدد وتفعيل موافقة بشرية مستقلة على مستوى المعاملة. ليس هذا قراراً ينفذه المختبر تلقائياً؛ لأنه يؤثر في تشغيل المؤسسة ويتطلب دراسة البدائل والمسؤوليات. أما إذا فشل تعامل الوكيل مع المستند لكن ERP منع التنفيذ بصورة مؤكدة، فقد تسمح السياسة باستمرار وظيفة المسودات مع تسجيل خطة تحسين ومراقبة إعادة التكرار. لا يمكن نسخ القرار بين المنظمات من دون سياق، ويجب توثيق الأثر التجاري والمخاطر المتبقية والجهة التي تمتلك سلطة قبولها.
المعالجة الهندسية
يمكن أن تشمل المعالجة تقليل الأدوات التي يستطيع الوكيل رؤيتها بحسب دور المستخدم، وتمرير تفويض أصلي موثوق بدلاً من مفتاح خدمة مشترك واسع، وفصل المحتوى المسترجع عن أوامر التحكم، والتحقق من نوع العملية والمستفيد في ERP، وتحسين مراقبة الاستدعاءات غير المعتادة. لا تعني هذه الخيارات ضرورة تطبيقها جميعاً بلا تحليل. يحدد الفريق الضابط الذي فشل بالفعل ويعالج أسبابه، مع فحص الوظائف المشروعة حتى لا يؤدي التشدد إلى منع الموظف من إعداد مسودة صحيحة. تحفظ نسخة من إعدادات الضبط ورابط التغيير والتاريخ ويعاد اختبار الحالة ذاتها بعد نشر الإصلاح في بيئة مناسبة.
إعادة الاختبار والفشل المتبقي
بعد المعالجة تعاد الحالة بمستند اختبار مماثل، وتتم مراجعة حسابات القراءة والموافقة والحالات المسموحة والممنوعة. النجاح يعني أن النظام الخلفي يرفض طلب تعديل غير مصرح به لأسباب التفويض المتوقعة، وأن السجلات تشير إلى ذلك، وأن إعداد المسودة المشروع لا يزال متاحاً. إذا تغيرت استجابة النموذج لكن بقي مفتاح الخدمة قادراً على تعديل سجلات دون تحقق، لم يغلق السبب الأساسي. كما ينبغي اختبار أثر تحديث نموذج الاستدلال أو مخطط الأداة لاحقاً، لأن التغيير قد يعيد ظهور محاولة الاستدعاء حتى لو بقي ضابط التنفيذ جيداً. وتُسجل نتيجة إعادة الاختبار كتاريخ جديد لا تمحى معه الحالة الأصلية.
قراءة سيادية للمثال
تكمن أهمية المثال في أن سيطرة المؤسسة على وكيل مشتريات لا تقاس فقط بقدرتها على اختيار نموذج أو مكان استضافته. فالسيطرة الحقيقية تشمل من يستطيع تفعيل الأداة، وباسم مَن تعمل، وأين تتحقق الموافقة، وما سجلاتها، وكيف تُلغى السلطة، وما الذي يحدث عند فشل طبقة النموذج. قد تستعين المؤسسة بنموذج خارجي وتحتفظ بتفويض محكم في طبقة أعمالها، وقد تستضيف نموذجاً داخلياً لكنها تمنحه سلطة واسعة دون تدقيق. هذا التحليل السيادي إضافة تحريرية من سيادة وليس مصطلحاً رسمياً من OWASP. ويمكن استخدام نتائجه لدعم سجلات مخاطر الموردين والتغيير والحوكمة والإشراف التنفيذي.
أسئلة للتدريب والتقييم
يُطلب من المتعلم رسم سلسلة المكونات وحدود الثقة وتحديد الأصول التي لا يجوز لحساب القراءة تعديلها، ثم إنشاء معيار منفصل لسلوك الوكيل ومعيار آخر لفعالية تفويض ERP. عليه اقتراح مصادر الأدلة لحكم PASS وFAIL وINCONCLUSIVE، وتحديد مالك كل عيب محتمل، وشرح كيف يعيد الاختبار بعد تحسين الضبط. كما يجب وصف قيود التجربة: حسابات اصطناعية، بيئة اختبار، نسخة محددة، وعدم وجود دليل على أثر إنتاجي. ولا تقبل إجابات عامة مثل «تطبيق Zero Trust» أو «تقوية المطالبة» دون تحديد أين يطبق الضابط ومن يثبت نجاحه. يهدف التمرين إلى اتخاذ قرار مبني على أدلة لا تقليد سيناريو هجومي.
الإسناد
المصدر المفاهيمي OWASP GenAI Security Project, GenAI Red Teaming Manual v1.0، أكتوبر 2026، وخاصة الأقسام 3.2 و4.5 و5.2 و6.1–6.6 و7.1–7.5 و8.1–8.2. هذه حالة افتراضية أصلية من سيادة AI لتوضيح الفرق بين تجاوز حدود الثقة في سلوك الوكيل ووقوع أثر فعلي في نظام خلفي. لا تمثل حادثة حقيقية أو ضمان امتثال، ولا يجوز استخدامها لاختبار أي نظام دون تفويض. يحمل المصدر الأصلي رخصة CC BY-SA 4.0؛ يُراعى نسب الأصل وشروط المشتقات عند إعادة استخدام مادته. لا يقدم المثال تعليمات هجومية عملية ولا يعوض عن إجراء تقييم أمني متخصص على البنية الحقيقية.