أمن الذكاء الاصطناعي الوكيل: دليل OWASP Top 10 للمؤسسات في 2026

ثورة الذكاء الاصطناعي الوكيل

يمثل الذكاء الاصطناعي الوكيل تحولاً جوهرياً من مساعدي الذكاء الاصطناعي التفاعليين إلى أنظمة مستقلة قادرة على التخطيط واتخاذ القرار والتصرف. وتشير McKinsey إلى أنه يُتوقع أن تساعد أنظمة الذكاء الاصطناعي الوكيل على تحقيق قيمة تتراوح بين 2.6 و4.4 تريليون دولار سنوياً عبر أكثر من 60 حالة استخدام للذكاء الاصطناعي التوليدي.

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

وعلى عكس النماذج اللغوية الكبيرة التقليدية التي تستجيب لطلبات منفردة، تستطيع أنظمة الذكاء الاصطناعي الوكيل:

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

تخلق هذه الاستقلالية أسطح هجوم جديدة كلياً، وقد تناولها مشروع OWASP GenAI Security في قائمته Top 10 للتطبيقات الوكيلة التي صدرت في 9 ديسمبر 2025.

قائمة OWASP Top 10 للتطبيقات الوكيلة

توضّح OWASP كل بند بحوادث وقعت بالفعل. الأسماء أدناه تتبع القائمة الرسمية، أما إجراءات التخفيف فهي خلاصتنا العملية.

ASI01 - اختطاف هدف الوكيل (Agent Goal Hijack)

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

التخفيف:

• التحقق من الهدف في كل خطوة
• استخدام مواصفات أهداف غير قابلة للتعديل
• مراقبة أنماط انحراف الهدف

ASI02 - إساءة استخدام الأدوات (Tool Misuse)

الخطر: يستخدم الوكلاء أدوات مشروعة بطرق غير آمنة أو غير مصرح بها. وتستشهد OWASP بحادثة Amazon Q، حيث وجّه وكيلٌ أدوات مشروعة نحو نتائج مدمّرة.

مثال توضيحي: وكيل لمعالجة الفواتير يُخدع لإرسال مستندات حساسة بالبريد الإلكتروني إلى جهات خارجية باستخدام قدرته المشروعة على إرسال الرسائل.

التخفيف:

• تطبيق ضوابط وصول على مستوى الأدوات
• عزل جميع عمليات تنفيذ الأدوات في بيئة معزولة
• تسجيل جميع استدعاءات الأدوات وتدقيقها

ASI03 - إساءة استخدام الهوية والامتيازات

الخطر: يصعّد الوكلاء امتيازاتهم بإعادة استخدام بيانات الاعتماد أو وراثتها، وتتيح لهم بيانات الاعتماد المسرّبة العمل بعيداً عن النطاق المحدد لهم.

وينشأ عن ذلك مشكلة "انفجار الهويات" - إذ قد يحتاج كل وكيل إلى بيانات اعتماد فريدة، ما يجعل إدارة الهويات أكثر تعقيداً بكثير.

التخفيف:

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

ASI04 - ثغرات سلسلة التوريد الوكيلة

الخطر: الاختراق عبر مكونات أو إضافات أو أدوات أو واجهات نماذج تابعة لأطراف ثالثة.

تستشهد OWASP باستغلال GitHub MCP (Model Context Protocol) مثالاً على ذلك: فقد أظهرت منظومات MCP والتواصل بين الوكلاء الديناميكية مدى سهولة تسميم مكونات وقت التشغيل.

التخفيف:

• تدقيق جميع مكونات الأطراف الثالثة
• اعتماد توقيعات للمكونات
• مراقبة الحالات الشاذة في سلسلة التوريد

ASI05 - تنفيذ تعليمات برمجية غير متوقع

الخطر: تقود مسارات التنفيذ باللغة الطبيعية الوكيل إلى تشغيل تعليمات برمجية دون تحقق مناسب. ومثال OWASP هو ثغرة تنفيذ تعليمات برمجية عن بُعد في AutoGPT.

التخفيف:

• عزل كل عمليات تنفيذ التعليمات البرمجية
• التحقق من جميع المدخلات قبل التنفيذ
• تنقية المخرجات

ASI06 - تسميم الذاكرة والسياق

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

ASI07 - التواصل غير الآمن بين الوكلاء

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

عندما يستطيع الوكلاء التواصل فيما بينهم، يمكن للمهاجمين:

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

ASI08 - الإخفاقات المتتالية

الخطر: إشارة خاطئة أو إجراء معيب واحد ينتشر عبر خطوط المعالجة الآلية بأثر متصاعد.

تحدّ حدود العزل من مدى انتشار الإخفاق:

ASI09 - استغلال الثقة بين الإنسان والوكيل

الخطر: تدفع التفسيرات الواثقة والمصقولة المشغّلين من البشر إلى الموافقة على إجراءات ضارة.

أفضل ممارسة: في الإجراءات عالية الأثر، اطلب من الوكيل عرض الأدلة التي يستند إليها طلبه، لا تفسيره فقط، واجعل الموافقة قائمة على تلك الأدلة.

