ما مدى خطورة «طبقة التحكم» على وكلاء نماذج اللغات الكبيرة؟
نادرًا ما تعمل نماذج اللغات الحديثة بمفردها. غالبًا ما يتم نشرها داخل ما يُعرف بـ«البنية التحتية للوكيل» — وهي طبقة وسيطة تمنح النموذج إمكانية الوصول إلى الأدوات والإضافات والذاكرة طويلة المدى والأذونات والإجراءات الخارجية. هذه الطبقة هي التي تحدد ما يمكن للنموذج فعله وما لا يمكنه فعله.
المشكلة أن معايير الأمان الحالية تختبر عادةً سيناريوهات هجوم منفردة أو مجموعة محدودة من الظروف التشغيلية. ولهذا يصعب فهم المرحلة التي يحدث فيها الخلل بالضبط في عمل البنية التحتية: هل هو عند الإعداد، أم عند استدعاء الأداة، أم عند التعافي بعد الحادث؟ اقترح الباحثون معيار HarnessRisk، الذي ينظر إلى أمان البنية التحتية للوكيل ككل، في جميع مراحل دورة حياتها.
المراحل الست لدورة حياة البنية التحتية
قسم مؤلفو الدراسة أمان البنية التحتية إلى ست مراحل تشغيلية:
- Harness Configuration — إعداد المعلمات وصلاحيات الوصول؛
- Capability Extension — ربط القدرات والإضافات الجديدة؛
- Runtime Operation — تنفيذ المهام في الوقت الفعلي؛
- State Persistence — حفظ الحالة واستعادتها؛
- Action Control — التحكم في الإجراءات والأدوات؛
- Incident Recovery — الاستجابة للأعطال والتعافي بعد الحوادث.
كل مرحلة مسؤولة عن نطاق محدد من المسؤوليات، وقد تظهر الثغرات في أي منها. هذا التقسيم هو ما يتيح المقارنة بين كيفية تعامل البنى التحتية المختلفة مع الهجمات في ظل ظروف متطابقة.
ما الذي يقدمه HarnessRisk: السيناريوهات والمقاييس
يضم المعيار 128 سيناريو معزولًا. كل سيناريو مصمم بذكاء: تُعرض على النموذج مهمة مستخدم آمنة، لكن داخل أداة عمل غير موثوقة تُخفى تعليمات عدائية. يجب على النموذج تنفيذ الهدف المشروع دون الاستسلام للهجوم المدمج في الأداة.
يتم تقييم كل مسار وفق أربعة مقاييس:
- Utility — مدى جودة تنفيذ المهمة الأصلية؛
- Attack Success Rate — نسبة الهجمات الناجحة؛
- Persistence — المدة التي يستمر فيها تأثير الهجوم؛
- Detection — مدى فعالية النظام في رصد المخاطر.
هذا النهج يتيح رؤية ليس فقط «هل تم الاختراق أم لا»، بل أيضًا تكلفة الأمان على فائدة النموذج.
ماذا أظهرت نتائج الاختبار
أُجريت التجارب على ثلاث بنى تحتية، وست نماذج لغوية، و14 توليفة من النماذج والبنى. كانت النتائج متفاوتة: تراوحت نسبة نجاح الهجمات بين 12.6% و80.9%، بينما بقيت Utility في نطاق 75.0% إلى 97.6%. بعبارة بسيطة، قد يكون النموذج نفسه شبه محصّن في تكوين واحد وضعيف بشكل واضح في تكوين آخر.
المرحلة الأكثر عرضة للثغرات في البنى الثلاث جميعها هي Harness Configuration. غالبًا ما تنجح الهجمات ليس بسبب استغلالات معقدة، بل لأنه ضمن سير العمل «المسموح به» يمكن تعديل معلمات تؤثر على الأمان. هذه إشارة مقلقة: حتى البنية التي تبدو سليمة قد تسمح للمهاجم بتغيير قواعد اللعبة.
هناك نتيجة مثيرة للاهتمام تتعلق أيضًا باكتشاف المخاطر. بعض التكوينات تكتشف الهجمات في أكثر من 90% من عمليات التشغيل، لكنها مع ذلك تسمح بنسبة كبيرة من الهجمات الناجحة. أي أن النموذج «يدرك» أن شيئًا خطيرًا يحدث، لكنه لا يحوّل هذا الإدراك إلى سلوك آمن. الوعي بالتهديد وحده لا يحمي النظام.
الاستنتاجات: لا يمكن قياس الأمان «بالمتوسط»
الدرس الرئيسي من HarnessRisk هو أن أمان الأنظمة الوكيلة يعتمد بشكل كبير على التوليفة المحددة بين النموذج والبنية التحتية. التقييمات المتوسطة مثل «النموذج آمن» أو «البنية آمنة» لا تعني الكثير إذا لم نأخذ في الاعتبار التكوين الذي تعمل فيه.
يجب تقييم الوكلاء عبر عدة نطاقات مسؤولية للبنية التحتية في آن واحد — من الإعداد الأولي إلى التعافي بعد الحوادث. وبشكل منفصل، يجب اختبار كيفية تصرف النموذج عند هجوم مدمج في أداة عمل عادية. فقط بهذه الطريقة يمكن رصد نقاط الضعف التي تبقى خارج نطاق المعايير التقليدية.
