تُظهر نتائج تقييم أمان 100 وكيل ذكاء اصطناعي: يجب على المؤسسات إعادة النظر في حدود التحكم قبل تسريع الاعتماد عليه

تُظهر نتائج تقييم أمني لـ 100 وكيل ذكاء اصطناعي: على الشركات إعادة النظر في حدود التحكم قبل التسريع في التبنّي

خلال العام الماضي، شهدت استثمارات الشركات في وكلاء الذكاء الاصطناعي ارتفاعًا ملحوظًا، لكن أبحاث الأمن بدأت تذكّر السوق بأن: كلما ازدادت قوة الوكيل، غالبًا ما اتسع سطح الهجوم. ووفقًا لما نقلته SecurityWeek عن دراسة Adversa AI، فقد أجرت الأخيرة تقييمًا أمنيًا لـ100 وكيل ذكاء اصطناعي، وقارنت بينها وفق ثلاثة أبعاد استنادًا إلى “AI Risk Quadrant”: قابلية الاختراق، والأثر التخريبي المحتمل، وقوة الضوابط الدفاعية. وكانت النتائج غير مشجعة — فمن بين 100 وكيل جرى اختبارها، لم يُصنَّف سوى 11 على أنه “capable well-defended” (أي يمتلك قدرات جيدة مع حماية قوية نسبيًا).

تكمن أهمية هذه الدراسة ليس في كون منتج بعينه “آمنًا أم لا”، بل في أنها تكشف واقعًا مؤسسيًا أوسع: الذكاء الاصطناعي الوكيلي (Agentic AI) يضيف مخاطر البرمجيات التقليدية، ومخاطر الهوية، ومخاطر البيانات، ومخاطر التنفيذ الآلي إلى سطح تحكم واحد. وبالنسبة إلى مسؤولي أمن المعلومات (CISO)، وقادة تقنية المعلومات، ومعماريي الأمن، فهذا يعني أن وكلاء الذكاء الاصطناعي لا ينبغي النظر إليهم كمجرد ميزة إنتاجية، بل يجب إدراجهم ضمن الأنظمة عالية الثقة وأنظمة الأتمتة عالية المخاطر.

الخلاصة الأساسية: القدرة والحماية تشهدان “انعكاسًا”

طرحت Adversa AI في تحليلها مفهومًا محوريًا: power-protection inversion (انعكاس القدرة والحماية). وببساطة، كلما كان الوكيل قادرًا على إنجاز مهام أكثر تعقيدًا وأقرب إلى العمليات الأساسية للأعمال، فإنه غالبًا يحتاج أيضًا إلى صلاحيات أعلى، ووصول أوسع إلى البيانات، وقدرات أكبر على تنفيذ إجراءات خارجية؛ وهذه القدرات نفسها توسّع نطاق الضرر إذا جرى إساءة استخدامه أو اختطافه.

وقد اختزلت الدراسة المشكلة في “الثالوث المميت” لوكلاء الذكاء الاصطناعي (lethal trifecta):

1. القدرة على الوصول إلى البيانات الخاصة 2. القدرة على التعامل مع محتوى غير موثوق 3. القدرة على تنفيذ إجراءات صادرة إلى الخارج

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

أي أنواع الوكلاء أكثر خطورة؟ الوكلاء الحاسوبيون ووكلاء البرمجة يستحقون أكبر قدر من الحذر

تشير الدراسة إلى أن الفئتين الأكثر بروزًا من حيث المخاطر هما computer agents (الوكلاء الحاسوبيون) وcoding agents (وكلاء البرمجة).

1) الوكلاء الحاسوبيون: عندما يفقدون السيطرة، لا تكون النتيجة مجرد “سوء تشغيل لتطبيق واحد”

1）الوكيل من نوع الحاسوب: عندما يخرج عن السيطرة، لا تكون العواقب مجرد "تلاعب غير مقصود بتطبيق واحد"

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

وهذا يطرح مشكلتين على مستوى المؤسسات:

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

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

