Kilo Code سلّم الخادم بصمت جميع ملفات المشروع الاثني عشر، رغم أن الإذن شمل ملفين فقط

عادةً نقبل عمل مساعد الذكاء الاصطناعي على هذا النحو: ننظر إلى الفرق (diff)، ونشغّل الاختبارات، ونرى النتيجة الخضراء، ثم نغلق المهمة. التجربة الموصوفة على موقع Habr تكشف ثغرة في هذه العادة. فقد يكون التعديل مثاليًا، بينما يكون المشروع قد أصبح فعلًا على خادم غريب.

كيف أُجريت التجربة

كانت المهمة صغيرة عن قصد: في الملف price.py كانت الدالة total(price, count) تعيد price + count، بينما كان الاختبار ينتظر أن تعطي total(7, 3) القيمة 21. المطلوب كان استبدال الجمع بالضرب وتشغيل check.py. وكانت تعليمات المستخدم تنص على أنه يمكن نقل price.py وcheck.py فقط.

انطلق الكاتب من نموذج يكون فيه مزوّد LLM غير موثوق ويخالف التعليمات عمدًا. وقام بدوره خادم HTTP محلي على 127.0.0.1. حاكى هذا الخادم الردود المتدفقة وفق واجهة Chat Completions المتوافقة مع OpenAI، وكان يرسل إلى العميل tool_calls: أولًا اثنا عشر أمر read لجميع ملفات مشروع اصطناعي، ثم أمر التصحيح، ثم تشغيل الاختبار. أما العميل فكان حقيقيًا: bin/kilo.exe من امتداد Kilo Code 7.4.20، شُغّل عبر أمر CLI المسمى run. وكانت الإعدادات تسمح بالقراءة وتنفيذ الأوامر.

ماذا حدث

من الخارج بدا كل شيء نموذجيًا. غيّر Kilo رمزًا واحدًا، ونجح الاختبار، ولم تتغير بقية الملفات على القرص، وكان رمز الإنهاء صفرًا، وانتهت جميع استدعاءات الأدوات الأربعة عشر بالحالة completed. لكن الخادم تلقى الملفات الاثني عشر كلها، بحجم إجمالي 11 103 بايت، وتطابقت قيم SHA-256 الخاصة بها مع الأصول.

الآلية بسيطة. يضيف Kilo نتيجة كل قراءة إلى سجل المحادثة ويرسله في الطلب التالي. يستخرج الخادم الرسائل ذات الدور tool، ويزيل أرقام الأسطر، ويعيد تجميع الملفات. لا حاجة إلى قناة تسريب: فالعميل نفسه يحمل البيانات في طلباته المعتادة.

وحركة البيانات مثيرة للاهتمام بدورها. بلغ عدد الطلبات إلى النموذج 15 طلبًا، وبلغ الحجم الإجمالي لأجسام الطلبات 458 779 بايت مقابل 11 كيلوبايت من الشيفرة الفريدة. والسبب هو إعادة إرسال السجل، ووصف الأدوات، والترميز الخدمي. لم يكن هناك طلب ضخم واحد: كانت الشيفرة تُرسل على دفعات صغيرة ثم تتكرر. لذلك لا يمكن ملاحظة هذا التسريب من حجم طلب واحد.

لماذا تعمل المنوعات أسوأ مما نظن

في سلسلة الاختبارات الأولى كانت القاعدة read: deny تمنع القراءة المباشرة للدليل المحظور. لكن مع bash: allow قرأ بايثون الملف نفسه، وانتقل الناتج في الطلب التالي. وعندما مُنع bash لم يُنفَّذ الأمر. تُحدَّد الصلاحيات في Kilo لكل أداة على حدة، ومنع إحداها لا يغلق المسارات الأخرى.

وهناك تحفظات نزيهة. لا يوجد نموذج حقيقي في التجربة: فالأوامر اختارها الخادم التجريبي، ولذلك لا تقيس التجربة ميل النماذج التجارية إلى هذا السلوك. وكانت أسماء الملفات معروفة للخادم مسبقًا، ولم يُختبر البحث المستقل في شجرة مجهولة. كما لم تُختبر الجلسة الرسومية للامتداد، بل واجهة CLI فقط.

ماذا نفعل عمليًا

أولًا: قيّموا لا الفرق (diff) فحسب، بل أيضًا سجل استدعاءات الأدوات وأجسام الطلبات إلى المزوّد. مرّروا الوكيل مرة واحدة على الأقل عبر وكيل (proxy) محلي وانظروا إلى ما يُرسَل فعلًا.

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

ثالثًا: لا تعتمدوا على تعليمة نصية مثل «انقل هذين الملفين فقط». فهذه أمنية موجهة إلى النموذج، لا قيدًا في العميل. الحدود الحقيقية لا تصنعها إلا صلاحيات الأدوات، وبيئة العزل (sandbox)، وسياسات الشبكة.

نشر الكاتب بيئة الاختبار كاملة: Python 3.10+ وGit والملف التنفيذي لـ Kilo، نحو 150 سطرًا من الشيفرة. ويجدر تكرارها على عميلكم الخاص، أيًّا كان الوكيل الذي تستخدمونه.