باحثون فحصوا 6 309 من agent skills: نصفها يملك صلاحية الوصول إلى shell

يبدو الـ skill الخاص بالوكيل كملف Markdown بريء، لكن الوكيل يقرؤه بوصفه تعليمات وينفذه بصلاحيات الجلسة التي حمّلته. قاس مؤلفو دراسة جديدة على Hugging Face Daily Papers مقدار السلطة التي يسلّمها المستخدم عند التثبيت. حلّلوا 6 309 إدراجات من سوقين هما ClawHub وskillsmp. لدى نصفها مؤشرات على القدرة على تنفيذ الأوامر في shell، وسبعة من كل عشرة تحمل قدرة مرتفعة واحدة على الأقل. وعند التثبيت لا يظهر من ذلك شيء تقريبًا.

المنهجية من مرحلتين. تبدأ بتحليل ساكن للحزمة (bundle) كاملة، لا لملف SKILL.md وحده، إضافةً إلى التحقق من مصدر التبعيات. ثم يُشغَّل الـ skill في sandbox مزوّدة بأدوات القياس، ويقيّم نموذج الآثار (traces) الناتجة بشكل منفصل. وثمة تفصيل مهم في العينة: اختيرت الإدراجات المخصصة للتشغيل دون الاستناد إلى إشارة مسبقة إلى تهديد أو خطر. لذلك تصف النتائج السوق ككل، لا المواقع المشبوهة وحدها، وهي التي تصل عادةً إلى التقارير.

ماذا أظهر القياس

يؤكد المؤلفون أن تثبيت الـ skill لا يمنحه امتيازات جديدة، بل يمنحه حق توجيه الوكيل. وهم يقيسون حجم هذا الحق. وفيما يلي نسب القدرات في المجموعة كاملة:

• تنفيذ shell: 50% من الإدراجات؛
• قراءة نظام الملفات: 35%؛
• الكتابة في نظام الملفات: 31%؛
• الاتصال الصادر بالشبكة (network egress): 31%؛
• الوصول إلى بيانات الاعتماد: 13%؛
• قدرة مرتفعة واحدة على الأقل: نحو 70%.

من المهم أن الدراسة لا تقتصر على البحث عن skills خبيثة. فقد تكون معظم هذه القدرات مشروعة تمامًا: فالـ skill المخصص للنشر (deployment) لا يستغني عن shell. لكن المستخدم يقبل سطح الهجوم هذا كله بنقرة واحدة، دون أن يعرف حدوده.

الإعلانات مقابل الواقع

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

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

وحتى حين يصرّح المؤلف، فإنه كثيرًا ما يخطئ أو يسكت عن أمور: 59% من الإدراجات المصرِّحة تقلّل من القدرات الفعلية. وتختلف المنصتان بوضوح. فـ ClawHub تصرّح بنحو ضعف ما تصرّح به skillsmp، لكنها تقلّل من القدرات في 88% من تصريحاتها مقابل 31% لدى المنافس. أي إن الحرص الأكبر على ملء الحقول لا يدل على صدق أكبر.

كيف نبني الفحص عمليًا

الاستنتاج الرئيسي للمؤلفين بالنسبة إلى الأسواق: لا ينبغي بناء الفرز (triage) على المعلن، بل على ما تستطيع الحزمة فعله فقط. يجيب كاشف البرمجيات الخبيثة عن سؤال «هل المؤلف سيئ النية». أما ملف القدرات فيجيب عن سؤال آخر: «ماذا سيحدث إذا اختُرق الـ skill أو أخطأ أو خُدع عبر prompt injection». وهذان الفحصان يكمّل أحدهما الآخر.

يُستحسن للفرق التي تربط skills من جهات خارجية بالوكلاء أن تفعل عدة أمور منذ الآن:

• فحص الحزمة كاملة، بما في ذلك السكربتات والتبعيات، لا الاكتفاء بقراءة الوصف؛
• وضع الـ skills التي تملك shell أو الكتابة في نظام الملفات أو الاتصال الصادر بالشبكة أو الوصول إلى credentials في قائمة منفصلة، واعتمادها يدويًا؛
• عدم اعتبار pre-approved tools في frontmatter إجراءً أمنيًا: فهي مجرد وسيلة لإزالة التأكيدات؛
• تشغيل الـ skills غير المعروفة في sandbox بلا أسرار ومع تقييد حركة البيانات الصادرة؛
• عدم منح جلسة الوكيل صلاحيات تفوق ما يحتاجه أكثر الـ skills المحمّلة حساسية.

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