Akamai Agent Sandbox: لماذا يعمل كود الوكيل الآن بلا إنترنت افتراضيًا؟

في 27 أكتوبر 2026 أعلنت Akamai عن خدمتين في نسخة تجريبية: Akamai Inference وAkamai Agent Sandbox. الخدمة الثانية هي ما يهمّ المطوّر الذي يبني وكلاء ذكاء اصطناعي، فهي تجيب عن سؤال صار يتكرر في كل فريق: أين يُشغَّل الكود الذي يكتبه الوكيل بنفسه، وكيف نضمن ألا يمدّ يده إلى ما لا يجب؟ الفكرة الأساسية بسيطة وجريئة: كود الوكيل يعمل داخل بيئة WebAssembly مقيَّدة، ولا يملك اتصالاً خارجياً إلا إذا سمحت له أنت.

ما الذي أُعلن بالضبط؟

وفق ما نشرته Akamai وما نقلته Techzine، فإن الخدمة تتيح للوكيل أن يكتب كوداً ويشغّله في بيئة معزولة منفصلة عن بيئة تشغيل الوكيل نفسه. العناصر الرئيسية:

• الوكلاء يعملون على Akamai Functions، أما الكود الذي يولّدونه فيُنفَّذ في عزل مستقل.
• اتصال خارجي محجوب افتراضياً: كل ما على الإنترنت ممنوع إلا ما تسمح به صراحةً.
• حدود للموارد: المعالج والذاكرة والاتصالات الصادرة وصلاحيات النظام.
• السماح بالأدوات وخوادم MCP: يمكنك منح الوكيل مجموعة أدوات ومهارات وخوادم MCP محددة، ولا يفعل إلا ما سمحت به.
• بيئة تشغيل JavaScript أو Python مقيَّدة متداخلة داخل صندوق الوكيل.
• مكوّن مفتوح المصدر من إطار Spin الذي جاء من Fermyon، الشركة التي استحوذت عليها Akamai.

الخدمة الآن في مرحلة بيتا عبر Spin SDK، فلا تبنِ عليها نظام إنتاج حرجاً قبل أن تختبر حدودها بنفسك.

لماذا يحتاج الوكيل إلى صندوق رمل أصلاً؟

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

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

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

لماذا WebAssembly تحديداً؟

هناك ثلاثة مسارات رئيسية لعزل الوكلاء اليوم، وكل منها يناسب حالة مختلفة:

النهج	نقطة القوة	الثمن
الأجهزة الافتراضية الصغيرة (microVM)	عزل قوي ولقطات واستنساخ للحالة	زمن إقلاع وتكلفة أعلى
الحاويات بسياسات صارمة	مألوفة وسهلة النشر	سطح هجوم أكبر من WebAssembly
دوال WebAssembly	إقلاع سريع جداً وصلاحيات صفرية افتراضياً	قيود على المكتبات واللغات المدعومة

نموذج WebAssembly يبدأ من «لا شيء مسموح» ثم تضيف الصلاحيات واحدة واحدة، بعكس الحاوية التي تبدأ بنظام تشغيل كامل ثم تحاول سحب الصلاحيات منه. وهذا يتوافق مع اتجاه أوسع شرحناه في WebAssembly والذكاء الاصطناعي وفي عزل الوكلاء.

كيف تفكر في تصميمك أنت؟

حتى لو لم تستخدم Akamai، فالدرس قابل للتطبيق على أي منصة:

1. افصل مكان التفكير عن مكان التنفيذ

وكيلك يتحدث مع النموذج ويحمل مفاتيح الخدمات، أما الكود الذي يولّده فيجب أن يعمل في مكان لا يرى تلك المفاتيح.

2. اجعل الشبكة قائمة سماح

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

3. ضع سقفاً للموارد

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

4. سجّل ما جرى

مع ازدياد طلب فرق الامتثال على سجلات التدقيق، احتفظ بما نُفّذ ومتى وبأي صلاحيات.

مثال عملي: وكيل يحلل ملف مبيعات

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

في التصميم المعزول يتغير المشهد:

1. يستقبل الوكيل الملف ويمرّره إلى الصندوق كبيانات فقط.
2. يعمل السكربت المولَّد داخل بيئة بلا شبكة ولا مفاتيح ولا نظام ملفات مشترك.
3. تعود النتيجة، وهي الأرقام أو الصورة، إلى الوكيل ثم إلى المستخدم.
4. أي محاولة اتصال خارجي تفشل ويمكن تسجيلها كإشارة إنذار.

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

أين يقع هذا من اتجاه السوق؟

شهد أكتوبر 2026 تركيزاً واضحاً على التحقق والتقييد في أدوات البرمجة بالوكلاء: صناديق رمل محلية في أدوات المطورين، ومدققات قواعد، وسجلات تدقيق، وتسعير قائم على الاستخدام يجعل الفرق تحسب كلفة كل تشغيلة. دخول Akamai بنسخة تعتمد على WebAssembly يعني أن مزوّدي البنية التحتية يتنافسون الآن على «أين يعمل الوكيل بأمان»، لا على «أي نموذج يستخدم» فقط. وهذا في صالح المطوّر، لأن الخيارات تتعدد وتنخفض كلفة الانتقال بينها طالما اعتمدت على معايير مفتوحة مثل MCP.

تحفّظات مهمة

الإعلان تجاري في المقام الأول، والخدمة في بيتا، وأرقام الأداء والأسعار التفصيلية لم تتضح بعد في المصادر العامة. اختبر بنفسك أمرين قبل الاعتماد: هل المكتبات التي يعتمد عليها تحليلك متاحة في بيئة Python المقيَّدة؟ وكيف يتصرف الصندوق عند تجاوز الحدود؟ العزل لا يغني أيضاً عن مراجعة الأدوات التي تمنحها للوكيل، فإذا منحته أداة تكتب في قاعدة بياناتك فقد فتحت باباً لا يغلقه أي صندوق.

أسئلة شائعة

هل يغني صندوق الرمل عن الحماية من حقن الأوامر؟

لا. هو يحدّ من الضرر إذا نجح الحقن، لكن الأفضل الجمع بين تنقية المدخلات وتقليل الصلاحيات والعزل.

هل يمكن للوكيل داخل الصندوق استدعاء أدوات خارجية؟

نعم، لكن فقط الأدوات وخوادم MCP التي منحتها له صراحةً، وبقية الإنترنت محجوبة افتراضياً بحسب Akamai.

هل أستخدم WebAssembly أم microVM؟

إن كان وكيلك يشغّل مقاطع قصيرة لتحليل بيانات فـWebAssembly مناسب وسريع. وإن كان يحتاج نظام تشغيل كاملاً أو أدوات ثقيلة فـmicroVM أقرب إلى حاجتك.

الخلاصة

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

المصادر: Akamai، Techzine، DEV Community