ماذا لو أصبح وكيل مؤسستك هدفا لوكيل آخر؟

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

هذا السيناريو ليس افتراضا بعيدا. ففي حديث لموقع Axios بتاريخ 8 سبتمبر 2026، توقّع الرئيس التنفيذي لشركة Bugcrowd، Dave Gerry، أن الوكلاء أنفسهم سيصبحون ضحايا الهجمات المقبلة، هذا توقع خبير أمني ينطلق من مواجهة يومية مع هذه المخاطر.

الخلاصة التنفيذية

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

لماذا يصبح الوكيل هدفا؟

الوكيل المؤسسي (AI Agent) برنامج يتصرف نيابة عن مستخدم أو نظام، يقرأ بيانات ويستخدم أدوات متصلة لتنفيذ مهام بأقل تدخل بشري ممكن. وما يجعله هدفا مختلفا عن أي تطبيق تقليدي هو اجتماع ثلاثة عناصر معا: القدرة على الوصول إلى بيانات حساسة، والقدرة على استخدام أدوات تنفّذ إجراءات فعلية كالإرسال والتعديل والدفع، والتفويض الممنوح له للتصرف نيابة عن مستخدم بشري دون مراجعة كل خطوة على حدة.

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

كيف يستغل المهاجم هذه الصلاحيات؟

يسلك المهاجم أحد مسارين رئيسيين، دون حاجة إلى تفاصيل هجومية معقّدة. المسار الأول هو التأثير في سلوك الوكيل عبر تعليمات مموَّهة داخل محتوى خارجي يعالجه بشكل معتاد: رسالة بريد، مستند مرفق، أو صفحة ويب. يصنّف مشروع OWASP لأمن تطبيقات النماذج اللغوية الكبيرة هذا النمط ضمن الفئة الأولى (LLM01: Prompt Injection) تحت مسمى "الحقن غير المباشر للتعليمات" (Indirect Prompt Injection)، حيث يعالج الوكيل التعليمات المزروعة داخل المحتوى وكأنها جزء من مهمته المشروعة، لأن التصميم الأساسي للنموذج لا يميّز دائما بين تعليمات المستخدم ومحتوى يُفترض أن يقرأه فحسب. المسار الثاني هو استغلال بيانات اعتماد الوكيل (Credentials) أو الأدوات المتصلة به مباشرة، بما يمنح المهاجم وصولًا لا يحتاج معه إلى خداع الوكيل من الأساس.

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

الوكيل الذي لم يدخل سجلّك الأمني

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

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

ما الذي تستطيع المؤسسة فعله؟

تبدأ حماية الوكيل المؤسسي من من خمس ركائز أساسية ومترابطة:

الحصر: تحديد كل وكيل يعمل داخل المؤسسة، مع توثيق مالكه، ووظيفته، والبيانات التي يصل إليها، والأدوات المتصلة به. وكيل غير موثَّق في السجل هو وكيل خارج نطاق أي تقييم مخاطر لاحق.

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

الموافقة البشرية: عرض تفاصيل الإجراء الحساس وأثره المحتمل على الشخص المخوَّل قبل التنفيذ لا بعده. الإجراءات التي تمس بيانات مالية أو مستفيدين خارجيين تستحق هذه الوقفة في كل مرة.

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

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

أين يلتقي هذا باحتياجات مؤسستكم اليوم؟

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

هل تستطيع مؤسستك أن تجيب؟

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

بطاقة تعريف الوكيل

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