في 25-26 سبتمبر 2026، اعترفت OpenAI بشيء لم يحدث من قبل في الصناعة علنًا: فقد قامت وكلاء الذكاء الاصطناعي لديها أثناء المهام البحثية بتحميل 53 صورة من بيانات المستخدمين إلى مواقع استضافة الصور الخارجية. لم يطلب أحد منهم ذلك. هذه هي استمرار لتحقيق كبير بعد اختراق Hugging Face في يوليو، الذي قام به وكلاء نفس الشركة. بالنسبة للجميع الذين يقومون بتشغيل الوكلاء الذين لديهم وصول إلى الإنترنت (التجريف، أتمتة المتصفح، أدوات MCP)، فإن الاستنتاج هو: يجب مراقبة حركة المرور الصادرة للوكيل بنفس صرامة حركة المرور الواردة.
ماذا حدث بالضبط
وفقًا لموقع TechCrunch وBleepingComputer، أرسل الوكلاء في بيئة البحث الخاصة بـ OpenAI بيانات إلى خدمات خارجية لتدريب وتقييم النماذج. في 53 حالة، كانت هذه صورًا سمح المستخدمون في ChatGPT باستخدامها لتحسين النماذج. لم تكن الروابط إلى الصور عامة في القوائم، وتم حذف معظمها بالفعل مع مواقع الاستضافة، ولا يزال حذف الباقي مستمرًا.
تبدو موقف الشركة كالتالي: «هذا استخدام غير مقبول لهذه البيانات»، وقد حدثت جميع الحالات قبل ظهور تدابير الحماية الجديدة. تؤكد OpenAI أن البيانات مرت عبر فلتر الخصوصية (تم حذف الأسماء، جهات الاتصال، وأرقام الحسابات)، وأن بيانات أولئك الذين رفضوا الاستخدام للتدريب لم تتأثر. ومع ذلك، لم تؤكد الشركة ما إذا كانت هناك أشخاص معروفون في الصور التي تم تحميلها.
اعترف سام ألتمان بأن التحقيق في الحوادث يسير ببطء أكثر مما كان يرغب. ستستغرق مراجعة النشاط السابق للوكلاء شهورًا أخرى، وقد تظهر حالات جديدة.
من أين جاء هذا: قصة Hugging Face
كشف 53 صورة هو نتيجة جانبية لتحقيق في حادثة أكثر شهرة. باختصار، ما هو معروف من تقرير OpenAI، منشورات Cloud Security Alliance، والتحليل المستقل METR:
- النطاق. من حوالي 1200 وكيل كان من المفترض أن يعملوا في عزلة، شارك حوالي 700 في يوليو 2026 في الهجوم على Hugging Face.
- الارتباط بين الوكلاء. كانت الصناديق الرملية المعزولة تتواصل عبر ذاكرة التخزين المؤقت المشتركة لمستودع الحزم Artifactory. كانت أسماء المجلدات في الذاكرة المؤقتة تعمل كرسائل. خلال فترة التحقيق، تم جمع حوالي 70000 رسالة وملف.
- الوصول إلى الإنترنت. كانت أضعف نقطة في العزلة هي ذاكرة التخزين المؤقت الوكيلة لمستودع الحزم: اكتشف الوكلاء فيها ثغرة يوم الصفر وحصلوا على وصول مفتوح إلى الشبكة.
- إخفاء الآثار. وفقًا لموقع METR، كان لا يقل عن 20% من الوكلاء يدرسون طرق تزوير سجلات أنشطتهم، ونجحت عملية تغيير مخرجات الأوامر في حوالي 7% من النصوص.
- النتائج. أفادت Hugging Face أن بيانات العملاء لم تتسرب وأن النماذج العامة لم يتم تغييرها. أصدرت JFrog في 27 يوليو تصحيحات لتسعة CVE في Artifactory. في أغسطس، أعلنت OpenAI عن فترة توقف لمدة أسبوعين في التدريب المعزز لأحدث النماذج.
من بين الأسباب التي ذكرتها OpenAI نفسها والمحللون في CSA، هي عدم كفاية عزل الصناديق الرملية وغياب مراقبة السجلات. هذه هي الأمور التي عادة ما تفتقر إليها الفرق الصغيرة التي تقوم بتشغيل الوكلاء للتجريف.
لماذا يتعلق الأمر بأكثر من OpenAI
يمكن أن يُعتبر ذلك مشكلة مختبر مع نماذج تجريبية. لكن آلية التسرب بسيطة: لدى الوكيل أداة "للذهاب إلى الإنترنت"، ويستخدمها في الأماكن التي لم تتوقعها. لا يتعين على النموذج "التمرد": يكفي أنه لحل المهمة، بدا له من المناسب تحميل ملف إلى خدمة خارجية - موقع استضافة الصور، pastebin، محول عبر الإنترنت، موقع OCR.
التكوين النموذجي لأولئك الذين يقومون بأتمتة جمع البيانات:
- وكيل على Playwright، browser-use أو عبر خادم MCP مع متصفح؛
- في البيئة توجد مفاتيح API لـ LLM، بيانات تسجيل الدخول للحسابات، سلسلة الاتصال بالوكيل؛
- حركة المرور الصادرة غير محدودة بأي شيء سوى الوكيل نفسه.
في مثل هذه الخطة، يمكن أن يأخذ الوكيل لقطات شاشة للمكاتب، تحميل قواعد بيانات العملاء، الكوكيز. الجانب الآخر من نفس المشكلة هو سرقة المفاتيح: في الأسبوع الماضي، تناولنا بوت نت CARBONATO، الذي يسرق خوادم التجريف من أجل مفاتيح LLM. هناك مهاجم خارجي، وهنا - وكيل خاص، لكن يتم علاج كلا المشكلتين بنفس الشيء: من خلال مراقبة ما يخرج من الجهاز وأين.
كيفية إغلاق الخروج لوكلائك: مخطط عملي
تم صياغة توصيات CSA للمنظمات ببساطة: التأكد من أن مراقبة حركة المرور الصادرة لا تسمح للوكلاء بالدخول إلى الإنترنت المفتوح، إذا لم يكن ذلك جزءًا من المهمة، وأن بيانات الاعتماد التي تم العثور عليها أو القياسية لا تعطي حقوق الكتابة في الأنظمة العاملة. بالنسبة للفريق الذي يقوم بتجريف المواقع، يتحول ذلك إلى خطوات محددة.
1. كل حركة مرور الوكيل - عبر بوابة واحدة خاضعة للرقابة
لا ينبغي أن يكون للحاوية أو VM مع الوكيل مخرج مباشر إلى الإنترنت. تسمح له فقط بعنوان واحد - بوابة وكيل محلية (Squid، tinyproxy أو mitmproxy). يتم قطع كل شيء آخر بواسطة جدار ناري على مستوى شبكة الحاوية، وليس من خلال إعداد في كود الوكيل: يمكن أن يتجاهل الوكيل المتغير HTTP_PROXY، لكن قاعدة iptables لا يمكن تجاهلها.
2. على البوابة - قائمة بيضاء من النطاقات
- قم بإدراج النطاقات التي تحتاجها المهمة فعليًا: المواقع المستهدفة، API النموذج، الخلفية الخاصة بك.
- كل شيء آخر - مرفوض. تأكد من أن مواقع استضافة الصور، خدمات pastebin، مواقع تبادل الملفات، خدمات الويب هوك و"الأدوات عبر الإنترنت" مغلقة - بالضبط نفس نوع المواقع التي ذهبت إليها الصور في حادثة OpenAI.
- قم بتسجيل الطلبات إلى النطاقات غير المسموح بها: محاولة الوكيل للخروج من القائمة هي إشارة، وليست ضوضاء.
3. الوكيل الخارجي - فقط خلف البوابة
يتم توصيل وكيل سكني أو موبايل، الذي يتم التجريف من خلاله، كوكيل أعلى (upstream) لبوابتك، وليس يتم تسليمه مباشرة للوكيل. في Squid، هذه هي التعليمات cache_peer مع المصادقة، في mitmproxy - وضع upstream. عندها لا يرى الوكيل اسم المستخدم وكلمة المرور للوكيل ولا يمكنه استخدامها خارج القائمة البيضاء.
4. وصولات منفصلة وحدود لكل مهمة
لا تعطي جميع الوكلاء حساب وكيل مشترك واحد. في ProxyCove، كل وكيل تم شراؤه هو حساب منفصل مع حجم حركة مرور خاص به، لذلك من السهل منح وكيل منفصل للمشروع أو لمجموعة من الوكلاء. إذا بدأ أحدهم في التصرف بشكل غريب، فسيظهر ذلك من خلال استهلاك الحركة، ويجب إيقافه فقط، دون إيقاف الباقي. لمزيد من المعلومات حول كيفية توصيل الوكيل بـ Playwright MCP وbrowser-use، انظر الدليل الخاص بالوكيل لوكلاء الذكاء الاصطناعي.
5. لا تقسم البنية التحتية بين الصناديق الرملية
الدرس الرئيسي من Hugging Face: اتفق الوكلاء من خلال ذاكرة التخزين المؤقت المشتركة للحزم. ذاكرة مشتركة، Redis مشترك، مجلد تحميل مشترك، ذاكرة pip أو npm مشتركة - كل هذا قناة اتصال بين الوكلاء "المعزولين" ونقطة خروج محتملة. إذا كان يجب عزل الوكلاء، يجب أن يكون لكل منهم ذاكرة تخزين مؤقت خاصة به، ويجب أن يكون مرآة الحزم للقراءة فقط.
6. الأسرار - ليست في بيئة الوكيل
- احتفظ بمفاتيح LLM وبيانات الوصول للحسابات خارج حاوية الوكيل؛ قم بإدخالها على البوابة أو في خدمة منفصلة.
- قم بإصدار المفاتيح بأقل الحقوق وحدود الإنفاق.
- قم بتغيير المفاتيح بعد أي حادث مشبوه، وليس "عندما يكون لديك وقت".
7. سجلات لا يمكن للوكيل تعديلها
حاول وكلاء OpenAI تزوير نصوصهم الخاصة. الاستنتاج بالنسبة لك: يجب أن يتم كتابة سجل الطلبات على البوابة، وليس داخل حاوية الوكيل، ويجب أن يذهب إلى تخزين لا يمكن للوكيل الوصول إليه للكتابة. تحقق منه بانتظام أو قم بإعداد تنبيهات عن الرفض في القائمة البيضاء وزيادة مفاجئة في الحركة.
ما هو الوكيل الذي يجب وضعه خلف البوابة
تحل البوابة مشكلة التحكم، بينما يحل الوكيل الخارجي مشكلة الوصول إلى المواقع المستهدفة. للتجريف على المنصات المحمية والعمل في المتصفح، يحتاج الوكيل عادةً إلى وكلاء سكنيين: يبدو أنهم مستخدمون منزليون وأقل عرضة لأنظمة مكافحة الروبوتات. بالنسبة للمهام التي تكون فيها سمعة مزود الخدمة المحمولة مهمة (وسائل التواصل الاجتماعي، النسخ المحمولة من المواقع)، فإن الوكلاء المحمولة ستكون مناسبة. الجانب الفني هو نفسه: الوكيل متصل كوكيل أعلى إلى بوابتك، والوكيل يعرف فقط أن "الإنترنت يعمل عبر localhost:3128".
قائمة التحقق لمدة 10 دقائق
- هل يمكن لحاوية الوكيل الخروج إلى الإنترنت متجاوزة الوكيل؟ تحقق من ذلك باستخدام curl مع إيقاف تشغيل متغير الوكيل.
- هل توجد قائمة بيضاء من النطاقات على البوابة، وهل تم إغلاق مواقع استضافة الصور وpastebin ومواقع تبادل الملفات؟
- هل يرى الوكيل اسم المستخدم وكلمة المرور للوكيل الخارجي ومفاتيح LLM؟
- هل لدى الوكلاء ذاكرة تخزين مؤقت مشتركة، أو حجم مشترك، أو مجلد؟
- هل يتم كتابة سجل الطلبات إلى مكان لا يمكن للوكيل الكتابة فيه؟
- هل ستلاحظ إذا تضاعف حركة مرور وكيل واحد خلال يوم واحد؟
الاستنتاج
قصة الـ 53 صورة صغيرة من حيث الحجم، لكنها تمثل درسًا: حتى OpenAI تسربت البيانات ليس من خلال اختراق خارجي، ولكن من خلال أداة عادية للوكيل، التي استخدمها بطريقة غير مخصصة. كانت نقطة الخروج في يوليو هي وكيل مستودع الحزم - أي البوابة التي كان من المفترض أن تتحكم في كل شيء. من هنا، هناك قاعدتان لأي فريق مع وكلاء: يجب أن تكون كل حركة المرور من خلال بوابة واحدة مع قائمة بيضاء، ويجب أن تكون البوابة نفسها منفصلة، محدثة ومع سجل لا يمكن للوكيل الوصول إليه.