بيئات عزل وكلاء الذكاء الاصطناعي: تنفيذ آمن للكود 2026

كتب وكيل الذكاء الاصطناعي للتو نصًا برمجيًا بلغة Python، والآن يريد تشغيله. قد يثبّت هذا النص الاعتماديات، ويستدعي واجهة برمجية، ويكتب ملفات، ثم ينتهي بسلام. أو قد ينفّذ rm -rf على مجلد مُحمَّل، أو يسرّب متغيرات البيئة لديك، أو يفتح صَدفة عكسية (reverse shell) — إما لأن النموذج تهيّأ له شيء خطير، أو لأن حقن التعليمات (prompt injection) أمره بذلك.

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

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

لماذا لا تكفي الحاويات وحدها

الغريزة الأولى لدى معظم المهندسين هي اللجوء إلى Docker. فهو مألوف، ومنتشر في كل مكان، ويبدو معزولًا. المشكلة أن الحاويات القياسية تتشارك نواة المضيف (host kernel). كل استدعاء نظام (syscall) يصدره كود وكيلك يذهب مباشرة إلى النواة نفسها التي تشغّل أعباء عملك الأخرى.

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

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

مستويات العزل الثلاثة

هناك ثلاثة مستويات عملية للعزل، يقايض كل منها الأداء بحدود أمنية أقوى.

المستوى الأول — الحاويات القياسية (الحد الأدنى)

Docker وcontainerd وما شابهها. توفّر مساحات الأسماء (namespaces) ومجموعات التحكم (cgroups) عزلًا للعمليات والموارد، لكن النواة مشتركة. هذا هو الأرضية لا السقف. استخدمه فقط عندما يكون الكود شبه موثوق أو يكون نطاق الضرر محتوىً فعليًا — مثلًا حاوية مؤقتة بلا شبكة، بلا أسرار، وبنظام ملفات للقراءة فقط.

المستوى الثاني — نواة مساحة المستخدم (gVisor)

يقع gVisor بين عبء العمل والمضيف. يعترض استدعاءات النظام في مساحة المستخدم ويعيد تنفيذ جزء كبير من واجهة النواة بنفسه، فلا يكاد الكود غير الموثوق يتحدث إلى نواة المضيف الحقيقية مباشرة. تحصل على حدود أقوى بكثير من الحاويات بتكلفة أداء متواضعة فقط. تستخدم Modal وعدة منصات أخرى gVisor كطبقة عزل افتراضية، محقّقة بدايات باردة (cold starts) أقل من ثانية.

المستوى الثالث — الآلات الافتراضية الصغيرة (Firecracker وKata Containers)

هذا هو المعيار الذهبي. يحصل كل عبء عمل على نواة ضيف مخصصة تعمل داخل آلة افتراضية خفيفة. لا يمكن لثغرة في نواة الضيف الوصول إلى نواة المضيف، لأنهما نواتان منفصلتان يفصل بينهما حد افتراضية عتادية (hardware virtualization).

إن Firecracker — التقنية نفسها التي تشغّل AWS Lambda — هو الخيار الفعلي السائد. والأرقام هي السبب: إقلاع بارد في أقل من 125 ميلي ثانية، وعبء ذاكرة أقل من 5 ميغابايت لكل آلة افتراضية، وعبء حوسبة أقل من 5 بالمئة مقارنة بالعتاد المباشر. ومع اللقطة والاستعادة (snapshot and restore)، يمكنك توفير بيئة عزل في نحو 28 ميلي ثانية باستعادة صورة ذاكرة مُسخّنة مسبقًا عبر طبقة نسخ-عند-الكتابة. تحصل على عزل بمستوى الآلة الافتراضية بسرعة تقارب سرعة الحاوية.

مقارنة المنصات: من يشغّل ماذا

نادرًا ما تبني فوق Firecracker الخام بنفسك. هناك موجة من المنصات تغلّف الآن هذه التقنيات بحزم تطوير (SDKs) صديقة للوكلاء. إليك مقارنة الخيارات الرئيسية من حيث العزل وزمن البدء البارد — الرقمان الأهم للوكلاء التفاعليين.

تتميّز E2B لأنها بُنيت تحديدًا لمطوّري وكلاء الذكاء الاصطناعي — لا للحوسبة العامة ولا لـ CI/CD. تحصل كل بيئة عزل على نواتها ومساحة أسمائها الشبكية، فلا تصل ثغرة نواة الضيف إلى المضيف، وحزمة التطوير مصمّمة حول سير عمل الوكلاء لا مُعدّلة من أداة نشر.

