amlasandbox: حماية الذكاء الاصطناعي من مخاطر تنفيذ الشفرة عبر بيئة ويب مُتعددة التراكيب تُعدّ محاكاة الشفرة المولدة بواسطة نماذج الذكاء الاصطناعي من أبرز التحديات في تطوير الأطر الذكية (agents)، حيث تعتمد معظم الأطر الشهيرة مثل LangChain وAutoGen وSWE-Agent على تنفيذ الشفرة عبر subprocess أو exec — ما يُشكّل خطراً جسيماً يُعرف بتنفيذ الشفرة العشوائي على الجهاز المضيف. ويشمل هذا النوع من الهجمات هجمات التلاعب بالملفات (prompt injection)، التي يمكن أن تؤدي إلى فقدان السيطرة على النظام بالكامل. لحل هذه المشكلة، أطلقت فرقة amlalabs إصداراً جديداً يُسمى amla-sandbox، وهو بيئة مُandbox مبنية على WebAssembly (WASM) مع دعم لفرض الصلاحيات (capability enforcement)، وتُعدّ بديلاً آمناً وفعّالاً لتشغيل الشفرة المولدة من الذكاء الاصطناعي دون الحاجة إلى إدارة بنى تحتية معقدة مثل Docker أو آلات افتراضية. يتميز amla-sandbox بتصميم أمني متعدد الطبقات: - يعمل داخل بيئة WebAssembly مع واجهة WASI لتقليل واجهات النظام إلى الحد الأدنى. - يوفر عزل الذاكرة تلقائياً بفضل بنية WASM، حيث تكون الذاكرة خطية ومُقيّدة بالحدود. - يعتمد على محرك wasmtime المعروف بالتصميم الآمن والتحقق الرسمي من سلامة الذاكرة. - يُطبّق سياسات صلاحيات دقيقة لكل أداة (tool)، بحيث يُسمح فقط بالوصول إلى الأدوات والمقاييس المحددة مسبقاً. مثلاً، يمكن تقييد عملية إنشاء مدفوعات عبر Stripe بقيود صارمة: - الحد الأقصى للقيمة: 10,000 وحدة عملة - العملة المسموح بها فقط: USD أو EUR - الحد الأقصى لعدد المكالمات: 100 إذا حاول النموذج تنفيذ أمر يتجاوز هذه القيود، يتم رفضه تلقائياً — حتى لو كان الشفرة صحيحة من الناحية اللغوية. يُعدّ هذا النموذج مستوحى من مبادئ الأمن القائم على الصلاحيات (capability-based security) كما هو مطبق في أنظمة مثل seL4، حيث لا تُمنح الصلاحيات تلقائياً، بل تُمنح صراحة. وهذا يُقلل من تأثير هجمات التلاعب بالملفات، حتى في حالات فشل النموذج في التمييز بين التعليمات الآمنة وغير الآمنة. يُعدّ amla-sandbox خياراً مثالياً للتطبيقات التي تعتمد على أدوات محدودة ومحددة، مثل الوكلاء الذكية التي تُستخدم في المهام اليومية، دون الحاجة إلى بيئة تشغيل كاملة أو دعم لوحدات معالجة الرسومات. - لا يحتاج إلى Docker أو VM - يُشغّل بملف واحد يعمل على كل الأنظمة - يُسرّع عملية التنفيذ من خلال دمج مكالمات الأدوات (tool calls) في دورة واحدة، مما يقلل من تكلفة استخدام النموذج (token tax) ومع ذلك، يحتوي على بعض القيود: - لا يدعم البيئة الكاملة لـ Linux أو وحدات مخصصة - لا يدعم GPU - لا يحتوي على حماية من الحلقات اللانهائية (مثل while(true)) — حيث يمكن أن تُعطل النظام إذا كنت بحاجة إلى بيئة افتراضية كاملة مع حالة مستمرة واعتماديات معقدة، فإن أدوات مثل e2b أو Modal تكون أكثر ملاءمة. الرمز المصدري للغة Python مُتاح تحت ترخيص MIT، بينما يُعتبر الملف التنفيذي لـ WASM ملكية خاصة، ويمكن استخدامه مع الحزمة دون إمكانية استخراجه أو إعادة توزيعه. النظام مدعوم بوثائق شاملة، أمثلة عملية، ودعم للتكامل مع أدوات مثل LangGraph، مما يجعله خياراً جذاباً لمن يبحث عن كفاءة أمنية في تطوير الوكلاء الذكية.
تُعدّ بيئة amla-sandbox حلاً مبتكرًا لمشكلة الأمان في الأطر الشائعة لتطوير الوكيل الذكي (Agent Frameworks)، التي تعتمد عادةً على تنفيذ الشيفرة المولدة بواسطة نماذج لغوية كبيرة (LLM) عبر عمليات فرعية أو أوامر تنفيذية مباشرة، مما يُ exposes النظام إلى هجمات استغلال الإدخال (Prompt Injection) وتنفيذ شيفرة عشوائية على الجهاز المستضيف. بخلاف الحلول التقليدية التي تعتمد على عزل باستخدام Docker أو آلات افتراضية، تتطلب هذه الحلول إدارة بنية تحتية معقدة وتشغيل خدمة Docker. تُقدّم amla-sandbox بديلاً أنيقًا وآمنًا عبر استخدام بيئة تنفيذ مُحَصَّنة بـ WebAssembly (WASM) مع واجهة WASI، مما يضمن عزلًا ذا كفاءة عالية دون الحاجة إلى آلة افتراضية أو حاوية Docker. تُنفذ الشيفرة داخل بيئة WASM، حيث يتم فصل الذاكرة بشكل تلقائي عبر التحقق من الحدود (bounds-checking)، مما يمنع أي محاولة للهروب إلى الفضاء الذاكرة للنظام الأساسي. كما أن المحرك المستخدم (wasmtime) مُصمم بنهج الدفاع المتعدد الطبقات، وقد تم التحقق رياضيًا من سلامته في ما يتعلق بالذاكرة. الأهم من ذلك، يُطبّق amla-sandbox نموذج أمان يعتمد على "الصلاحيات" (Capability-Based Security): لا يمكن للوكلاء الوصول إلى أي أداة أو وظيفة إلا إذا تم منحها صلاحية صريحة، مع تحديد قيود محددة لكل صلاحية. على سبيل المثال، يمكن تمكين وصول وظيفة دفع عبر Stripe فقط لقيمة لا تتجاوز 10000 وحدة نقدية، وبعملة محددة (مثل USD أو EUR)، مع حد أقصى لعدد الاستدعاءات. أي محاولة لتجاوز هذه القيود تُرفض تلقائيًا، مما يقلل من تأثير أي هجوم استغلال إدخال. بفضل هذه البنية، يُمكن للوكلاء تنفيذ الشيفرة في وضع "الكود" (code mode) بكفاءة عالية — حيث يُمكن دمج عشرة استدعاءات لأدوات في استدعاء واحد للنموذج، بدلًا من عشرة استدعاءات منفصلة — مع الحفاظ على مستوى عالٍ من الأمان. هذا يُحقق التوازن المثالي بين الكفاءة وحماية النظام. البيئة تدعم نظام ملفات افتراضي (VFS) قابل للتعديل فقط في مجلدات /workspace و/tmp، ولا تسمح بأي اتصال شبكي أو هروب إلى الطرفية (shell escape). كما أن التكامل مع أدوات مثل LangGraph يُسهّل استخدامها ضمن سير عمل الوكيل، مع إمكانية التحكم الدقيق في الصلاحيات لكل أداة. التشغيل الأول يتطلب تجميعًا للوحدة WASM (حوالي 300 مللي ثانية)، لكن التحميل اللاحق يكون سريعًا جدًا (حوالي 0.5 مللي ثانية) إذا تم تخزين النسخة المُسبق تجميعها. وتم تطوير لغة تعريف قيود (Constraint DSL) تُمكّن من تحديد قواعد معقدة على مدخلات الوظائف، مثل التحقق من القيم أو المطابقة النمطية لاسم الأداة. بالرغم من مزاياها، فإن amla-sandbox لا يوفر بيئة تشغيل كاملة مثل نظام لينكس، ولا يدعم المكتبات المخصصة أو الوصول إلى وحدة المعالجة الرسومية (GPU)، كما أن الحماية من الحلقات اللانهائية (مثل while(true){}) محدودة، لأن حدود الخطوات تُحسب فقط عند التوقف (yield) داخل WASM، وليس عند تنفيذ التعليمات في JavaScript. بالتالي، يُعدّ amla-sandbox الحل الأمثل للحالات الشائعة التي تتطلب تنفيذ شيفرة مولدة من نماذج لغوية مع التحكم الدقيق في الأدوات والقيود، دون الحاجة إلى بنية تحتية معقدة. أما إذا كانت الحاجة إلى بيئة افتراضية كاملة مع حالة مستمرة واعتماديات متعددة، فيُنصح باستخدام حلول مثل e2b أو Modal. الكود المكتوب بلغة Python مُتاح بموجب ترخيص MIT، بينما تُعدّ الوحدة WASM ذات ترخيص خاص، وتُستخدم فقط ضمن هذا الحزمة دون إمكانية استخراجها أو إعادة توزيعها.
