يكلف الوصول إلى نماذج AI مالا، ويفضل بعض المهاجمين أن يدفع شخص آخر. يتناول تقرير Financial Times في 26 سبتمبر سرقة حسابات وخوادم لاستخدامها في أنشطة AI. ويصف بحث أسبق لفريق استخبارات التهديدات في Google الأساس التقني للظاهرة: سرقة بيانات الوصول واستغلال بنية المؤسسات لتشغيل أحمال حوسبة دون تصريح.
تسمى الظاهرة أحيانا LLM-jacking. ولا تقتصر على الاستيلاء على محادثة في روبوت دردشة: فقد يتيح مفتاح API أو تصريح سحابي استخدام حصة مدفوعة، وأحيانا موارد حوسبة لم تقصد المؤسسة تشغيلها لذلك الطرف أصلا.
الحساب مجرد طريق واحد للدخول
يصف تقرير Google، المنشور في وقت سابق من سبتمبر، طلبا على بيانات الوصول لخدمات AI ومحاولات سرقة ملفات إعداد أدوات التطوير. وقد تحتوي هذه الملفات على مفاتيح أو عناوين خدمات تستخدمها مساعدات البرمجة.
بحسب الباحثين، لا يبحث المهاجمون فقط عن كلمة مرور المستخدم في المتصفح. بل يهتمون أيضا بكيفية اتصال أداة العمل بالنموذج، والحساب الذي يتحمل الفاتورة، والصلاحيات الممنوحة لها.
من المهم التمييز بين تاريخي النشر: مقال Financial Times هو التقرير الجديد؛ وبحث Google مصدر الخلفية للوصف التقني. ولا ينبغي تقديم نتائج البحث الأقدم وكأنها كلها كشفت للمرة الأولى في نهاية الأسبوع.
الاستخدام غير المصرح به قد يبدو عملا عاديا
بالنسبة إلى صاحب الحساب، قد تكون العلامة الأولى حصة مستنفدة أو رسوما غير معتادة أو نشاطا لم يبدأه. وجود رسم كهذا وحده لا يثبت اختراقا، لكنه يبرر فحص سجل الاستخدام وبيانات الوصول النشطة.
يتيح مفتاح API صالح للبرمجيات التعريف بنفسها لدى خدمة. وإذا انكشف، فلا يؤدي تغيير كلمة مرور الدخول وحده بالضرورة إلى إبطاله. يجب فحص المفتاح نفسه والصلاحيات المرتبطة به.
ما الذي يستحسن فحصه في المؤسسة
يوصى بفصل المفاتيح بين الأنظمة، ومنح كل منها الصلاحيات اللازمة فقط، وضبط تنبيهات الاستخدام والميزانية حيث تتيح الخدمة ذلك. ويجب إلغاء المفتاح المكشوف واستبداله، وليس مجرد حذفه من المستند الذي ظهر فيه.
ويستحسن توسيع الفحص ليشمل مستودعات الشفرة وبيئات التطوير. عندما يصبح AI جزءا من أدوات العمل، تصبح بيانات الوصول إليه أصلا يجب إدارته كسائر أسرار المؤسسة. تبدأ الحماية بتحديد من يستطيع استخدام المورد، وليس فقط من يحق له فتح واجهة الدردشة.