هناك لحظة يعرفها كل مطوّر. تستنسخ مستودعاً، يسألك الوكيل إن كان يستطيع تنفيذ خطوات التثبيت، توافق، وبعد أربعين ثانية تبدأ الآلة ببناء شيء ما. تبدو كأنها تقدّم.
هذا الأسبوع تحوّلت تلك العادة إلى سطح هجوم موثّق. ورقة جديدة للباحثين أدِيش بَغمار وبوشكار ساراف اختبرت اثني عشر سيناريو هجوم ضمن خمس فئات على أدوات وكلاء برمجة إنتاجية تعمل بنماذج متقدمة. والنتيجة صريحة: الوكلاء يقرأون ملفات README وقوائم المتطلبات وملفات Makefile، ثم ينفذون خطوات التثبيت، ولا يتحققون تقريباً من أسماء الحزم أو مصادرها أو إصداراتها قبل ذلك.
ثم نشر BleepingComputer حيلة موازية: ضع ملف AGENTS.md في مجلد التنزيلات، فأي وكيل يمر من هناك يمكن دفعه لتنفيذ كود أو تسليم بيانات اعتماد. لا سلسلة استغلال. لا ثغرة يوم صفر. مجرد ملف نصي يشبه الوثائق.
إذا كان فريقك يعمل بـ Claude Code أو Codex أو Copilot أو Cursor، فهذه مشكلتك الآن، وليست فضولاً مخبرياً.
مراجعة الثلاث ثوانٍ التي لم يعد أحد يقوم بها
قبل الوكلاء، كان خط الدفاع الأخير هو نفاد صبر المطوّر الذي يؤدي أماناً بالخطأ. من يمرّ على README بنظرة سريعة قد يلاحظ رابط سجل غريباً أو اسم حزمة فيه حرف زائد، فيتوقف لحظة.
تلك اللحظة اختفت. الوكيل يقرأ الملف، ويفسّر مواصفات الاعتماديات، وينفّذ التثبيت بصلاحياتك ومتغيرات بيئتك، وغالباً يوافق تلقائياً على أوامر الطرفية لأن السرعة هي الهدف كله.
الورقة منصفة فيما ينجح فيه الوكلاء. اسم حزمة مزيف فجّ مثل "tranformers" يُكتشف في كل مرة تقريباً. الوكلاء جيدون في رؤية الخطأ الواضح.
المشكلة تبدأ حيث يبدو الخطأ معقولاً:
- الخلط في الفواصل. "azurecore" بدل "azure-core". مقنع، وقريب بما يكفي ليمر على نظرة سريعة، ومختلف بما يكفي ليصل إلى حزمة المهاجم.
- تحويل السجل. السجلات المخفية والمصادر غير الموثوقة تُثبّت بلا شرط تقريباً. يلاحظ الباحثان أن جهد المهاجم في اختيار أسماء مقنعة مهدور إلى حد بعيد، لأن قناة المصدر هي التي لا يحرسها الوكلاء.
- إصدارات معروفة الثغرات. حزمة صحيحة اسمياً لكنها متأخرة سنوات عن التحديثات.
النقطة العمياء ليست الذكاء. إنها السلطة. الوكيل يتعامل مع ملف المشروع كتعليمات مشروعة، لأن ملف المشروع يُفترض أن يكون كذلك.
لماذا النموذج ليس الحلقة الأضعف
هنا الجزء الذي يجب أن يغيّر طريقة شرائك لهذه الأدوات ونشرها. النموذج نفسه اكتشف هجوماً عبر أداة وسيطة، وثبّته عبر أداة أخرى. في تجربة مضبوطة تغيّرت فيها الأداة الوسيطة فقط، انتقل هجوم واحد من الاكتشاف في كل المحاولات العشر إلى الاكتشاف في تسع من ثلاثين.
أي أن أمان لحظة التثبيت خاصية لاقتران الأداة بالنموذج، لا لمستوى النموذج في المقاييس. الترقية إلى نموذج "أفضل" ليست ترقية أمنية. الأداة الوسيطة هي ما يضبط استدعاءات الأدوات والصلاحيات والتنفيذ والذاكرة، وهي أيضاً ما لا يُعدّه أحد تقريباً.
ويضع الباحثان رقماً للفجوة نقلاً عن عمل متزامن: الطلبات الخبيثة الصريحة تفشل أمام دفاعات قوية، لكن الحمولة نفسها حين تُغسل داخل مخرجات تطوير عادية تتجاوز التدريب على الرفض في 11.6 إلى 33.5 في المئة من الحالات. النية المخبأة في الوثائق تمر تحت التدريب الذي كان سيرفضها في مواجهة صريحة.
حيلة الاستمرارية: AGENTS.md كموطئ قدم
مع قصة AGENTS.md تصبح الاستراتيجية أوضح. مشكلة خبيثة على GitHub هي طلقة واحدة: حقن، تنفيذ، وربما سرقة رمز وصول قبل أن يلاحظ أحد. أما AGENTS.md القابل للكتابة فهو عقد إيجار.
أظهر باحثون عملوا مع Codex من OpenAI أن التوجيهات التي يكتبها المهاجم في ملف AGENTS.md قابل للكتابة تبقى عبر عدة مراحل آلية، لأن المراحل اللاحقة تعيد استخدام مساحة العمل وتستمر في الوثوق بالملف. وكذلك دُفع وكيل Anthropic عبر مشكلة مُعدّة إلى قراءة ملفات عشوائية وسحب بيانات اعتماد GitHub وAnthropic.
اربط النتيجتين معاً. ملف تعليمات يبقى بعد حدود المراحل، مع وكيل بصلاحيات CI/CD الافتراضية، يعني اختراقاً لا يحتاج إلى ضجيج. خطوط الإنتاج متعددة المراحل تتشارك مساحات العمل. وأصدرت الشركات معالجات. وقد تكون نسختك من تلك الإعدادات الافتراضية لا تزال قائمة.
كيف يبدو ذلك في فريق حقيقي
تخيّل فريق منتج متوسط الحجم في دبي. اثنا عشر مهندساً، ثلاثة مستودعات، وخط CI يشغّل وكيلاً على كل طلب دمج لإصلاح تنسيق الكود وتلخيص التغييرات. الوكيل يحمل رمز وصول بصلاحية كتابة، لأن ذلك كان أسرع طريق لجعله مفيداً.
يفتح مساهم مشكلة ودّية: "البناء يفشل على الفرع الرئيسي، رجاءً نفّذ خطوات CONTRIBUTING لإعادة الإنتاج". الوكيل يمتثل. لا شيء في هذا التسلسل يبدو شاذاً في سجل يعمل فيه الوكلاء بالأوامر طوال اليوم.
لا يلاحظ أحد أحد عشر يوماً. لا لأن الاكتشاف صعب، بل لأن أحداً لم يحدد كيف يبدو "الطبيعي" لوكيل في هذا الخط.
المعالجة مملة، وهذا هو المقصود
وجد الباحثان أن فحصاً حتمياً قبل التثبيت، يتحقق من الاسم والمصدر والإصدار قبل تنفيذ أي كود، يسدّ معظم الفجوة. لا وكيل حالي يطبّقه افتراضياً. لذا إما تبنيه، أو تضع بوابة.
خمسة أمور يمكنك فعلها هذا الأسبوع:
- ضع بوابة قبل التثبيت. قائمة سجلات موثوقة، وفشل عند تشابه الاسم مع حزمة شائعة، ورفض الإصدارات غير المثبتة. خمسة أسطر من السياسة أفضل من توجيه فيه أمل.
- قلّص صلاحيات الرموز. رمز الوكيل يجب ألا يكتب على الفرع الرئيسي، ولا يقرأ الأسرار، ولا يلمس الإنتاج. أقل صلاحية ليست شعاراً، بل احتواء.
- تعامل مع ملفات التعليمات كأنها كود. التغييرات على AGENTS.md وCLAUDE.md و.cursorrules وCONTRIBUTING وملفات سير العمل تمر بمراجعة إلزامية، تماماً كتغيير في وحدة المصادقة.
- اجعل مساحات عمل الوكيل مؤقتة. حاوية جديدة لكل مرحلة. لا شيء قابل للكتابة يبقى لينقل تعليمات إلى الأمام.
- سجّل أفعال الوكيل كهوية. كل أمر، كل ملف يُقرأ، كل وصول إلى بيانات اعتماد، منسوباً إلى الوكيل ومرسلاً إلى مكان ينظر فيه إنسان فعلاً.
الخلاصة لعملائنا
لا شيء في هذا حجة ضد استخدام وكلاء البرمجة. وكلاؤنا ينجزون عملاً حقيقياً كل يوم، ومكسب الإنتاجية ليس وهماً.
إنه حجة لمعاملة الوكيل كزميل جديد يحمل حاسوباً ومفاتيح الإنتاج: مفيد فوراً، وخطير دون إدارة. المحيط تحرّك. لم يعد حدود شبكتك ولا مزوّد النموذج. إنه آخر ملف قرأه وكيلك قبل أن ينفّذ شيئاً.
إذا كنت تنشر وكلاء داخل خط CI، أو لست متأكداً من الصلاحيات التي تحملها اليوم، فهذه محادثة من ساعتين نجريها بانتظام. أحضر خط الإنتاج. ونحن نحضر الحذر.