أعلنت تحالفية “الذكاء الاصطناعي الآمن” المفتوحة عن إطلاق “تحالف تأمين الذكاء الاصطناعي المفتوح” (Open Secure AI Alliance)، بمشاركة 37 جهة من عالم السحابة والأمن والبرمجيات المؤسسية وتقنيات النماذج. الفكرة المركزية بسيطة في ظاهرها: إذا كان الهجوم يستفيد من وكلاء قادرين على تنفيذ مهام واتخاذ قرارات، فيجب أن يمتلك المدافعون أدوات يمكنهم قراءتها وفحصها وتعديلها وتشغيلها ضمن بيئتهم بدل الاعتماد على واجهات مغلقة قد لا تمنح شفافية كافية أو تحكمًا تشغيليًا.

لكن خلف هذه الرسالة توجد معركة أكثر تعقيدًا: كيف نضمن أن “الوكيل” لا يتحول إلى ناقل خطر؟ وكيف نميز بين قابلية التدقيق والاحتواء؟ وما الذي يحدث عندما يطلب الوكيل من النموذج كتابة كود وتشغيله داخل البنية؟

لماذا يهم “تأمين الوكلاء” الآن؟

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

• مسار البيانات: تسرب بيانات حساسة عبر سياق المحادثة، السجلات، أو الاستدعاءات للأدوات.
• مسار التنفيذ: تحويل طلبات النموذج إلى عمليات فعلية مثل القراءة/الكتابة على الملفات أو استدعاء الشبكة أو تغيير الإعدادات.

في هذا السياق، يصبح تأمين الوكلاء جزءًا من تأمين سلسلة البرمجيات والحوكمة التشغيلية، وليس مجرد “ضبط مرشحات” أو “رفض أوامر” داخل نموذج. لذلك تركز مبادرات مثل هذا التحالف على ما يسمى طبقة الوكيل كاملة (agent stack)، بما يشمل الهوية والصلاحيات والعزل والضوابط داخلية والتسجيل وحتى تنسيقات النماذج وإجراءات البرمجة الآمنة.

ماذا يقدّم التحالف فعليًا؟ NOOA كنقطة اختبار

وفق المواد المنشورة حتى الآن، فإن أول مساهمة تقنية مسماة تأتي من مختبرات NVIDIA عبر إطار بحثي باسم NVIDIA-labs OO Agents (NOOA). الإطار مصمم لتمكين اختبار سلوك الوكيل وتتبع قراراته وتدقيقها وحوكمتها، مع محاولة تقليل تشتت منطق الوكيل بين طبقات متعددة.

فكرة “توحيد سلوك الوكيل” داخل كود مألوف

في NOOA، يتم تمثيل طبقة “محرك الوكيل” كـ صنف برمجي بلغة Python. الفكرة ليست مجرد تنظيم الكود؛ بل جعل أجزاء من الوكيل قابلة للاختبار بنفس أدوات هندسة البرمجيات المعتادة: الاختبارات، التتبع، مراجعات الشيفرة، وإعادة البناء. يتم تقسيم سلوك الوكيل إلى نوعين:

• منطق حتمي: دوال عادية في Python تبقى محددة النتائج.
• منطق يولده النموذج: دوال تتضمن جسدًا من نوع ellipsis (مثل …) يتم إكمالها أثناء التشغيل عبر حلقة يقودها نموذج لغوي.

هذه المقاربة تلتقي مع اتجاه أوسع في الصناعة: تقليل الاعتماد على مخططات معقدة من “موجهات” متفرقة وبدلًا من ذلك بناء وكلاء يمكن إدارتهم مثل أي مكوّن برمجي آخر. هذا مهم لأن صعوبة تدقيق وكلاء الذكاء الاصطناعي غالبًا تأتي من أن منطقهم موزع بين قنوات غير قياسية: رسائل نصية، قوالب أدوات، callbackات، ورسومات تدفق غير قابلة للتفتيش بسهولة.

اختبار قابل للقياس… مع تحذير واضح

تذكر المواد أن NOOA حقق 86.8% في معيار CyberGym L1 لاستعادة ثغرات (vulnerability-rediscovery) باستخدام نموذج GPT-5.5، مع حظر وصول الشبكة وتطبيق فحوصات مبنية على قواعد على كل مسار (trajectory). هذا النوع من الاختبارات يعكس محاولة الانتقال من “تقييمات جودة النص” إلى تقييمات سلوكية قابلة للقياس.

لكن الأهم—وبما يتماشى مع نضج أمني ضروري—هو أن الإطار نفسه يقر بالمخاطر: يمكن تكوينه ليُنفذ Python يُولّد بواسطة النموذج، ما قد يؤدي إلى إرسال بيانات خاصة أو حذف ملفات أو تعديل بيئة التشغيل. لذلك توصف فحوصات مثل فحص شجرة بناء مجردة (AST) وقوائم منع الوحدات (deny-lists) بأنها طبقات دفاع إضافية وليست “حد احتواء” بحد ذاتها.

الاحتواء الحقيقي: لماذا لا يكفي “حظر الأوامر” داخل الوكيل؟

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

هذا المنطق يتقاطع مع مبدأ أمني معروف في هندسة الدفاع: Defense in Depth (يمكن توضيحه من خلال ويكيبيديا)، حيث لا يعتمد الأمن على طبقة واحدة. وفي سياق الوكلاء، قد تكون “طبقة المنع” داخل النموذج أو الإطار مفيدة، لكنها لا تعوض حدود العزل على مستوى التشغيل.

