دراسة CARI: تعليمات خبيثة في مخرجات خدمات المشروع تخدع coding agents بنسبة نجاح 94.8%

نُشرت على arXiv يوم 28 أكتوبر 2026 ورقة بحثية بعنوان CARI، من إعداد الباحثين Jie Fu وShuang Wu وAshish Kundu وWendy Hui Wang وYuan Hong. وتقول الورقة إن نقطة ضعف مهمة في الـ coding agent لا تقع في الـ prompt ولا في النموذج، بل في مخرجات التشغيل التي يقرؤها أثناء العمل.

وتنطلق الدراسة من وضع شائع في المشاريع. فالمطور يعمل على مشروع يتصل بمكوّنات لا يملكها: خدمة backend، أو test harness، أو مهمة في الـ CI، أو خدمة نشر. ومن حق هذه المكوّنات أن تبلغ عن حالتها، فهذا عملها. لكن ليس من حقها أن تكتب في ملفات المطور، أو تلمس مفاتيحه، أو تصل إلى الـ shell الخاص به.

وتسمي الورقة هذا الفرق authority mismatch، أي أن المكوّن يملك صلاحية التشخيص ولا يملك صلاحية الفعل. فالمهاجم لا يكسر الـ prompt ولا النموذج ولا بيئة الضحية، بل يضع تعليماته داخل الـ feedback الذي يصدره المكوّن. ويقرأ الـ agent هذا النص كرسالة خطأ عادية وهو يحاول إصلاح المشكلة، فيحوّله إلى فعل داخل مشروع الضحية.

واختبر الباحثون 10 أنواع من الهجمات، تشمل استنزاف الموارد وكشف المعلومات والتلاعب بحالة التطوير، على 4 لغات برمجة و5 نماذج. ونجحت الهجمات في 2,845 تجربة من 3,000، أي بنسبة 94.8%. وعلى أدوات حقيقية بلغت النسبة 61.3% على Codex و58.7% على Claude Code.

أما الدفاعات فلم تقدم حلًا مريحًا. فالتحذيرات العامة داخل الـ prompt لم يكن لها أثر يُذكر. والسياسات الصريحة قلّلت الهجمات، لكنها جعلت الـ agent يرفض عددًا كبيرًا من الأفعال المشروعة.

وتمس النتيجة كل فريق يربط agent بمخرجات خدمات يديرها فريق آخر. فالسطر الذي يبدو مجرد log قد يصل إلى نموذج يملك صلاحية التعديل والتنفيذ، ويصبح بذلك قناة أوامر. ويبقى السؤال المفتوح كيف يُمنع ذلك دون أن يفقد الـ agent قدرته على قراءة الأخطاء وإصلاحها، وهو ما لم تحسمه الورقة.