إضافة opencode-policy توفر 309 قواعد لحماية وكلاء الذكاء الاصطناعي من الحقن والتسرب

تم اقتراح طبقة حماية منفصلة لبيئة opencode تعترض الطلبات الخطرة قبل وصولها إلى النموذج أو تمريرها إلى أدوات shell والملفات. يستخدم المكون الإضافي opencode-policy القواعد الحتمية، وليس فقط موجهات النظام، ويغطي سيناريوهات الهجوم النموذجية على وكلاء الذكاء الاصطناعي: حقن الموجه، قراءة الملفات غير المصرح بها، محاولات استخراج متغيرات البيئة، تحضير تسرب البيانات وتنفيذ الأوامر المريبة. تتضمن النسخة الأساسية 309 قواعد يمكن توسيعها لبنيتك التحتية.

نشأت الفكرة من تجربة مسابقات وكلاء الذكاء الاصطناعي، حيث يتم إعطاء المشاركين عن قصد تعليمات خبيثة. في مثل هذه المهام، يمكن أن يُطلب من الوكلاء نسيان القواعد السابقة وإظهار موجه النظام وقراءة .env و ~/.

ssh أو /proc/self/environ وفك تشفير الحمولات وتنفيذ شيء نيابة عن المستخدم. لهذا السبب وضع مؤلف المكون الإضافي الحماية خارج النموذج نفسه: إذا كان أمر خطير قد وصل بالفعل إلى تنفيذ الأداة، فقد فات الأوان للتفاعل. يتم تحديد الفلتر في وقت أبكر ويفحص رسائل المستخدم وحجج الأدوات.

يتم بناء التكامل في opencode على hook اثنين. يقوم الأول بتحويل الرسائل قبل إرسالها إلى النموذج والبحث عن علامات حقن الموجه في حقول النص، بما فيها text و prompt و command و source.value.

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

حالياً المكون الإضافي لديه 282 قاعدة لاستدعاءات الأداة و 27 قاعدة ضد حقن الموجه. يتم تخزينها في JSON وتعمل كمجموعة من سياسات regex. تقع التوقيعات النموذجية تحت الحجب، مثل "ignore previous instructions" والعلامات المزيفة [developer] و [system] والأوامر printenv و echo $TOKEN والإشارات إلى /run/secrets و /proc/self/environ وكذلك محاولات ترميز البيانات عبر base64 أو xxd أو openssl enc.

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

يتم تثبيت المكون الإضافي بأمر واحد npm install opencode-policy ويتم توصيله عبر تكوين opencode، وبعد ذلك يتم تشغيل الرسائل واستدعاءات الأداة تلقائياً عبر طبقة القواعد قبل التنفيذ. يؤكد المؤلف بشدة أن مجموعة السياسات مفتوحة ويمكن توسيعها لبنيتك التحتية المحددة، والنهج نفسه متوافق مع النماذج المحلية إذا كانت تعمل عبر opencode. هذا يجعل الحل مفيداً ليس فقط للمساعدات السحابية ولكن أيضاً لحلقات الوكلاء الداخلية داخل الشركات.

من المهم بشكل خاص أن المؤلف يعتمد عن قصد على آليات بسيطة وشفافة بدلاً من طبقة LLM أخرى فوق LLM. بالنسبة لبعض التهديدات، الدلالات المعقدة ليست ضرورية حقاً: أسماء الملفات السرية وأوامر إخراج البيئة وقوالب طلبات jailbreak محددة جداً. نهج regex أبسط في المراجعة والتحديث والربط بحالات محددة، وبعد حادثة، يمكن إضافة قاعدة جديدة بشكل حرفي نقطة بنقطة.

هذا التصميم المحافظ مفيد بشكل خاص حيث تكون القابلية للتكرار والاختبارات الحتمية مطلوبة، وليس تقييم المخاطر الاحتمالية. هذا الفلتر بحد ذاته لا يحل محل العزل والقيود على الامتيازات والقوائم البيضاء للأدوات والعزلة الشبكية. لكن بالنسبة لأنظمة الوكلاء التي تعمل مع الأكواد و shell و CI/CD والمستودعات الداخلية والأسرار، فإنها تغلق طبقة دفاع مبكرة مهمة.

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