قصة Hugging Face: لماذا صارت “تشغيل النماذج محليًا” حجة أمنية؟

ربطت NVIDIA موقف التحالف بحادثة اختراق طالت Hugging Face في يوليو الماضي، حيث تم إساءة استخدام نظام وكلاء/أنظمة مستقلة للوصول إلى أجزاء من البنية الإنتاجية. وفق ما تم الإعلان عنه، لم يُظهر التحقيق دليلًا على تعديل نماذج عامة أو مجموعات بيانات منشورة أو صور حاويات أو حزم منشورة، لكن تم رصد وصول غير مصرح به إلى مجموعة محدودة من البيانات الداخلية واعتماديات (credentials) مرتبطة بخدمات الشركة.

كيف بدأ المسار الهجومي؟

وُصف مسار البداية بأنه استغلال لمجموعة بيانات خبيثة: إساءة استخدام محمل بيانات عن بعد مع حقن قوالب (template injection) في إعدادات مجموعة البيانات. ثم تطور الأمر إلى وصول للعقد (node access) وجمع الاعتماديات والحركة الجانبية عبر عدة عناقيد داخلية.

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

دور النموذج المفتوح في الاستجابة… وليس في منع الاختراق

أشارت الشركة إلى أنها أجرت تحليلًا باستخدام وكلاء مدفوعين بالنموذج على أكثر من 17,000 إجراء مُسجل لإعادة بناء التسلسل الزمني واستخراج مؤشرات الاختراق وربط الاعتماديات التي تم لمسها. كما ذكرت أن واجهات نماذج “مستضافة تجاريًا” رفضت في البداية أوامر الهجوم والحمولات (payloads) وأجزاء القيادة والسيطرة (command and control) اللازمة للتحليل.

لذلك اتجهت إلى تشغيل نموذج بوزنات مفتوحة (open-weight) داخل بنيتها، ما سمح لها بإبقاء بيانات الهجوم والاعتماديات ضمن محيطها. النص التشغيلي الذي لخصته الحادثة كان واضحًا: امتلك نموذجًا قادرًا يمكنك تشغيله على بنيتك قبل وقوع الحادث—جاهزًا، ومفحوصًا، وقابلًا للتشغيل.

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

وتضيف إفصاحات لاحقة أن سلسلة الهجوم استغلت ثغرة يوم-صفر في وسيط ذاكرة مؤقتة لسجل حزم (package-registry cache proxy) للحصول على وصول إلى الإنترنت، ثم سَلْسَلت ثغرات أخرى واعتماديات مسروقة عبر بيئات متعددة بحثًا عن إجابات لمعايير. كما تم الإشارة إلى مسار يفضي إلى تنفيذ كود عن بعد على خوادم Hugging Face. هذه التفاصيل—حتى لو اختلفت صياغتها بين الجهات—تعكس واقعًا واحدًا: الوكيل ليس المشكلة الوحيدة؛ المشكلة قد تكون في السلسلة كاملة من البوابات إلى التنفيذ.

تحالف بلا “دليل تشغيل” علني: ما الذي ينقصه كي يكون قابلًا للمراجعة؟

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

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

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

كيف ترتبط هذه الخطوة بالأطر والمعايير الأوسع؟

تركيز التحالف على الهوية والصلاحيات والعزل والتسجيل ينسجم مع توجهات أوسع في الأمن المؤسسي. يمكن ربط ذلك بأفكار مثل:

• مبدأ أقل صلاحية في التحكم بالوصول (Access Control) لتقليل الأثر عند اختراق مفاتيح أو اعتماديات.
• التجزئة والعزل للحد من الحركة الجانبية (Lateral Movement)، وهو جوهر في نماذج النضج الأمني.
• المراقبة والتسجيل كشرط للتعقب والتحقيق؛ أي أن “التأمين” لا ينتهي عند المنع.

كما أن مفهوم “الوكيل” يضيف بعدًا جديدًا إلى ممارسات مثل التحقق المستمر (Zero Trust)، إذ إن الوكيل قد يعمل ككيان يطلب صلاحيات أو يتفاعل مع أدوات متعددة، ما يعني أن الثقة ليست ثابتة بل سياقية.

ماذا يعني ذلك للجهات التي تبني وكلاء ذكاء اصطناعي؟

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

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

وبالنظر إلى أن الصناعة تتحرك بسرعة، فإن السؤال الحقيقي ليس “هل النموذج مفتوح؟” بل: هل سلسلة التنفيذ محكومة؟ هل حدود العزل قوية؟ هل يمكن إعادة بناء ما حدث؟

خلاصة وتأمل للنقاش

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

سؤال للنقاش: إذا أصبح كل وكيل قادرًا على توليد كود وتنفيذه، فهل ستتعامل مؤسساتنا مع الأمن كـ “طبقات تدقيق” داخلية فقط، أم كـ “حدود عزل تشغيلية” قابلة للقياس والتحقق قبل أن يتحول الوكيل إلى نقطة فشل؟

للمتابعة على وسائل التواصل: فيسبوك و إكس.

هاشتاغات مقترحة: #CyberSecurity #AI #Agents #SecureSoftware

ملاحظة: تم إعداد التحليل اعتمادًا على المعلومات المتاحة من مواد إطلاق التحالف ووصف حادثة Hugging Face كما وردت في السرد المرفق، مع ربط المفاهيم بممارسات أمان معروفة.