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

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

من هم المشاركون وما الذي يحاول التحالف فعله؟

يضم التحالف 37 جهة تمتد عبر سلاسل توريد متعددة: سحابة وأمن مؤسسي وبرمجيات مؤسسات ومنصات ذكاء اصطناعي. من بين الأسماء المذكورة: [مايكروسوفت] و[سيسكو] و[كلاودفلير] و[كراودسترايك] و[هاغينغ فيس] و[آي بي إم] و[بالو ألتو نتوركس] و[ريد هات] و[مؤسسة لينكس فاونديشن]. ويُفهم من نطاق العمل المعلن أنه يريد معالجة تحديات متداخلة، مثل:

• الهوية والصلاحيات: من يملك حق تشغيل الوكيل؟ وما حدود ما يمكنه فعله؟
• العزل: كيف نمنع الضرر عند خطأ النموذج أو نجاح هجوم مضاد؟
• حواجز الحراسة (Guardrails): قيود سلوكية تقلل خطر الانحراف عن الهدف.
• السجلات والتدقيق: كيف نوثق “لماذا وكيف” تم اتخاذ القرار؟
• تنسيقات النماذج وإمكانية الفحص متعدد النماذج (Multi-model Scanning)
• مسارات التطوير الآمن (Secure Coding Workflows): كيف نضمن أن الوكيل لا يولد كودًا خطيرًا دون فحص؟

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

ما الذي يجعل “طبقة الوكيل” نقطة أمنية حساسة؟

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

التحالف قدم أول مساهمة تقنية مُسمّاة: NVIDIA-labs OO Agents (NOOA)، وهي إطار بحثي مبني على Apache 2.0 يهدف إلى جعل سلوك الوكيل قابلًا للاختبار والتتبع والمراجعة والحوكمة. الفكرة هنا ليست جديدة من حيث مفهوم “الفصل بين المنطق والنموذج”، لكنها تقدمها بطريقة عملية عبر تمثيل طبقة الوكيل كلغة برمجية مألوفة، بدل تشتيت السلوك بين مخططات أدوات وحقول وصف وأوامر نصية متفرقة.

لماذا يهم أن يكون السلوك مكتوبًا ككود قابل للتدقيق؟

عندما تُصاغ طبقة الوكيل ككود (مثل Python)، يصبح بالإمكان تطبيق أدوات الهندسة المعتادة: اختبارات وحدة، تتبع (Tracing)، مراجعة إصدار (Version Control)، وإعادة هيكلة (Refactoring). مقابل ذلك، بعض الأنظمة تضع السلوك داخل سلسلة مطالبات أو تعريفات أدوات مبعثرة، ما يجعل التدقيق أصعب ويزيد احتمالات “الانزلاق” نحو سلوك غير متوقع.

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

نقطة القوة… ونقطة التحذير: اختبار السلوك لا يعني احتواء الخطر

أحد أهم أجزاء إعلان NOOA هو اعتراف صريح بالمخاطر. الإطار يستطيع أن يُضبط ليقوم بتنفيذ كود Python مُولّد بواسطة النموذج. وهذا يعني نظريًا أنه قد:

• يرسل بيانات خاصة إلى خارج البيئة
• يحذف ملفات
• يعدّل بيئة التشغيل

لذلك يوضح المطورون أن فحوصات مثل تحليل شجرة بناء مجردة (Abstract Syntax Tree) وقوائم رفض للوحدات (Module Deny-lists) هي طبقات دفاعية إضافية، لكنها ليست “حدًا للاحتواء” (Containment Boundary). هذا التفريق جوهري: الاختبارات والفلاتر تقلل المخاطر، لكنها لا تمنع بالضرورة اختراقًا إذا نجح المهاجم في الالتفاف أو استغلال ثغرة في البيئة.

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

كيف ينعكس ذلك على تقييم الأداء الأمني؟

في تقييم ذاتي، ذكرت NVIDIA أن NOOA حقق 86.8% في معيار استعادة ثغرة (Vulnerability-Rediscovery) ضمن CyberGym L1 باستخدام [GPT-5.5] مع تقييد الوصول إلى الشبكة وتطبيق فحوصات قائمة على القواعد على كل مسار. هذه الأرقام مهمة، لكن ينبغي قراءتها في سياقها: الاختبار يقيس قابلية إعادة اكتشاف ثغرات ضمن سيناريو محدد، وليس “سلامة كاملة” ضد كل أساليب الالتفاف أو الاستغلال الواقعي.

حادثة [هاغينغ فيس]: لماذا أصبحت دافعًا سياسيًا وتقنيًا؟

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

