النيران الصديقة والعميل المارق: الحدود الأمنية الجديدة لوكلاء البرمجة بالذكاء الاصطناعي

مقدمة

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

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

يعيد هذا المقال تنظيم المناقشة الأصلية حول النيران الصديقة والعميل المارق ليصبح دليلاً أمنيًا عمليًا للفرق التي تستخدم وكلاء البرمجة بالذكاء الاصطناعي في سير العمل التطويري الفعلي.

الحكم الأساسي

الإشارة المشتركة وراء النيران الصديقة والعميل المارق بسيطة: يمكن للسياق غير الموثوق أن يصبح خطيرًا عندما يتعامل معه الوكيل كسلطة.

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

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

لماذا تهم النيران الصديقة

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

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

الدرس المهم ليس الذعر بشأن أدوات الأمان بالذكاء الاصطناعي. بل هو فصل الأدلة عن التفويض.

قد يشرح ملف README كيف يتم اختبار المشروع عادة. لا ينبغي أن يُفوض الوكيل تلقائيًا لتشغيل هذا الاختبار. قد يكون البرنامج النصي التابع جزءًا من المستودع. لا ينبغي أن يصبح موثوقًا تلقائيًا. قد تتضمن حزمة طرف ثالث أمرًا يبدو كفحص أمني عادي. يمكن للوكيل قراءته، لكن التنفيذ يتطلب مستوى أعلى من الثقة.

نمط محفوف بالمخاطر يبدو هكذا:

./security.sh

قد يبدو الأمر نفسه غير ضار، لكن السؤال المهم هو مصدره. هل طلبه المستخدم صراحة؟ هل اقترحه النموذج؟ هل نُسخ من ملف README لطرف ثالث؟ هل كان مضمنًا داخل تعليق مشكلة أو برنامج نصي تابع؟ لا ينبغي أن تحمل هذه المصادر نفس مستوى الثقة.

الدرس الأساسي من العميل المارق

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

منصة يمكن لوكلاء المحادثة فيها تشغيل كتل برمجية داخل بيئة تنفيذ مُدارة.

الدرس المفيد لفرق المنتج والأمن هو أن روبوتات المحادثة ليست مجرد أوامر واستجابات. فقد تتضمن أيضًا بيئات تشغيل، حسابات خدمية، منافذ شبكة خارجة، متغيرات جلسة، سجلات، بنية تحتية مشتركة، وأذونات نشر.

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

نمط الفشل المشترك

حادثتا "النيران الصديقة" و"الوكيل المارق" هما حادثتان مختلفتان، لكنهما تشيران إلى نمط الفشل نفسه: بيئة غير موثوقة تحصل على صلاحيات تشغيلية.

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

لهذا السبب لا يمكن لتصميم الأمن الاعتماد فقط على نموذج دقيق. يمكن للنموذج المساعدة في التفكير في المخاطر، لكن لا ينبغي له الموافقة على استدعاءات أدواته الخطرة فورًا بعد قراءة تعليمات غير موثوقة.

تفصل البنية الأكثر أمانًا بين ثلاث طبقات:

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

البنية الموصى بها

1. عزل مساحة العمل

يجب فتح المستودعات التابعة لجهات خارجية، المشاكل غير المعروفة، تدقيقات التبعيات، أرشيفات العملاء، والحزم التي تم تنزيلها في بيئات مؤقتة. الحاوية أو الآلة الافتراضية هي خيار افتراضي جيد.

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

الخيارات الافتراضية الجيدة تشمل:

• عدم تحميل دليل المستخدم الرئيسي الشخصي
• عدم وجود بيانات اعتماد سحابية طويلة الأمد
• عدم وجود رمز مدير حزم افتراضي
• عدم وجود وصول شبكة خارجة غير مقيد
• مخابئ حزم مؤقتة
• حدود زمنية ومادية صارمة
• تسجيل كامل للأوامر

2. تقسيم سير عمل الوكيل إلى مراحل

لا تدع القراءة والتحرير والتنفيذ يندمجون في تدفق تلقائي واحد. افصل بينهم.

مرحلة القراءة: يمكن للوكيل فحص الملفات، تحديد المخاطر، وإنتاج خطة.

مرحلة التصحيح: يمكن للوكيل إنشاء فرق أو تصحيح، ويفضل دون تشغيل نصوص غير موثوقة.

