تجربة على 409 آلاف قرار: البشر يمرّرون ثلث التهديدات

60 ثانية، و409 آلاف قرار

مطوّر يكتب باسم Wirbelwind بنى لعبة متصفح بسيطة بمساعدة Claude (المساعد الذكي من شركة Anthropic). فكرتها أن تجلس مكان الإنسان الذي يوافق على أوامر الوكيل الذكي البرمجي.

أمامك 60 ثانية. تمرّ عليك أوامر طرفية واحدًا تلو الآخر، وعليك أن توافق أو ترفض بأسرع ما يمكن. اللعبة تحذّرك مسبقًا: بعض هذه الأوامر خبيثة.

بعد تحليل 409 آلاف قرار موافقة ورفض، جاءت النتيجة الأساسية: اللاعبون فوّتوا واحدًا من كل ثلاثة تهديدات. أي أن ثلث الأوامر الخطرة مرّت بموافقة بشرية صريحة.

لماذا يهمّك

معظم أدوات البرمجة والأتمتة الجديدة تبيعك الأمان عبر جملة واحدة: لا تقلق، الإنسان يوافق قبل التنفيذ. هذا هو نموذج الإشراف البشري الذي تتكئ عليه شركات كبرى في تسويق وكلائها.

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

وإن كنت تستخدم وكيلًا يكتب شيفرة أو ينفّذ أوامر على جهازك أو على خادم شركتك، فأنت اللاعب في هذه التجربة، لكن بلا شاشة نتائج في النهاية.

مفتاح SSH يوقفهم، وبقية الملفات تمرّ

أوضح نتيجة في التفاصيل هي أن اللاعبين يتعرّفون على الخطر الشهير فقط. أمر قراءة المفتاح الخاص cat ~/.ssh/id_rsa رفضه 82% منهم.

لكن ملفات الإعدادات وبيانات الاعتماد الحساسة الأخرى مرّت بالموافقة في نحو نصف الحالات، وفق تحليل صاحب التجربة.

الدرس هنا ليس أن الناس أغبياء. الدرس أنهم يميّزون الأنماط المحفوظة، لا المخاطر. أي ملف سرّي لا يحمل الشكل الشهير للتهديد يمرّ بسهولة.

الخدعة الأنجح: اجعل الأمر يبدو روتينيًا

أخطر ما في التحليل هو الطريق الذي وصفه صاحب التجربة بأنه الأنجح لأي شيفرة خبيثة: تعديل ملف package.json ثم طلب التشغيل عبر أمر npm عادي.

الأمر npm run analyze حصل على موافقة 65% من اللاعبين. والأهم: الحمولة الخبيثة كانت ظاهرة صراحة في سجل التنفيذ الموجود فوق نافذة الطلب مباشرة.

بعبارة أخرى، الدليل كان معروضًا على الشاشة، ومع ذلك وافق ثلثا اللاعبين. الأمر بدا مألوفًا، فتوقّف التفكير عند شكله لا عند مضمونه.

ليست دراسة محكّمة، وهذا يجب أن يُقال

من الإنصاف وضع النتيجة في حجمها الصحيح. هذه لعبة متصفح نشرها مطوّر فرد على مدونته وعلى Reddit، وليست بحثًا أكاديميًا خضع للمراجعة.

اللاعبون تحت ضغط عدّاد 60 ثانية، والهدف المعلن جمع أكبر عدد من القرارات، وهو ما يدفع للسرعة على حساب التدقيق. كما أن من يلعبون ليسوا عيّنة تمثيلية.

لكن الاتجاه العام يستحق الانتباه. الظروف الحقيقية ليست أفضل بالضرورة: المطوّر المشغول بمهمة أخرى يوافق أسرع من لاعب يعرف أن اللعبة فخّ.

ما الذي يكسره هذا في فكرة الموافقة البشرية؟

نموذج الموافقة البشرية يفترض ثلاثة أشياء: أن الإنسان يقرأ، وأنه يفهم ما يقرأ، وأنه يملك وقتًا للرفض. التجربة تشكّك في الثلاثة معًا.

المشكلة بنيوية أكثر منها فردية. كلما زادت كفاءة الوكيل، زاد عدد الطلبات، وكلما زاد عدد الطلبات انخفضت جودة كل مراجعة على حدة.

وهذا يعيدنا إلى سؤال طرحناه سابقًا في من يدفع حين يخطئ وكيلك الذكي؟: إذا كانت الموافقة البشرية شكلية عمليًا، فهل تصلح أساسًا لتحميل المسؤولية القانونية؟

بالنسبة للمنطقة العربية

الوكلاء البرمجية تنتشر في فرق التطوير العربية بسرعة، لأنها تعوّض نقص الكوادر وتختصر الوقت. الشركات الصغيرة والمتوسطة هي الأكثر اعتمادًا عليها، وهي أيضًا الأقل امتلاكًا لفريق أمن معلومات.

الاستنتاج المباشر من هذه التجربة أن أخطر سيناريو عربي ليس اختراقًا معقدًا، بل مطوّرًا واحدًا يوافق بسرعة على أمر يبدو عاديًا داخل مشروع عميل.

ما يمكن فعله عمليًا اليوم:

• لا تشغّل وكيلًا برمجيًا على جهاز يحتوي مفاتيح دخول لخوادم الإنتاج أو حسابات العملاء.
• افصل بيئة العمل: حاوية أو جهاز افتراضي منفصل للوكيل، بلا صلاحيات على الشبكة الداخلية.
• ضع قائمة رفض تلقائي لأوامر بعينها بدل الاعتماد على انتباه الموظف في كل مرة.
• راجع أي تعديل على ملفات الإعداد مثل package.json بنفس جدية مراجعة الشيفرة.

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

ولا توجد بيانات منشورة عن سلوك المستخدمين العرب تحديدًا في هذه التجربة، فصاحبها لم يفصّل توزيع اللاعبين جغرافيًا.

الخلاصة

تجربة واحدة بلعبة متصفح لا تثبت شيئًا نهائيًا، لكنها تضع إصبعها على فجوة حقيقية: الوكلاء يتحسّنون بسرعة، والإشراف البشري لا يتحسّن معهم.

الحماية الفعّالة لن تأتي من زر موافقة، بل من تقليل ما يستطيع الوكيل الوصول إليه أصلًا. صلاحيات أقل تعني أن الخطأ البشري يبقى خطأ صغيرًا، لا كارثة.