تتّبع Northflank النهج المعاكس: منصة تطوير كاملة تدعم Firecracker وKata Containers وCloud Hypervisor وgVisor، تتيح لك اختيار المقايضة بين الأمن والأداء لكل عبء عمل. وهذه المرونة مهمة حين يشغّل بعض وكلائك أدوات داخلية موثوقة ويشغّل آخرون كودًا عشوائيًا يقدّمه المستخدم.

ما الذي تفرضه بيئة العزل الآمنة فعلًا

عمق العزل ضروري لكنه غير كافٍ. آلة افتراضية صغيرة بشبكة مفتوحة على مصراعيها ومفاتيح AWS مُحمَّلة بداخلها تظل كارثة في الانتظار. العزل الحقيقي يعني أن بيئة العزل لا يمكنها الوصول إلى عمليات المضيف أو أنظمة ملفاته أو واجهاته الشبكية — ويعني أنك تتحكم بدقة فيما يمكن لبيئة العزل الوصول إليه.

إليك مثالًا بسيطًا بـ E2B يشغّل كود وكيل غير موثوق بحدود محكمة:

from e2b_code_interpreter import Sandbox
 
# كل استدعاء يُشغّل آلة Firecracker افتراضية صغيرة معزولة
with Sandbox.create(timeout=30) as sandbox:
    # كود مُولَّد بواسطة الوكيل — يُعامل على أنه غير موثوق
    execution = sandbox.run_code(agent_generated_code)
 
    if execution.error:
        # التقط الفشل، ولا تكشف أخطاء المضيف الخام للنموذج أبدًا
        handle_error(execution.error)
    else:
        result = execution.results
 
# تُدمَّر بيئة العزل عند الخروج — بلا حالة دائمة، بلا نافذة هروب

البدائيات الدفاعية التي ينبغي طبقها فوق أي بيئة عزل:

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

التسريب الذي لا علاقة له بالكود إطلاقًا

إليك النتيجة التي تعيد صياغة المشكلة كاملةً. وجدت أبحاث من جامعة واشنطن أن 63.4 بالمئة من وكلاء النماذج اللغوية بلا عزل سليم سرّبوا بيانات حساسة عبر المحادثة — لا عبر تنفيذ الكود.

اقرأ ذلك مجددًا. الخطر ليس فقط أن الوكيل ينفّذ curl evil.com. بل أن وكيلًا متعاونًا، حين يطلب منه تعليمٌ محقون ذلك، سيقرأ ملفًا بكل سرور ويلخّص محتوياته في المحادثة. لا يُنفَّذ أي كود خبيث. النموذج ببساطة يفعل ما قيل له، فيخرج سرّك عبر قناة الرد.

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

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

آلة افتراضية صغيرة معزولة تمامًا لا تنفعك في شيء إن قرأ الوكيل قاعدة بيانات عملائك وكتبها في رد.

مطابقة عمق العزل للمخاطرة

ليس كل عبء عمل يحتاج آلة افتراضية صغيرة. النموذج الصحيح هو مطابقة عمق العزل لنموذج التهديد الفعلي لديك:

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

عند الشك، اذهب أعمق. فرق التكلفة بين حاوية وآلة Firecracker افتراضية صغيرة يُقاس اليوم بعشرات الميلي ثانية ونسب مئوية أحادية الرقم من العبء. أما تكلفة الهروب فتُقاس بتقارير الحوادث والثقة المفقودة.

نحو الإنتاج

إن كنت تنشر تنفيذ كود وكيلي اليوم، فالبنية المبدئية المعقولة تبدو هكذا:

1. اختر مزوّد بيئة عزل قائمًا على الآلات الافتراضية الصغيرة (E2B للأصالة الوكيلة، أو Northflank إن أردت التحكم في مستوى العزل لكل عبء عمل).
2. شغّل كل تنفيذ للكود بشكل مؤقت — بيئة عزل واحدة لكل مهمة، تُدمَّر عند الإنجاز.
3. الرفض الافتراضي للشبكة، مع قائمة سماح خروج صريحة لكل نوع مهمة.
4. وسّط كل الاعتمادات عبر وكيل مُدقَّق؛ لا يعيش أي شيء حساس داخل بيئة العزل.
5. احرس قناة المحادثة بالعناية نفسها التي تحرس بها قناة الكود، لأنها حيث يقع أغلب التسريبات الحقيقية.

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

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

المصادر: Firecrawl — بيئات عزل وكلاء الذكاء الاصطناعي، Northflank — أفضل بيئة لتنفيذ الكود، Spheron — إعداد E2B وDaytona وFirecracker، ARMO — دليل عزل وكلاء الذكاء الاصطناعي.