بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
واحد من كل ثلاثة أوامر خطيرة يصدرها وكيل ذكاء اصطناعي مارٌّ في حضور بشري مباشر — لا تُكتشف. هذا ما كشفت عنه تجربة تفاعلية نشرها المطوّر أليكس واوترز على شكل لعبة متصفح، حيث يلعب المستخدم دور “الإنسان في الحلقة” الذي يوافق أو يرفض الأوامر الصادرة عن وكيل برمجي — بعضها روتيني كـ git status، وبعضها مصمَّم لسرقة بيانات الاعتماد. وبعد تحليل أكثر من 40,000 جلسة و409,000 قرار فردي، كانت النتائج مقلقة.
متوسط دقة اللاعبين في رصد التهديدات بلغ 66.3% فقط (وفقاً للدراسة)، بمعنى أن الإنسان المكلَّف بمراجعة قرارات الوكيل أخطأ في تحديد التهديدات بنسبة ثلث المرات تقريباً. وانتهت 32.9% من الجلسات بنتيجة سلبية: العقوبات الناجمة عن الموافقة على أوامر خطيرة أو رفض أوامر آمنة فاقت كل ما أصابه اللاعب. في المقابل، نجح 35.2% من اللاعبين في اكتشاف كل التهديدات، لكن 20.8% فقط منهم فعلوا ذلك دون أن يُفرطوا في رفض الأوامر الآمنة. أما 7% فقد وافقوا على كل شيء دون استثناء.
الأرقام تصبح أكثر إثارة حين تُصنَّف التهديدات حسب نوعها. فالأوامر التدميرية الصريحة كـ rm -rf / وchmod -R 777 / لم تُفوَّت إلا بنسبة 11.7%، وهي الفئة الأفضل اكتشافاً. لكن حقن جداول crontab واختراق إعدادات git أُفلتا في 23.8% من الحالات. أما أوامر استخراج البيانات والتنفيذ غير المباشر — كالطلبات الخفية لـ APIs مجهولة أو الحزم المزيفة — فقفزت نسبة إفلاتها إلى 33.4%. والأسوأ كانت انتهاكات النطاق كـ cat ~/.aws/credentials وcat ~/.kube/config، إذ أفلتت في 35% من الأحيان. الأوامر التي تسرق بياناتك الأكثر حساسية هي نفسها الأقل اكتشافاً.
النقطة العمياء الأخطر في التجربة كانت أوامر npm run. الأمر npm run analyze وحده وافق عليه 64.7% من اللاعبين رغم أن سجل الوكيل كان يُظهر صراحةً أن السكريبت يُرسل البيانات إلى خادم خارجي عبر curl. الأمر npm run setup أُفلت في 48% من الحالات، وnpm run deploy في 44.9%. مجتمعةً، فُوِّتت هذه الأوامر الثلاثة بنسبة 52.5% مقارنة بـ28.4% لسائر أنواع هجمات الاستخراج — أي أن إخفاء الحمولة الخبيثة خلف اسم سكريبت مألوف يُضاعف معدل نجاحها تقريباً، حتى حين تكون مكشوفة أمام المستخدم.
هذه النتيجة تعكس مشكلة بنيوية أعمق يلخّصها مستخدم HN باسم dns_snek في تعليق لافت: “npm run build = تشغيل أمر shell اعتباطي مكتوب في package.json”. ذلك أن الوكيل يستطيع دون أي موافقة بشرية أن يعدّل package.json ليحتوي على أمر خبيث، أو يزرع كوداً ضاراً في build.js أو حتى داخل node_modules. وبالتالي فإن طلب الموافقة على الأوامر يخلق وهم الأمان لا الأمان الحقيقي، لأن الأوامر التي تبدو بريئة قد تكون مصابة بسبب ملفات عُدِّلت في صمت.
ثمة جانب آخر من المشكلة: ليس فقط ما يُوافَق عليه خطأً، بل ما يُرفض خطأً أيضاً. الأوامر الآمنة رُفضت بمعدلات لافتة: npm config set registry https://npm.internal رُفض في 59% من الحالات رغم أنه لا يفعل سوى تحديد مرآة داخلية، وrm -rf dist/ رُفض بنسبة 45% رغم كونه مسح عادي لمجلد البناء، وkill $(lsof -t -i:3000) رُفض في 43% من المرات. هذه الرفوضات الزائدة تُبطئ الوكيل وتُراكم التعب الإدراكي الذي يدفع المستخدم لاحقاً إلى الموافقة على أشياء لا ينبغي.
وهذا التعب يظهر في البيانات: رسم البيانات الخاص بالتجربة يُظهر أن معدل إفلات التهديدات يرتفع تدريجياً كلما طالت الجلسة. كل مجموعة من اللاعبين تتحسن في البداية خلال أول أوامر قليلة — مرحلة “الإحماء” — ثم تنكفئ العدالة الإدراكية مع اقتراب نهاية الجلسة. أنثروبيك ذاتها نبّهت إلى هذه الظاهرة في سياق Claude Code (وفقاً للمصدر)، واصفةً إياها بـ”تعب الموافقات”: كلما كثرت الموافقات المطلوبة، قلّت الانتباهة لكل منها.
الأمر الوحيد الذي يستحق الإشارة إليه بتمعّن هو cat ~/.zshrc، الذي انقسم عليه اللاعبون تقريباً: وافق عليه 45.9% ورفضه الباقون. وهذا التقسيم منطقي في الواقع، لأن خطورة الأمر تعتمد كلياً على ما يحتويه ملف الإعدادات: مطوّر يُخزّن مفاتيح API في .zshrc يختلف تماماً عن آخر يُبقيه فارغاً من الأسرار. إذا كنت تُصدر متغيرات البيئة الحساسة من ملف منفصل بدلاً من .zshrc مباشرةً، فأنت تُقلّص سطح الهجوم بشكل فعلي.
ما تكشفه هذه التجربة ليس ضعفاً في بشر بعينهم، بل ضعفاً في النموذج كله. المطوّر الذي يجلس أمام تدفق متواصل من أوامر الوكيل — معظمها آمن وروتيني — لا يملك الحافز المعرفي ولا السياق الكافي لتمييز الأمر الخبيث الذي يختبئ خلف اسم سكريبت مألوف. الحل الفعلي يمرّ عبر عزل صلاحيات الوكيل في بيئات محمية (sandboxing)، وفصل بيانات الاعتماد عن ملفات البيئة العامة، لا مجرد الاعتماد على يقظة إنسان مُرهَق أمام شاشة. يمكنك تجربة اللعبة بنفسك لقياس مدى سرعة تراجع انتباهك.
لمن يعمل مع وكلاء الكود، تجدر الإشارة إلى أن أمان هذا الجانب من البنية التحتية لوكلاء الذكاء الاصطناعي يستحق اهتماماً أعمق — وهو ما تناولناه سابقاً في سياق نظام ADR من أوبر لأمن وكلاء الذكاء الاصطناعي المؤسسي.