2）الوكيل البرمجي: دخول مباشر أكثر إلى سلسلة توريد البرمجيات

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

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

• الوصول إلى مفاتيح التطوير أو الرموز المميزة
• تعديل عمليات البناء والاختبار
• إدخال تبعيات عالية المخاطر
• التأثير في إعدادات ما قبل الإطلاق أو بيئة الإنتاج
• الوصول إلى الأصول الحساسة قبل مراجعة الكود

بالنسبة للمؤسسات التي تعتمد DevOps أو هندسة المنصات أو أنماط التطوير الداخلي منخفضة الكود / "vibe coding"، فإن تأثير هذا النوع من الوكلاء يكون كبيرًا بشكل خاص لأنه يدمج المخاطر داخل سلسلة توريد البرمجيات نفسها. ولا يكفي أن تراجع المؤسسة الفروق النهائية في الكود فقط، بل يجب أيضًا مراجعة ما الذي نفذه الوكيل من إجراءات، وما الأسرار التي لمسها، وأي الاتصالات الخارجية التي مرّ بها.

التأثير على المؤسسات: ليست مشكلة "أمان نموذج" منفردة، بل مشكلة تحكم في الأعمال

من منظور المؤسسة، تؤثر مشكلات أمان AI Agent في أربعة مستويات على الأقل.

1）المخاطر التشغيلية

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

2）المخاطر المالية

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

3）مخاطر الامتثال والتدقيقعندما يلامس وكيل الذكاء الاصطناعي البيانات الشخصية أو البيانات المالية أو البيانات الخاضعة للتنظيم أو البيانات العابرة للحدود، يجب على المؤسسة أن تجيب عن الأسئلة التالية:

• من الذي فوّض الوكيل؟
• ما البيانات التي وصل إليها؟
• هل يمكن تدقيق كل خطوة من خطواته؟
• هل يلتزم بمتطلبات أقلّ الصلاحيات، وتقليل البيانات، والاحتفاظ بالسجلات؟

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

4）مخاطر العلامة التجارية والثقة

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

هذا يعكس اتجاهًا في الصناعة، وليس حالة معزولة

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

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

• هل يحتاج إلى الوصول إلى بيانات خاصة؟
• هل سيتعامل مع محتوى غير موثوق؟
• هل يمكنه تنفيذ إجراءات صادرة إلى الخارج؟
• هل يدعم حدود صلاحيات قابلة للتحقق، وسجلات تدقيق، وموافقات على الإجراءات؟
• هل يمكنه الانخفاض الآمن عند الفشل؟

بعبارة أخرى، فإن أمن وكلاء الذكاء الاصطناعي ينتقل من كونه “مشكلة على مستوى النموذج” إلى كونه “مشكلة في ضوابط الأعمال وحوكمة وقت التشغيل”.

توصيات للمؤسسات: عامِلوا الوكيل كنظام أتمتة عالي الصلاحيات

على مستوى المؤسسة

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

الهوية والتحكم في الوصول

• فرض مبدأ أقلّ الصلاحيات
• استخدام هوية مستقلة للوكيل بدلًا من حسابات بشرية مشتركة
• إدخال المصادقة متعددة العوامل (MFA)، والوصول المشروط، والموافقة على مستوى الخطوة للإجراءات عالية المخاطر
• إخضاع الإجراءات الحرجة والعمليات غير القابلة للعكس إلى تحقق إضافي

الضوابط التقنية

• استخدام SIEM لتسجيل سلوك الوكيل وتفاعلاته مع الأنظمة بشكل مركزي
• استخدام EDR/XDR لرصد سلوكيات غير طبيعية على الأطراف ونشاطات العبور بين النطاقات
• فرض قيود على حركة البيانات الصادرة، ونداءات API، وتسريب البيانات إلى الخارج
• الاحتفاظ بسجلات قابلة للتدقيق لمسارات تنفيذ الوكيل، وليس فقط سجلات النتائج
• في بيئات التطوير، مراقبة shell، والاعتماديات، والرموز المميزة، وتفاعلات CI/CD