مرحلة التنفيذ: يمكن للوكيل تشغيل الأوامر المعتمدة فقط ضمن قائمة سماح ضيقة، مع مهلات زمنية وحدود للموارد.

إذا كان الأمر المقترح من ملف README أو تعليق على مشكلة أو نص تبعية أو مستند خارجي، يجب أن تظهر واجهة الموافقة هذا المصدر.

بوضوح. الأمر الذي يقترحه المستودع ليس هو نفسه الأمر الذي يطلبه المستخدم صراحةً.

3. تشغيل الفحص الحتمي قبل حكم النموذج

الوكلاء الذكيون مفيدون للشرح والتصنيف، لكن الأدوات الحتمية يجب أن تعمل أولاً حيثما أمكن.

على سبيل المثال:

• فحص الأسرار قبل أي تنفيذ للأوامر
• فحص الثغرات في التبعيات قبل نصوص التثبيت
• كشف الملفات الثنائية قبل تشغيل أدوات المستودع
• التحليل الثابت قبل تفسير النموذج
• مراجعة فرق ملف القفل قبل تحديث الحزم
• فحص دورة حياة النصوص قبل تثبيت التبعيات

يمكن للوكيل تلخيص النتائج وترتيب أولوياتها. لا ينبغي له استبدال الماسحات الأساسية.

سير العمل للكود من طرف ثالث

بالنسبة للمستودعات غير الموثوقة، الافتراضي الأكثر أمانًا هو الفحص أولاً، وليس التنفيذ.

1. استنساخ المستودع في بيئة نظيفة قابلة للتخلص.
2. تعطيل أدوات بيانات الاعتماد وتجنب إرفاق أسرار المضيف.
3. استخدام ذاكرات تخزين مؤقتة للحزم مؤقتة.
4. تقييد الوصول إلى الدلائل الأصلية.
5. دع الوكيل يقرأ الملفات وينتج خطة مخاطر.
6. مراجعة نصوص دورة الحياة قبل تثبيت التبعيات.
7. اطلب من الوكيل شرح مصدر وهدف كل أمر يريد تشغيله.
8. تشغيل الأوامر المعتمدة فقط مع حدود للوقت والشبكة ونظام الملفات.
9. إرجاع القطع الأثرية المراجعة فقط، مثل التصحيحات والتقارير وملاحظات إعادة الإنتاج.
10. لا تعد ذاكرات التخزين المؤقت للحزم أو الملفات الثنائية المولدة أو سجل الأوامر أو حالة وقت التشغيل من الصندوق الرملي.

قاعدة مفيدة بسيطة: كلما قلت ثقتك في الإدخال، قلّت السلطة التي يجب أن يحصل عليها الوكيل.

كيف يجب على فرق المنتجات تصميم صلاحيات الوكيل الذكي

مفتاح "الوضع الآمن" الفردي لا يكفي. المنتجات الحقيقية تحتاج إلى صلاحيات على مستوى القدرات.

نموذج صلاحيات أفضل يعامل كل قدرة بشكل منفصل:

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

يجب أن تظهر شاشات الموافقة ليس فقط الأمر، بل أيضًا مصدره. يجب تمييز الأمر الذي يأتي من نية المستخدم، أو استنتاج النموذج، أو تعليمات README، أو تكوين CI، أو تعليقات القضايا الخارجية بشكل مختلف.

ماذا يعني هذا لسير عمل NxCode

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

النهج العملي هو تصنيف المهام إلى ثلاث مجموعات:

1. عمل منخفض المخاطر في بيئة موثوقة

المستودعات**
تشمل الأمثلة التنسيق، تحديثات الوثائق، تغييرات طفيفة في واجهة المستخدم، واقتراحات الاختبارات. يمكن لهذه استخدام أتمتة أعلى عندما يكون المستودع والبيئة موثوقين.
2. التحقيق في المدخلات غير الموثوقة
تشمل الأمثلة المستودعات المجهولة، تحديثات التبعيات، تقارير المشكلات الخارجية، والأرشيفات التي رفعها العملاء. يجب تشغيل هذه في بيئات مقيدة وقابلة للتخلص.
3. العمليات المؤثرة على الإنتاج
تشمل الأمثلة النشر، ترحيل قواعد البيانات، تدوير الأسرار، تغييرات البنية التحتية، وتحديثات أذونات CI/CD. تتطلب هذه موافقة بشرية وسجلات أدلة قوية.