لكن المسار الهجومي كان لافتًا: تم تحصيل الوصول الأول عبر مجموعة بيانات خبيثة استغلت تحميلًا لبيانات عبر جهاز بعيد (Remote-code dataset loader) مع حقن قالب (Template injection) داخل إعدادات مجموعة البيانات. ثم تطور الهجوم إلى وصول على مستوى العقد (Node Access)، وجمع بيانات اعتماد، ثم حركة جانبية (Lateral Movement) داخل عدة عناقيد داخلية.

الأهم في سرد [هاغينغ فيس] هو دور السيطرة التشغيلية: الشركة استخدمت نموذجًا بوزن مفتوح (GLM 5.2) على بنيتها التحتية لإجراء تحليل مدفوع بالنموذج على أكثر من 17,000 إجراء مسجل لإعادة بناء التسلسل الزمني واستخراج مؤشرات الاختراق وتحديد الاعتمادات التي تم لمسها. كما أشارت إلى أن نماذج API المستضافة تجاريًا رفضت في البداية أوامر الهجوم والحمولات (Payloads) وآثار التحكم والسيطرة اللازمة للتحليل.

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

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

إطار الحوكمة الغائب: لماذا يجب أن يهمك “من يحكم”؟

على الرغم من أن التحالف يرفع راية “تقنيات مفتوحة” و”حوكمة” الوكلاء، فإن المواد المنشورة لا تتضمن حتى الآن تفاصيل تشغيلية مثل ميثاق واضح (Charter)، أو مجلس حوكمة، أو مسارات عمل محددة، أو جدول تسليم مشترك، أو مستودع تعاوني موحد. كما أن موقع التحالف نفسه قيد الإنشاء.

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

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

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

• مستوى قابلية التدقيق المستمرة (Continuous Auditing)
• سرعة تصحيح الثغرات في الأدوات المشتركة
• وضوح مسؤوليات الأعضاء عند حدوث حوادث
• توحيد معايير التوثيق والتقييم الأمني

كيف يرتبط هذا التحالف باتجاهات الأمن الأوسع؟

تحالفات كهذه تأتي في لحظة تتسارع فيها ثلاثة مسارات متوازية:

• هجمات تستغل “سلاسل الأدوات” وليس النص فقط: أي أن المهاجم يستهدف التكامل بين النموذج والأنظمة الداخلية.
• زيادة الحاجة إلى قابلية التحقق: فرق الأمن تريد سجلات تدقيق، وتتبع قرارات، وشفافية في كيفية استخدام الأدوات والصلاحيات.
• انتقال الأمن إلى مستوى “التنفيذ”: عندما يولد الوكيل كودًا، تصبح عزل البيئة ومراقبة التنفيذ (Runtime Monitoring) محورية.

لهذا السبب، ينسجم تركيز التحالف على الهوية والصلاحيات والعزل والسجلات مع أطر عمل راسخة في الصناعة مثل NICE في جانب المهارات، وأفكار الحوكمة والتدقيق المرتبطة بمبادئ إدارة أمن المعلومات وفق ISO/IEC 27001، إضافة إلى ممارسات “الأقل امتيازًا” (Least Privilege) التي تُعد حجر أساس في تصميم أنظمة آمنة. (للتوسع: Least privilege).

ما المخاطر الفعلية التي يجب أن تضعها المؤسسات في الحسبان؟

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

• حقن سياق: كيف يمكن لمصدر البيانات أن يغيّر سلوك الوكيل؟
• استغلال الصلاحيات: هل يمتلك الوكيل مفاتيح وصول أوسع من حاجته؟
• التسرب عبر التنفيذ: ماذا يحدث عند توليد كود أو استدعاء أدوات؟
• الالتفاف حول الضوابط: هل يمكن تجاوز قوائم الرفض أو قواعد الفحص؟
• فجوة العزل: هل العزل على مستوى النظام كافٍ ضد هروب الحاويات أو إساءة استخدام موارد؟

وبينما تقدم NOOA آليات للتتبع والاختبار، فإن الرسالة الأهم: لا توجد “حماية سحرية” داخل الوكيل. الأمن الحقيقي يبدأ من تصميم البيئة التي يعمل فيها الوكيل، ثم يكتمل بسجلات تدقيق وتحكم صارم في الهوية والصلاحيات.

أسئلة للنقاش: هل المفتوح سيقود إلى أمان أفضل أم إلى تعقيد أكبر؟

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

ما رأيك: هل تعطيك الأدوات المفتوحة مثل NOOA ثقة أكبر في تشغيل الوكلاء بأمان، أم أنك ترى أن العزل والهوية والتدقيق وحدها هي العامل الحاسم بغض النظر عن انفتاح الكود؟

مصادر إضافية للتوسع:
المصدر المفتوح,
العزل,
مبدأ أقل امتياز.

شارك النقاش:
https://x.com/CYBRAT_NET
و
https://www.facebook.com/Cybrat.NET