لا تثق بوكلاء الذكاء الاصطناعي

28 فبراير 2026 · Gavriel Cohen

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

هذا هو المبدأ الذي بنيت عليه NanoClaw.

لا تثق بالعملية

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

في NanoClaw، عزل الحاويات جزء أساسي من البنية. كل وكيل يعمل في حاويته الخاصة، سواء على Docker أو Apple Container على macOS. الحاويات مؤقتة، تُنشأ جديدة مع كل استدعاء وتُدمّر بعده. يعمل الوكيل كمستخدم غير مميز ولا يرى سوى المجلدات التي تم تركيبها صراحة. حدود الحاوية يفرضها نظام التشغيل.

لا تثق بالوكلاء الآخرين

حتى عند تفعيل صندوق حماية OpenClaw، يتشارك جميع الوكلاء نفس الحاوية. قد يكون لديك وكيل كمساعد شخصي وآخر للعمل، في مجموعات WhatsApp أو قنوات Telegram مختلفة. جميعهم في نفس البيئة، مما يعني أن المعلومات يمكن أن تتسرب بين وكلاء من المفترض أن يصلوا إلى بيانات مختلفة.

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

حاوية مشتركة مساعد شخصي وكيل العمل وكيل مجموعة العائلة نظام ملفات مشترك جميع بيانات الاعتماد متاحة جميع سجلات الجلسات مرئية جميع البيانات المركّبة مشتركة جميع الوكلاء يرون كل شيء حاويات لكل وكيل مساعد شخصي /data/personal جلسة خاصة ro × وكيل العمل /data/work جلسة خاصة rw × وكيل مجموعة العائلة /data/family جلسة خاصة ro الوكلاء معزولون عن بعضهم

حدود الحاوية هي طبقة الأمان الصلبة — لا يمكن للوكيل الهروب منها بغض النظر عن الإعدادات. فوق ذلك، تعمل قائمة السماح للتركيب في ~/.config/nanoclaw/mount-allowlist.json كطبقة إضافية للدفاع المتعمق: وُجدت لمنع المستخدم من تركيب شيء لا ينبغي كشفه عن طريق الخطأ، وليس لمنع الوكيل من الهروب. المسارات الحساسة (.ssh، .gnupg، .aws، .env، private_key، credentials) محظورة افتراضياً. قائمة السماح موجودة خارج مجلد المشروع، لذا لا يمكن لوكيل مخترق تعديل أذوناته الخاصة. كود التطبيق المضيف مركّب للقراءة فقط، لذا لا شيء يفعله الوكيل يمكن أن يبقى بعد تدمير الحاوية.

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

لا تثق بما لا تستطيع قراءته

يحتوي OpenClaw على ما يقرب من نصف مليون سطر من الكود، و53 ملف إعدادات، وأكثر من 70 تبعية. هذا يكسر الفرضية الأساسية لأمان المصادر المفتوحة. يحتوي Chromium على أكثر من 35 مليون سطر، لكنك تثق بعمليات مراجعة Google. معظم مشاريع المصادر المفتوحة تعمل بالعكس: تبقى صغيرة بما يكفي ليتمكن الكثيرون من مراجعتها فعلاً. لم يراجع أحد أسطر OpenClaw الـ 400,000. كُتبت في أسابيع بدون عملية مراجعة مناسبة. التعقيد هو حيث تختبئ الثغرات، وتحليل Microsoft أكد ذلك: مخاطر OpenClaw يمكن أن تظهر من خلال استدعاءات API العادية، لأنه لا يوجد شخص واحد يمكنه رؤية الصورة الكاملة.

مقارنة أسطر الكود: OpenClaw بحوالي 400,000 سطر مقابل NanoClaw بحوالي 3,000 سطر

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

الوظائف الجديدة تأتي من خلال المهارات: تعليمات مع تطبيق مرجعي كامل العمل يدمجه وكيل البرمجة في قاعدة الكود الخاصة بك. تراجع بالضبط ما هو الكود الذي سيُضاف قبل أن يُدرج. وتضيف فقط التكاملات التي تحتاجها فعلاً. كل تثبيت ينتهي كبضعة آلاف من أسطر الكود مصممة حسب متطلبات المالك بالضبط.

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

صمّم على أساس عدم الثقة

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

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

يمكنك قراءة الكود المصدري والنموذج الأمني الكامل لـ NanoClaw؛ كلاهما قصير بما يكفي لقراءته في فترة ما بعد الظهر.