هذا التصميم لا يزيل ميزة السرعة التي تتمتع بها وكلاء البرمجة بالذكاء الاصطناعي. بل يحافظ على سرعة الوكيل في الحالات منخفضة المخاطر، ويفرض هيكلية أكبر حيث يكون نطاق الضرر واسعًا.

ملاحظات المصدر

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

الأسئلة الشائعة

ما هو "النيران الصديقة" في أمان وكلاء البرمجة بالذكاء الاصطناعي؟

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

ما هو "الوكيل المارق"؟

"الوكيل المارق" هي مشكلة أمنية موثقة في Dialogflow CX تتضمن تنفيذ شيفرة داخل سير عمل الوكيل. الدرس الأوسع منها هو أن روبوتات الدردشة المدعومة بالذكاء الاصطناعي التي تتمتع بتنفيذ الشيفرة، الوصول إلى الجلسة، وصلاحيات وقت تشغيل السحابة يجب التعامل معها كبرامج إنتاجية، وليس مجرد نصوص محادثة.

لماذا وكلاء البرمجة بالذكاء الاصطناعي عرضة لحقن التعليمات؟

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

هل العزل في بيئة رملية كافٍ لتأمين وكلاء البرمجة بالذكاء الاصطناعي؟

العزل في بيئة رملية مهم، لكن لا ينبغي أن يكون الدفاع الوحيد. الإعداد الآمن يحتاج أيضًا إلى حدود الأذونات، قيود الشبكة، عزل الأسرار، الفحص الحتمي، مصدر الأوامر، وسجلات التدقيق.

هل يجب على وكلاء الذكاء الاصطناعي تشغيل الأوامر من ملفات README؟

ليس تلقائيًا. أوامر README يمكن أن تكون وثائق مفيدة، لكنها تأتي من المستودع قيد الفحص. بالنسبة للمشاريع غير الموثوقة، يجب على الوكيل شرح مصدر الأمر والمخاطرة قبل الموافقة على أي تنفيذ.

كيف يجب على الفرق التعامل مع مستودعات الطرف الثالث باستخدام وكلاء الذكاء الاصطناعي؟

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

ما هي الأذونات التي يجب أن تقدمها منتجات البرمجة بالذكاء الاصطناعي؟

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

الأدوات ذات الصلة

• Claude Code: أداة البرمجة الوكيلة من Anthropic لقراءة وتحرير والعمل مع قواعد الأكواد.
• OpenAI Codex: منصة الوكيل البرمجي من OpenAI مع مفاهيم العزل والموافقة.
• Google Dialogflow CX: منصة العملاء الافتراضيين من Google Cloud، بما في ذلك دفاتر اللعب وإمكانات كتل الأكواد.
• Docker: طريقة شائعة لإنشاء بيئات تطوير واختبار مؤقتة.
• Semgrep: أداة تحليل ثابتة يمكنها فحص الكود المصدري قبل التنفيذ بواسطة الوكيل.
• GitHub CodeQL: محرك تحليل أكواد دلالي مفيد لسير عمل مراجعة الأمان.

الروابط ذات الصلة

• بحث Friendly Fire من AI Now: موجز بحثي حول وكلاء الذكاء الاصطناعي الدفاعيين وخطر تنفيذ الأكواد عن بُعد.
• إفشاء وكيل Varonis المارق: شرح تقني لثغرة الوكيل المارق في Dialogflow CX.
• وثائق أمان Claude Code: الإرشادات الأمنية الرسمية من Anthropic لـ Claude Code.
• وضع Claude Code التلقائي: شرح Anthropic للوضع التلقائي وقرارات الإذن في Claude Code.
• وثائق بيئة OpenAI Codex المعزولة: شرح رسمي لكيفية استخدام Codex لحدود العزل.
• المراجعة التلقائية من OpenAI Codex: وثائق رسمية لسلوك المراجعة التلقائية في Codex.
• كتل أكواد Dialogflow CX: وثائق Google Cloud لكتل أكواد Python في دفاتر لعب Dialogflow CX.

ملخص

يظهر "Friendly Fire" و"Rogue Agent" أن أمان وكيل الذكاء الاصطناعي ليس مجرد مشكلة توافق النموذج. الحدود العملية هي بيئة التشغيل: الملفات، الأوامر، الوصول إلى الشبكة، الأسرار، بيئات التنفيذ، وقابلية المراجعة.

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

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