رسم تدفق البيانات وحدود الثقة في تطبيق RAG والوكلاء

نقطة الانطلاق

يربط OWASP GenAI Red Teaming Manual v1.0 في القسم 3.2 بين Trust Boundaries وData-Flow Mapping، وهو من أهم مكونات الانتقال من اختبار النصوص إلى فحص التطبيق المؤسسي. حد الثقة ليس مجرد جدار شبكي؛ قد يقع داخل الطلب نفسه عندما ينتقل نص غير موثوق من مستند مسترجع إلى مساحة تفسرها طبقة التنسيق على أنها أمر. وقد يقع بين وكيل يقترح إجراء وبين API ينفذه مستخدماً رمز خدمة أوسع من صلاحية صاحب الطلب. يهدف الدرس إلى تعلم كيفية رسم تلك الحدود وإسنادها إلى ضوابط يمكن إثبات فعاليتها في السجلات، مع إبقاء التحليل مرتبطاً بالأصول والأدوار بدلاً من الاكتفاء بقائمة هجمات معروفة.

تقسيم التطبيق إلى طبقات

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

تعريف عقدة المصدر

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

تسمية الأسهم بوضوح

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

حد دخول محتوى المستأجر

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

حد صلاحيات الأداة

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

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

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

المعاملات والالتزام

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

التسجيل بوصفه حد رؤية

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

إعداد قائمة حدود الثقة

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

تحويل المخطط إلى سيناريو

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

إدارة التغيير المعماري

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

تدريب عملي على رسم خريطة

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

أخطاء شائعة في المخرجات

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

مصدر الدرس

يرتكز هذا الدرس على القسم 3.2 Trust Boundaries & Data-Flow Mapping من OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026، بدءاً من الصفحة 34، مع الاستفادة من قسم 3.3 Threat Modeling وقسم 4.5 Agentic System Attack Vectors عند تحويل الحدود إلى حالات اختبار. المحتوى بناء تعليمي وتحليلي عربي من سيادة AI لا يمثل ترجمة رسمية أو شهادة أمن، ويجب استخدامه داخل أنظمة مخول اختبارها فقط. ترخيص الوثيقة الأصلية CC BY-SA 4.0 وتُراعى شروطها عند نقل المواد المرخصة أو تعديلها.