الإدارة والحوكمة

• إدراج وكلاء الذكاء الاصطناعي ضمن خطط الاستجابة للحوادث (Incident Response)
• تقييم مخاطر وكلاء الطرف الثالث، والإضافات، وخوادم MCP، وسلاسل الأدوات الخارجية
• إنشاء عملية إدارة مخاطر الأطراف الثالثة (Third-party Risk Management)
• وضع عتبات للإطلاق وآليات خروج للأتمتة ذات “الصندوق الأسود”
• إعادة مراجعة صلاحيات الوكيل دوريًا بدلًا من اعتبارها صالحة على المدى الطويل افتراضيًا

SecurityPost Insight

• إن اختبارات Adversa AI على 100 وكيل ذكاء اصطناعي تذكّر المؤسسات بأن مشكلات أمن وكلاء الذكاء الاصطناعي ليست أمرًا مستقبليًا، بل هي خطر واقعي يتوسع الآن.- استخدام SIEM لتسجيل سلوك الـAgent وتفاعلاته مع الأنظمة بشكل مركزي
• استخدام EDR/XDR لرصد الشذوذ في سلوك الطرفية والسلوك عبر النطاقات
• فرض قيود على حركة المرور الصادرة، واستدعاءات API، وتسريب البيانات
• الاحتفاظ بسجلات قابلة للتدقيق لمسارات تنفيذ الـAgent، وليس سجلات النتائج فقط
• في سيناريوهات التطوير، مراقبة shell، والاعتمادات، والرموز، وتفاعلات CI/CD

الإدارة والحوكمة

• إدراج Incident Response الخاص بالذكاء الاصطناعي ضمن خطط الاستجابة للحوادث
• تقييم مخاطر الوكلاء الخارجيين، والإضافات، وخوادم MCP، وسلاسل الأدوات الخارجية
• إنشاء عملية Third-party Risk Management
• وضع عتبات للإطلاق وآليات خروج لـ"الأتمتة الصندوقية المغلقة"
• إعادة مراجعة صلاحيات الـAgent دوريًا، بدلًا من اعتبارها صالحة طويلًا بشكل افتراضي

SecurityPost Insight

تذكّر اختبارات Adversa AI على 100 من وكلاء الذكاء الاصطناعي الشركات بأن مشكلات أمن الـAI Agent ليست احتمالًا مستقبليًا، بل خطرًا واقعيًا يتوسع الآن. التحدي الحقيقي لا يقتصر على ما إذا كان النموذج سيتحدث بـ"خطأ"، بل فيما إذا كان، بعد امتلاكه القدرة على الوصول إلى البيانات والتعامل مع المحتوى وتنفيذ عمليات خروجية، سيحوّل خطأً واحدًا إلى حادثة أمنية قابلة للتنفيذ. وبالنسبة للمؤسسات، فإن الخطر الأكبر ليس استخدام الذكاء الاصطناعي، بل نشر AI Agent في غياب الحدود والتدقيق وعزل الصلاحيات.

ثلاثة اتجاهات تستحق المتابعة في المستقبل: أولًا، ستواصل الـAgent الدخول إلى مسارات العمل المكتبية والتطوير وخدمة العملاء والتشغيل؛ ثانيًا، ستصبح هجمات حقن التعليمات، وإساءة استخدام الصلاحيات، وهجمات سلسلة التوريد الموجهة إلى الـAgent أكثر منهجية؛ ثالثًا، ستنتقل الشركات تدريجيًا من "تقييم النماذج" إلى "حوكمة وقت التشغيل" و"الحماية القابلة للتحقق". وبالنسبة إلى CISO، فإن التركيز في المرحلة القادمة ليس على ما إذا كان ينبغي اعتماد الـAgent، بل على كيفية اعتماد الـAgent مع ضمان بقاء الهوية، والخروج، والتدقيق، والأفعال غير القابلة للعكس تحت السيطرة.