في الأسبوع الماضي، اقتحم وكيل ذكاء اصطناعي بيئة إنتاجية لم يكن من المفترض أن يتدخل فيها. فقد اكتشف ثغرة أمنية من نوع «يوم صفر»، وربطها ببيانات اعتماد مسروقة، ورفع صلاحياته، وانتقل أفقياً عبر البنية التحتية التابعة لشركة لا يسيطر عليها مشغله. لم يوجهه أي مهاجم. ولم يوافق عليه أي إنسان. كان يسعى لتحقيق نتيجة قياسية.
هذه هي الحادثة OpenAI و Hugging Face تم الكشف عن ذلك هذا الأسبوع. خلال تقييم داخلي لنموذج GPT-5.6 Sol ونموذج ما قبل الإصدار الأكثر قدرة منه، قامت OpenAI بإزالة بعض إجراءات الحماية المتعلقة بـ«الرفض السيبراني» للسماح بإجراء اختبارات أقل تقييدًا.
ذهب النموذج إلى أبعد مما كان متوقعًا بكثير. فقد استغل ثغرة يوم الصفر في وكيل سجل الحزم للهروب من بيئة الحماية الخاصة به، ووجد مسارًا إلى الإنترنت المفتوح، واستنتج أن Hugging Face ربما تستضيف مفتاح الإجابات الخاص بمعيار الأداء الذي كان يخضع للاختبار عليه، وربط بيانات الاعتماد المسروقة باستغلال لتنفيذ التعليمات البرمجية عن بُعد لسرقتها مباشرةً من أنظمة الإنتاج الخاصة بـ Hugging Face. اكتشفت Hugging Face الاختراق واحتوته باستخدام فريقها الأمني ونماذجها الخاصة قبل أن تتواصل معها OpenAI. ولم تكتشف OpenAI الهروب والإجراءات إلا بعد أن تساءلت عن سبب حصول النموذج على درجات عالية جدًا في الاختبار القياسي الذي كان يخضع له.
ووصفت شركة OpenAI هذه الحادثة بأنها “حادث إلكتروني غير مسبوق”. لكن الأمر أكبر من ذلك. إنه لمحة عما سيأتي.
تجاهلوا ثغرة «اليوم صفر» في الوقت الحالي: فسيتم إصلاحها. ما ينبغي أن يقلق كل مسؤول أمن المعلومات هو ما يكشفه هذا الحادث عن كيفية تراكم صلاحيات الوصول لدى العناصر العميلة، وكيف يمكنها اتخاذ إجراءات غير متوقعة لتحقيق هدف ما. فهذه العنصر العميل لم يطلب أبدًا إذنًا من أي شخص للوصول إلى البنية التحتية لشركة «Hugging Face». وعندما طُلب منه تقييم قدراته، قرر أن أفضل طريقة للقيام بذلك هي إيجاد مسار عبر سلسلة من الثغرات الأمنية وبيانات الاعتماد الموروثة. لم يقم أحد بتوفير هذا الوصول. ولم يطلب أحد من العميل شن هجوم. ولم يكن أحد يراقب الوضع في الوقت الفعلي، إلى أن رصدت أنظمة الدفاع الخاصة بـ Hugging Face هذا الاختراق.
كان هذا الحادث أبعد ما يمكن تصوره عن مبادئ «الثقة الصفرية». كما أنه الجزء الذي ينطبق مباشرةً على بيئات المؤسسات التي تعمل باستخدام الوكلاء (agents) في الوقت الحالي. فمعظم المؤسسات التي تنشر أنظمة المساعدة (copilots) وخطوط الإنتاج المستقلة (autonomous pipelines) وسير العمل القائم على الوكلاء (agent-based workflows) لا تستطيع الإجابة عن الأسئلة الأساسية المتعلقة بها: كم عدد الوكلاء قيد التشغيل، وما الذي يمكن لكل واحد منهم الوصول إليه فعليًا، ومن يملكهم، وما هي الأنظمة والبيانات التي يمكنهم الوصول إليها، وما إذا كانت أذوناتهم قد خضعت للمراجعة من قبل. وعلى عكس المستخدمين البشريين، الذين يعملون فقط بعدد محدود من الصلاحيات في كل مرة، يمكن للوكيل تجربة جميع قدرات الوصول الخاصة به، بسرعة وعلى نطاق واسع، بشكل شبه متزامن. كما أن الوكلاء يرثون الأذونات، ويربطونها معًا، ويتصرفون، غالبًا بسرعة تفوق قدرة الإنسان على الملاحظة، ناهيك عن الموافقة.
تم تصميم نظام إدارة الهوية والوصول (IAM) التقليدي للإجابة على الأسئلة التالية: ما الذي يمكن للمستخدمين الوصول إليه؟ وكيف يتعين عليهم إثبات هويتهم؟ وما هي العلامات التي تشير إلى وجود مخاطر؟.
تفترض منظمة IAM أن الشخص يقدم طلبًا للوصول، ويوافق المدير عليه، وتقوم دورة المراجعة باكتشاف أي انحراف. ولا تنطبق أي من هذه المراحل بشكل واضح على وكيل يمكنه أن يرث بيانات الاعتماد من الخدمات التي يستدعيها، ويتخذ آلاف الإجراءات المستقلة خلال عطلة نهاية الأسبوع، وهو ما حدث تقريبًا في هذه الحالة: فقد أعادت Hugging Face لاحقًا بناء أكثر من 17,000 الأحداث المسجلة المتعلقة بالحادث الواحد.
هذا لا يقترب بأي شكل من «نموذج الثقة الصفرية». وسد هذه الفجوة يتطلب أكثر من مجرد تحسين مواءمة النموذج (على الرغم من أن OpenAI محقة في أن ذلك ضروري أيضًا). فهو يتطلب معاملة كل وكيل كهوية منفصلة لها قائمة حقيقية، وضوابط وصول حقيقية، ومساءلة حقيقية — وهي نفس المعايير التي تطبقها فرق الأمن بالفعل على الحسابات البشرية وحسابات الخدمات، وتُطبق بشكل متسق على الحسابات غير البشرية.
هناك ثلاث قدرات يمكن أن تساعد فريق الأمن لديك في مواجهة هذا التحدي:
- تحتاج فرق الأمن إلى رؤية مستمرة لكل وكيل يعمل في بيئتها، بما في ذلك الوكلاء الذين لم يسجلهم أحد.
- إنهم بحاجة إلى ضوابط تشغيل تضمن الالتزام بما يمكن لكل وكيل القيام به فعليًّا، مع تدخل بشري في أي قرار ذي تأثير كبير.
- إنهم بحاجة إلى نظام حوكمة يضمن الوصول بشكل مستمر، ويتخذ الإجراءات التصحيحية فور ظهور أي سلوك غير سليم من جانب أحد الوكلاء، وليس خلال دورة التدقيق التالية.
لا يوجد شيء استثنائي في قائمة الوظائف هذه. فالوكيل الذي لا يرد في قائمة الجرد الخاصة بك لا يمكن إدارته بشكل سليم. والوصول الذي لا يتم فرضه أثناء وقت التشغيل لا يمكن الوثوق به. والنظام الذي يفتقر إلى سجل التدقيق لا يمكن اعتماده.
سيُنظر إلى حادثة «Hugging Face» في المقام الأول على أنها قصة تتعلق بقدرات النموذج. وهي أيضًا قصة تتعلق بالهوية وفشل واضح جدًّا لنموذج «الثقة الصفرية» (Zero Trust): فقد عثرت هوية غير خاضعة للإدارة على باب لم يكن أحد يعلم أنه مفتوح، واخترقته.
كل مؤسسة تستخدم برامج وكيلة اليوم تمتلك نسخة ما من تلك «البوابة». والسؤال الذي يجدر طرحه بعد هذا الحادث ليس ما إذا كانت نماذجكم آمنة، بل ما إذا كان بإمكانكم تقديم قائمة كاملة بجميع البرامج الوكيلة التي تتمتع بحق الوصول إلى أنظمتكم في الوقت الحالي، وإثبات مصدر أذوناتها، وتوضيح من يتولى مراجعتها.
وإذا كانت الإجابة «لا»، فهذا هو المكان الذي يجب أن تبدأ منه.
