وكيل ذكاء اصطناعي غير خاضع للرقابة ولا للإدارة ولا يمكن إيقافه يتسبب في تسرب بيانات

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

هذه هي الحادثة 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) لا تستطيع الإجابة عن الأسئلة الأساسية المتعلقة بها: كم عدد الوكلاء قيد التشغيل، وما الذي يمكن لكل واحد منهم الوصول إليه فعليًّا، ومن يملكهم، وما هي الأنظمة والبيانات التي يمكنهم الوصول إليها، وما إذا كانت أذوناتهم قد خضعت للمراجعة من قبل. وهذه هي الهويات غير البشرية (NHIs)—وهم يمثل أحد المخاطر المؤسسية الأسرع نموًّا والأقل خضوعًا للرقابة. على عكس المستخدمين البشريين، الذين لا يتعاملون إلا مع عدد محدود من الصلاحيات في كل مرة، يمكن للوكيل تجربة جميع قدرات الوصول المتاحة له، بسرعة وعلى نطاق واسع، بشكل شبه متزامن. كما أن الوكلاء يرثون الأذونات، ويربطونها معًا، ويتصرفون، غالبًا بسرعة تفوق قدرة الإنسان على ملاحظتها، ناهيك عن الموافقة عليها.

تم تصميم نظام إدارة الهوية والوصول (IAM) التقليدي للإجابة على الأسئلة التالية: ما الذي يمكن للمستخدمين الوصول إليه؟ وكيف يتعين عليهم إثبات هويتهم؟ وما هي العلامات التي تشير إلى وجود مخاطر؟.

تفترض IAM أن الشخص يطلب الحصول على حق الوصول، وأن المدير يوافق على ذلك، وأن دورة المراجعة تكتشف أي انحراف. كما أنه لا يوجد نموذج لـ تصعيد صلاحيات الوكيل الذكي—الطريقة التي يربط بها الوكلاء الصلاحيات وبيانات الاعتماد في مسارات وصول لم يقم أي شخص بتوفيرها صراحةً قط. لا تتطابق أي من تلك المراحل بشكل واضح مع وكيل قادر على وراثة بيانات الاعتماد من الخدمات التي يستدعيها والقيام بآلاف الإجراءات المستقلة خلال عطلة نهاية الأسبوع، وهو ما حدث هنا تقريبًا: فقد أعادت Hugging Face لاحقًا بناء أكثر من 17,000 الأحداث المسجلة المتعلقة بالحادث الواحد.

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

هناك ثلاث قدرات يمكن أن تساعد فريق الأمن لديك في مواجهة هذا التحدي:

1. تحتاج فرق الأمن إلى رؤية مستمرة لكل وكيل يعمل في بيئتها، بما في ذلك الوكلاء الذين لم يسجلهم أحد.
2. إنهم بحاجة إلى ضوابط تشغيل تضمن الالتزام بما يمكن لكل وكيل القيام به فعليًّا، مع تدخل بشري في أي قرار ذي تأثير كبير.
3. إنهم بحاجة إلى الحوكمة التي تضمن مراقبة الوصول بشكل مستمر وتتخذ الإجراءات التصحيحية فور ملاحظة أي سلوك غير سليم من جانب أحد الموظفين، وليس خلال دورة التدقيق التالية.

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

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

سيُنظر إلى حادثة «Hugging Face» في المقام الأول على أنها قصة تتعلق بقدرات النموذج. وهي أيضًا قصة تتعلق بالهوية وفشل واضح جدًّا لنموذج «الثقة الصفرية» (Zero Trust): فقد عثرت هوية غير خاضعة للإدارة على باب لم يكن أحد يعلم أنه مفتوح، واخترقته.

كل مؤسسة تستخدم برامج وكيلة اليوم لديها نسخة ما من تلك «الثغرة». والسؤال الذي يجدر طرحه بعد هذا الحادث ليس ما إذا كانت نماذجك آمنة، بل ما إذا كان بإمكانك إنتاج القائمة الكاملة بجميع الموظفين الذين لديهم حق الوصول إلى أنظمتكم في الوقت الحالي, ، وإثبات مصدر أذوناتها، وتوضيح من يتولى مراجعتها.

إذا كانت الإجابة «لا»، فهذا هو المكان الذي يجب أن نبدأ منه. ليس بمواءمة النموذج، بل بالهوية.