«هارنس» وكلاء الذكاء الاصطناعي يتحول إلى سطح هجوم جديد

حين يُسأل مسؤول أمني عن موطن الخطر في وكيل ذكاء اصطناعي، يكاد الجواب يبدأ دائمًا بالحديث عن النموذج نفسه: هل يمكن تجاوزه عبر «جيلبريك»، وهل يمكن الوثوق بأوزانه. هذا الانعكاس الغريزي بات متجاوَزًا بشكل متزايد. فعدد متنامٍ من عروض الاختراق، واختبارات الفرق الحمراء المستقلة، وتقييمات الباحثين، يشير بدلًا من ذلك إلى الشيفرة البرمجية التي تقع بين النموذج والعالم الخارجي. تُعرف هذه الشيفرة بـ«الهارنس» (Harness): فهي تزوّد النموذج بالأدوات، وتحوّل مخرجاته النصية إلى أفعال حقيقية — أمر Shell، أو كتابة ملف، أو استدعاء واجهة برمجة تطبيقات. وفي كثير من الشركات، لا تزال هذه الطبقة غير محصورة بالكامل، ولا مختبَرة بانتظام، ولا موكلة بوضوح إلى فريق محدد.

ما هو «الهارنس» بالضبط

عندما يُطلب من الممارسين تعريف الهارنس، تتقارب استعاراتهم من زوايا مختلفة لتصف الشيء نفسه. يصفه مايكل بارغوري، الشريك المؤسس والمدير التقني لشركة الأمن السيبراني للذكاء الاصطناعي Zenity، بأنه «يدا النموذج وساقاه وعيناه»: فالنموذج نفسه لا يُنتج سوى رموز نصية، والهارنس هو من يحوّلها إلى أمر Shell أو كتابة ملف أو استدعاء واجهة برمجية. أما روب تي. لي، كبير مسؤولي الذكاء الاصطناعي ورئيس الأبحاث في معهد SANS، فيشبّه النموذج بالمحرك والهارنس بهيكل السيارة. ويصفه مايكل سرومين، مهندس تعلّم آلي أول في شركة Lasso Security، بأنه نظام التشغيل الذي يدير الحلقة الكاملة لتطبيق قائم على الوكلاء، ويربط بين النموذج والأدوات والمستخدم. أما عمر سانتوس، المهندس المتميز في سيسكو، فيقدّم التعريف الأكثر رسمية: الهارنس هو الطبقة التي تحيط بالنموذج وتجعله قابلًا للاستخدام — وتشمل التنسيق، واستخدام الأدوات، والتعليمات النصية، والسياق، والأدوار، والتقييمات، وحواجز الأمان. تلتقي هذه التوصيفات الأربعة عند المشكلة نفسها: في الهارنس تُمارَس صلاحيات الوكيل فعليًا. فهو يقع بين استنتاج النموذج ونظام ملفات حقيقي، أو مفتاح واجهة برمجية، أو قاعدة بيانات إنتاجية. ونموذج مُحاذًى بشكل مثالي لا يُجدي نفعًا كبيرًا إن كان يعمل داخل هارنس يثق بأي نمط Shell عشوائي، أو يعيد استخدام مساحة عمل تحتوي محتوى غير موثوق عبر عدة تشغيلات.

ثلاث طرق يفشل بها الهارنس

عرض إيلاد ميغيد، المهندس المؤسس والباحث الأمني في Novee Security، في مؤتمر Black Hat USA كيف تمكّن من اختراق مستودعات الأتمتة الرسمية لدى Anthropic وGoogle وOpenAI معتمدًا فقط على تذاكر GitHub Issues. اختلفت الثغرات المحددة باختلاف كل مزوّد — من تنفيذ الشيفرة، إلى كشف بيانات الاعتماد، إلى تعليمات مزروعة يثق بها مكوّن لاحق أقوى دون إعادة التحقق منها. غير أن الخطأ المعماري الكامن كان متطابقًا بشكل لافت لدى الشركات الثلاث: مكوّن يتخذ قرارًا أمنيًا، ومكوّن آخر أقوى منه في مرحلة لاحقة من السلسلة يثق بهذا القرار دون التحقق منه مجددًا. ويلخّص ميغيد الأمر بقوله: «هذا ليس فشلًا في النموذج، بل فشل في حدود الثقة».

أما مصدر الفشل الثاني فيكمن في تصميم الهارنس نفسه، دون الحاجة إلى أي خطأ برمجي. اكتفى باحثو Lasso Security باستبدال الهارنس تحت نموذج مفتوح الأوزان واحد، مع إبقاء النموذج والتعليمات والأدوات كما هي. فارتفع معدل نجاح الهجمات من 1% إلى 24%، وانقلبت النتيجة كليًا في 43 من أصل 100 توليفة من النماذج والمهام التي جرى اختبارها. يقول سرومين: «تغيير الهارنس يعني عمليًا الحصول على وكيل مختلف تمامًا»، وينصح بتقييم الهارنس والنموذج معًا بدلًا من اعتماد إعداد افتراضي دون اختباره.

أما الثغرة الثالثة فتمتد عبر سلسلة توريد الهارنس. فحص فريق مايكل بارغوري في Zenity ما يُعرف بـ«المهارات» (skills) — وهي ملفات تُعلّم الوكيل مهمة جديدة — ووجد فيها برمجيات خبيثة لسرقة بيانات الاعتماد، كانت قد اجتازت جميع أدوات الفحص المتاحة في السوق، بما فيها أدوات Anthropic وسيسكو نفسيهما. إحدى المهارات الخبيثة كتبت نفسها داخل ملف الذاكرة الذي يعيد الوكيل تحميله عند كل إعادة تشغيل: فحذف المهارة لم يكن كافيًا، لأن تعليمة إعادة التثبيت بقيت نشطة، وعادت البرمجية الخبيثة عند التشغيل التالي. وتنكّرت مهارة أخرى في هيئة أداة رسمية من Anthropic، فحذفت الأداة الحقيقية بعد تنفيذها واستبدلتها بنسخة المهاجم، دون أي تغيير ملحوظ للمستخدم. وكانت أبرز حالة حملة استنساخ لأدوات مفتوحة المصدر شائعة، عُدّلت خفية لسرقة بيانات الاعتماد، وجُمّعت نحو 1.7 مليون عملية تنزيل قبل اكتشافها وإيقافها.

• الجرد: حصر كل هارنس يعمل في بيئة الإنتاج، حتى لو كان يُسمى داخليًا «مساعدًا» أو «مساعد سير عمل» أو «إضافة»
• رسم خريطة الصلاحيات: تحديد الأدوات والبيانات التي يمكن لكل هارنس الوصول إليها، ثم تقليص هذه الصلاحيات إلى الحد الأدنى الضروري
• الاختبار المستقل: تقييم الهارنس والنموذج معًا بدلًا من الوثوق بإعداد افتراضي دون التحقق منه

تفكّر الفرق بمنطق التطبيقات والخدمات وخطوط المعالجة والبوتات. أما الهارنس فيختفي داخل مستودعات الشيفرة ومنتجات SaaS وشاشات إعداد المزوّدين، بدل أن يظهر كأصل مستقل في جرد الأمان.

ما الذي يتغيّر بالنسبة للشركات التي تنشر وكلاء ذكاء اصطناعي داخليًا

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