ASI10 - الوكلاء المنفلتون (Rogue Agents)

الخطر: وكلاء يُظهرون عدم اتساق مع الأهداف أو إخفاءً أو تصرفاً ذاتي التوجيه. ومثال OWASP هو حادثة Replit.

يعتمد اكتشاف الوكيل المنفلت على التسجيل:

لماذا تتعثر مشاريع الذكاء الاصطناعي الوكيل

لا يوجد رقم عام موثوق لمعدل فشل مشاريع الذكاء الاصطناعي الوكيل، لذلك لا نذكر أي رقم. أما جانب المخاطر فموثّق (انظر McKinsey أعلاه)، وأسباب تعثر المشاريع تتكرر باستمرار:

ما تشترك فيه المشاريع الناجحة

1. إعادة ابتكار العمليات - لا مجرد إدخال الذكاء الاصطناعي في مسارات العمل القائمة
2. حوكمة قوية - الأمن والامتثال منذ اليوم الأول
3. حالات الاستخدام الصحيحة - البدء بتطبيقات عمودية خاصة بالمجال
4. الاستثمار في إدارة التغيير - برامج التدريب والتبنّي
5. تخطيط سليم للتكلفة الإجمالية للملكية - وضع ميزانية لتكاليف التشغيل الفعلية، لا للمرحلة التجريبية فقط

الحوكمة أثناء التشغيل: الفرق الحاسم

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

كيف تبدو الحوكمة أثناء التشغيل

سيناريوهات الهجوم التي تم إثباتها

بنى فريق Unit 42 التابع لـ Palo Alto Networks تطبيقين متطابقين وظيفياً، أحدهما باستخدام CrewAI والآخر باستخدام AutoGen، ونفّذ تسعة سيناريوهات هجوم ملموسة على كليهما. ومن أمثلتها:

ويؤكد Unit 42 أن أياً من الإطارين ليس معرضاً للخطر بطبيعته: فالهجمات تنجح بسبب أنماط تصميم غير آمنة وإعدادات خاطئة وتكاملات أدوات غير آمنة. ولم تكن هذه تجارب نظرية - فقد نفّذها Unit 42 من البداية إلى النهاية على تطبيقات عاملة ونشر الشيفرة المصدرية بشكل مفتوح.

خارطة طريق التنفيذ

المرحلة 1: التقييم (الأسبوعان 1-2)

• لم يُنجَز بعد: حصر عمليات نشر الوكلاء الحالية والمخطط لها
• لم يُنجَز بعد: رسم خريطة لقدرات الوكلاء وصلاحياتهم
• لم يُنجَز بعد: تحديد حالات الاستخدام عالية المخاطر
• لم يُنجَز بعد: تقييم الضوابط الأمنية الحالية

المرحلة 2: البنية (الأسابيع 2-4)

• لم يُنجَز بعد: تصميم حدود العزل
• لم يُنجَز بعد: تخطيط إدارة الهوية والوصول
• لم يُنجَز بعد: تحديد سياسات تفويض الأدوات
• لم يُنجَز بعد: وضع متطلبات التسجيل

المرحلة 3: الضوابط (الأسابيع 4-8)

• لم يُنجَز بعد: تطبيق الحوكمة أثناء التشغيل
• لم يُنجَز بعد: نشر المراقبة والتنبيهات
• لم يُنجَز بعد: إعداد بيئات التنفيذ المعزولة
• لم يُنجَز بعد: تفعيل التسجيل الشامل

المرحلة 4: التحقق (الأسابيع 8-12)

• لم يُنجَز بعد: اختبارات الفريق الأحمر (راجع دليل Agentic AI Red Teaming الصادر عن CSA)
• لم يُنجَز بعد: اختبارات اختراق أنظمة الوكلاء
• لم يُنجَز بعد: التحقق من قدرات الكشف
• لم يُنجَز بعد: توثيق إجراءات الاستجابة للحوادث

الخلاصة

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

النقاط الرئيسية:

1. يحتاج الذكاء الاصطناعي الوكيل إلى حوكمة أثناء التشغيل - ضوابط ما قبل النشر لا تكفي
2. انفجار الهويات حقيقي - يحتاج كل وكيل إلى بيانات اعتماد فريدة ومحدودة النطاق
3. السلوكيات الخطرة للوكلاء شائعة بالفعل - تقول 80% من المؤسسات إنها واجهتها (McKinsey)
4. الحوكمة هي ما يجعل الوكلاء قابلين للإطلاق - ضوابط جاهزة قبل أن يتصرف الوكيل، لا بعد وقوع الحادث
5. OWASP توفر خارطة الطريق - اتبع قائمة Top 10 للتطبيقات الوكيلة

ليس السؤال ما إذا كان عليك تبنّي الذكاء الاصطناعي الوكيل - فإمكانات القيمة أكبر من أن تُتجاهل. السؤال هو ما إذا كانت ضوابطك جاهزة قبل أن يبدأ وكلاؤك بالتصرف في أنظمتك.