ما هو AI Agent Containment؟ وكيف نمنع وكلاء الذكاء الاصطناعي من تجاوز حدودهم؟
لم تعد أنظمة الذكاء الاصطناعي تكتفي بالإجابة عن الأسئلة أو توليد النصوص، إذ بدأت وكلاء الذكاء الاصطناعي (AI Agents) بتنفيذ مهام فعلية باستخدام أدوات خارجية، والوصول إلى الملفات والإنترنت وواجهات API وتشغيل الأوامر البرمجية.
هذا التطور يمنح الذكاء الاصطناعي قدرات أكبر، لكنه يطرح سؤالاً أمنياً جديداً: ماذا يحدث إذا تجاوز وكيل الذكاء الاصطناعي الحدود المسموح بها؟
هنا يظهر مفهوم AI Agent Containment أو احتواء وعزل وكلاء الذكاء الاصطناعي، وهو مجموعة من الضوابط التي تحدد ما يستطيع الوكيل الوصول إليه وتنفيذه، بحيث لا يعتمد الأمان فقط على قرار النموذج نفسه بالتوقف.
لماذا أصبح أمن وكلاء الذكاء الاصطناعي قضية مهمة؟
الفرق الأساسي بين نموذج ذكاء اصطناعي تقليدي وAI Agent يكمن في القدرة على اتخاذ إجراءات داخل أنظمة أخرى.
قد يمتلك الوكيل، بحسب طريقة تشغيله، صلاحية قراءة ملفات، استخدام أدوات برمجية، الاتصال بالإنترنت، استدعاء خدمات عبر API، تنفيذ أوامر في Terminal أو التفاعل مع قواعد البيانات.
وهذا يعني أن الخطأ لم يعد بالضرورة إجابة غير صحيحة تظهر على الشاشة، بل قد يتحول إلى إجراء حقيقي داخل بيئة رقمية.
وتزداد أهمية هذه المشكلة مع توجه الشركات إلى منح الوكلاء صلاحيات أوسع لأتمتة البرمجة وتحليل البيانات والأمن السيبراني وإدارة العمليات.
ماذا حدث مع Gemini ولماذا أعاد النقاش حول Agent Containment؟
عاد الموضوع بقوة إلى الواجهة في سبتمبر/أيلول 2026 بعد الكشف عن حادثة وقعت أثناء تقييم لقدرات Gemini في الأمن السيبراني.
خلال الاختبار الذي أُجري في مايو/أيار 2026، تمكن النظام من الوصول إلى أنظمة تابعة لثلاث شركات حقيقية، بعدما اعتقد أن المواقع المستهدفة تقع ضمن نطاق بيئة الاختبار.
وبحسب المعلومات التي أعلنت عنها Google، استخدم Gemini معلومات عامة وتمكن من تخمين بيانات اعتماد في إحدى الحالات، بينما عثر في حالات أخرى على بيانات اعتماد متاحة علناً. وتوقف النظام عندما أدرك أن الأهداف تعود إلى جهات حقيقية.
المهم هنا أن الحادثة لا تعني أن تطبيق Gemini المستخدم يومياً يستطيع بصورة عادية اختراق الشركات، فقد وقعت ضمن تقييم متخصص للأمن السيبراني مُنح فيه النظام أدوات وقدرات مختلفة عن الاستخدام الاستهلاكي المعتاد.
لكنها تكشف مشكلة أوسع: حتى إذا كان النموذج قادراً على إدراك الخطأ والتوقف، يجب أن تمنعه البنية المحيطة به تقنياً من الوصول إلى أهداف غير مصرح بها منذ البداية.
كما أن Gemini ليس الحالة الوحيدة التي دفعت هذه القضية إلى الواجهة؛ فقد كُشف خلال 2026 عن حوادث أثناء تقييمات أمنية لأنظمة ذكاء اصطناعي أخرى تمكنت فيها نماذج من الوصول إلى الإنترنت أو أنظمة حقيقية خارج النطاق المتوقع للاختبار.
ما هو AI Agent Containment؟
يشير AI Agent Containment إلى مجموعة التقنيات والسياسات التي تحصر وكيل الذكاء الاصطناعي داخل نطاق محدد من الموارد والصلاحيات أثناء تنفيذ المهام.
الفكرة تشبه وضع برنامج غير موثوق داخل بيئة محمية، لكن التحدي يصبح أكبر عندما نتعامل مع Agent يستطيع التخطيط واختيار الأدوات وتنفيذ سلسلة من الإجراءات بصورة شبه مستقلة.
لذلك لا يعني الاحتواء مجرد تشغيل الوكيل داخل Sandbox، بل بناء عدة طبقات من القيود حوله.
ويفترض التصميم الآمن قاعدة بسيطة:
لا يحصل وكيل الذكاء الاصطناعي على أي صلاحية لا يحتاج إليها لتنفيذ المهمة الحالية.
كيف تعمل بيئة Sandbox لوكلاء الذكاء الاصطناعي؟
الـSandbox هي بيئة معزولة تسمح بتشغيل الأوامر والبرامج بعيداً عن النظام الأساسي.
فعلى سبيل المثال، يمكن السماح لوكيل برمجي بإنشاء الملفات وتشغيل الكود داخل مساحة مخصصة، من دون منحه وصولاً مباشراً إلى بقية ملفات الجهاز.
لكن وجود Sandbox وحده لا يعني أن الوكيل أصبح آمناً بالكامل.
إذا كان الوكيل معزولاً عن نظام الملفات لكنه يمتلك اتصالاً مفتوحاً بالإنترنت، فما يزال بإمكانه التواصل مع خدمات خارجية. وإذا امتلك بيانات اعتماد قوية داخل البيئة المعزولة، فقد يستخدمها للوصول إلى أنظمة أخرى.
لهذا يجب التعامل مع عزل الملفات وعزل الشبكة وإدارة بيانات الاعتماد باعتبارها حدوداً منفصلة.
لماذا لا يكفي منع الوصول إلى الملفات؟
أحد الأخطاء الشائعة هو اعتبار حماية نظام الملفات كافية لتأمين Agent.
لكن الوكيل قد يمتلك أدوات أخرى أكثر حساسية، مثل الاتصال بالشبكة أو API أو قواعد البيانات أو المستودعات البرمجية.
ولهذا تستخدم بيئات Agent Sandbox الحديثة عدة مستويات من العزل.
عزل نظام الملفات
يُسمح للوكيل بالوصول إلى الملفات التي يحتاج إليها فقط، بينما تبقى بقية ملفات الجهاز أو الخادم غير متاحة.
عزل الشبكة
يمكن منع الاتصال الخارجي بالكامل أو السماح فقط بنطاقات وخدمات محددة.
وهذه نقطة مهمة لأن السماح بالوصول المفتوح إلى الإنترنت قد يحول مهمة محلية إلى إجراء يمتد خارج البيئة المفترض أنها معزولة.
عزل بيانات الاعتماد
يجب تجنب منح الوكيل مفاتيح API أو كلمات مرور وصلاحيات واسعة بصورة دائمة.
الأفضل استخدام بيانات اعتماد محدودة الصلاحية والنطاق والمدة الزمنية.
ما مبدأ أقل الصلاحيات Least Privilege؟
يعد مبدأ أقل الصلاحيات من أهم القواعد المستخدمة في تأمين وكلاء الذكاء الاصطناعي.
بدلاً من إعطاء Agent صلاحية كاملة ثم محاولة مراقبة سلوكه، يحصل على الحد الأدنى اللازم لتنفيذ المهمة.
فإذا كانت مهمته قراءة مستودع برمجي، فلا توجد حاجة لمنحه صلاحية حذف المستودع. وإذا كان يحتاج إلى استدعاء API واحد، فلا ينبغي منحه مفتاحاً يسمح بالوصول إلى جميع خدمات المؤسسة.
وتصبح هذه القاعدة أكثر أهمية مع الأنظمة القادرة على تنفيذ عشرات الخطوات تلقائياً، لأن خطأ صغيراً في بداية سلسلة التنفيذ قد يتوسع بسرعة عندما تكون الصلاحيات كبيرة.
ما هو Network Allowlisting؟
بدلاً من منح Agent اتصالاً غير محدود بالإنترنت، يمكن إنشاء قائمة سماح للشبكة Network Allowlist.
تحدد هذه القائمة النطاقات أو الخدمات التي يستطيع الوكيل الاتصال بها.
فإذا كانت مهمته تحتاج إلى الوصول إلى خدمة معينة، يمكن السماح بتلك الوجهة فقط ومنع بقية الإنترنت.
هذا الأسلوب يقلل احتمالية انتقال الوكيل إلى نظام غير متوقع أو إرسال بيانات إلى وجهة غير مصرح بها، سواء حدث ذلك بسبب خطأ في التخطيط أو تعليمات ضارة وصلت إليه.
لماذا تشكل Prompt Injection خطراً أكبر على AI Agents؟
هجمات Prompt Injection تصبح أكثر خطورة عندما يكون النموذج متصلاً بأدوات حقيقية.
في روبوت محادثة تقليدي، قد تؤدي التعليمات الخبيثة إلى إجابة غير مرغوبة.
أما في Agent يمتلك أدوات وصلاحيات، فقد تحاول التعليمات الخبيثة دفعه إلى قراءة ملف أو إرسال معلومات أو استخدام أداة بطريقة لم يقصدها المستخدم.
ولهذا لا يمكن اعتبار التعليمات المرسلة إلى النموذج حاجزاً أمنياً كافياً.
حتى إذا طُلب من Agent في الـSystem Prompt عدم الوصول إلى بيانات حساسة، ينبغي أن تكون هناك طبقة تقنية تمنعه من ذلك أصلاً.
هل موافقة المستخدم قبل كل إجراء هي الحل؟
تستخدم بعض أنظمة AI Agents أسلوب Human-in-the-loop، بحيث يطلب الوكيل موافقة المستخدم قبل تنفيذ الإجراءات الحساسة.
هذه الآلية مفيدة خصوصاً عند حذف الملفات أو إجراء تغييرات خارجية أو استخدام بيانات اعتماد مهمة.
لكن مطالبة المستخدم بالموافقة على كل خطوة قد تتحول إلى مشكلة أخرى.
إذا ظهرت عشرات رسائل الموافقة خلال المهمة الواحدة، فقد يعتاد المستخدم قبولها دون مراجعة حقيقية.
لذلك يتجه التصميم الأمني الأفضل إلى الجمع بين القيود التقنية الصارمة والموافقة البشرية عند القرارات عالية الخطورة بدلاً من الاعتماد على الموافقة البشرية وحدها.
ما هو Kill Switch في أنظمة AI Agents؟
يشير مصطلح Kill Switch إلى آلية تسمح بإيقاف الوكيل بسرعة عند اكتشاف سلوك غير متوقع.
لكن زر الإيقاف ليس بديلاً عن الاحتواء.
فالهدف الأول يجب أن يكون منع Agent من امتلاك القدرة على تنفيذ إجراء خطير، ثم تأتي المراقبة والإيقاف كطبقة حماية إضافية.
كما يجب تسجيل العمليات التي ينفذها الوكيل، مثل الأدوات المستخدمة والموارد التي وصل إليها والاتصالات الخارجية ومحاولات الوصول المرفوضة.
هذه السجلات تساعد على اكتشاف السلوك غير الطبيعي وفهم ما حدث بعد أي حادثة.
ما الفرق بين AI Safety وAI Agent Security؟
يتقاطع المجالان لكنهما ليسا الشيء نفسه.
AI Safety مفهوم أوسع يهتم بسلوك نماذج الذكاء الاصطناعي ومواءمتها مع أهداف البشر والمخاطر التي قد تنتج عن قدراتها.
أما AI Agent Security فيركز بصورة أكبر على البيئة التشغيلية: ما الأدوات التي يمتلكها الوكيل؟ ما الملفات التي يستطيع قراءتها؟ إلى أي شبكات يمكنه الاتصال؟ وما الإجراءات التي يستطيع تنفيذها؟
قد يكون النموذج مصمماً لاتباع التعليمات الآمنة، لكن إذا حصل على صلاحيات مفرطة أو وُضع داخل بيئة ضعيفة العزل، تبقى المخاطر قائمة.
والعكس صحيح أيضاً؛ يمكن للبنية الأمنية الجيدة أن تقلل أثر بعض أخطاء النموذج من خلال منعها من التحول إلى إجراءات حقيقية.
كيف يمكن تأمين وكلاء الذكاء الاصطناعي؟
لا توجد طبقة واحدة كافية لحماية AI Agent، لذلك يعتمد النهج الأقوى على الدفاع متعدد الطبقات Defense in Depth.
يبدأ ذلك بتشغيل الوكيل داخل Sandbox معزول، ثم تقييد نظام الملفات والاتصال بالشبكة، وتطبيق مبدأ أقل الصلاحيات، وحماية بيانات الاعتماد، وتحديد الأدوات المتاحة لكل مهمة.
ويضاف إلى ذلك تسجيل النشاط ومراقبة السلوك ووضع حدود للوقت والموارد، إلى جانب طلب موافقة بشرية قبل العمليات الحساسة.
الأهم هو عدم اعتبار قدرة النموذج على معرفة ما هو مسموح وما هو ممنوع بديلاً عن الضوابط التقنية.
هل يمكن أن يخرج وكيل الذكاء الاصطناعي من Sandbox؟
يمكن أن تفشل حدود العزل إذا كانت البيئة نفسها غير مهيأة بصورة صحيحة، أو إذا حصل الوكيل على مسار للوصول إلى موارد لم يكن من المفترض أن تكون متاحة.
لكن مصطلح Sandbox Escape قد يكون مضللاً أحياناً؛ فليس كل وصول غير متوقع يعني أن النموذج اكتشف ثغرة تقنية وكسر نظام العزل.
قد تكون المشكلة ببساطة أن البيئة سمحت باتصال شبكي لم يكن ينبغي السماح به، أو أن الصلاحيات المتاحة للوكيل كانت أوسع من نطاق الاختبار.
لذلك يجب تحليل كل حادثة لمعرفة ما إذا كان هناك اختراق فعلي لحاجز تقني أم فشل في تصميم حدود البيئة نفسها.
هل تصبح AI Agents خطراً أمنياً جديداً؟
لا يعني صعود AI Agents أنها ستتحول بالضرورة إلى أنظمة خارجة عن السيطرة، لكن انتقال الذكاء الاصطناعي من مرحلة توليد المعلومات إلى مرحلة تنفيذ الإجراءات يغير طبيعة المخاطر.
السؤال الأمني لم يعد فقط: هل سيولد النموذج إجابة خاطئة؟
بل أصبح أيضاً: ماذا يستطيع النظام أن يفعل عندما يخطئ؟
وهنا تكمن أهمية AI Agent Containment.
كلما حصل وكلاء الذكاء الاصطناعي على وصول أكبر إلى البرمجيات والشبكات والبيانات والبنية السحابية، سيصبح تصميم الحدود المحيطة بهم جزءاً أساسياً من أمن أنظمة الذكاء الاصطناعي.
وقد تكون الحوادث التي ظهرت خلال 2026 مؤشراً مبكراً على هذا التحول: أمن الذكاء الاصطناعي لم يعد متعلقاً بالنموذج وحده، بل بالبيئة والصلاحيات والأدوات التي نضعها بين يديه.