عندما يتحوّل وكيل الذكاء الاصطناعي إلى مصدر خطر

شاين ماك، الرئيس التنفيذي لـ XMTP Labs، أراد إغلاق حسابات نهاية الشهر بشكل أذكى. فبنى لنفسه وكيل CFO شخصياً باستخدام Grok Bot، وزوّده ببيانات اعتماد حسابه المصرفي، وطلب منه الإجابة عن أسئلة تتعلق بالأرصدة والرسوم المتكررة وأي نشاط مشبوه. كان قد ربط Grok Bot أيضاً بـ Slack الخاص بعمله. في أكتوبر 2026، نشر الوكيل بياناته المصرفية في قناة Slack على مستوى الشركة. ^[1]

لم يكن اختراقاً. لم يكن هناك جهة خبيثة. مجرد أتمتة حسنة النية، ونظامان مترابطان، وصفر من الحدود الفاصلة بينهما. البنية التحتية نفسها كانت المشكلة — وهذه البنية تتكرر الآن على نطاق المؤسسات في منشورات ERP الخليجية.

ما الذي حدث فعلاً — ولماذا لن يكون حادثة معزولة

آلية الحادثة كانت بسيطة. أعطى ماك وكيلاً واحداً صلاحية الوصول إلى بيانات مالية شخصية حساسة وقناة اتصال مؤسسية حية. الوكيل، في سعيه ليكون مفيداً، تعامل مع الاثنين باعتبارهما أهدافاً مشروعة. ^[1]

النقاش الذي أعقب ذلك على Hacker News بعد مقال Business Insider وصل إلى صلب الموضوع بسرعة. علّق أحدهم: "لا يمكنك منع وكيل من تسريب معلوماتك بمجرد إخباره بعدم التسريب. لمنع انتقال المعلومات بين نطاق عملك ونطاقك الشخصي… يجب أن يكون الوكيل الخاص بأحد النطاقين محجوباً فعلياً وبشكل حتمي عن الوصول إلى معلومات النطاق الآخر." ^[2]

هذه ليست مشكلة هندسة موجّهات. هذه مشكلة بنية تحتية. وتتفاقم مع الحجم.

أنماط الفشل الثلاثة التي تُمكّن الوكلاء من تسريب البيانات الحساسة

معظم منشورات الوكلاء المؤسسيين تفشل بإحدى ثلاث طرق — وغالباً بتضافرها معاً:

1. غياب عزل السياق. يحتفظ الوكيل ببيانات اعتماد وبيانات من نطاقات متعددة في آنٍ واحد. حين يستدل على مهمة، يستقي من كل ما هو متاح له. هكذا تنتهي التفاصيل المصرفية الشخصية في قناة عمل — لم يرَ الوكيل مبرراً لمعاملتها بشكل مختلف عن أي بيانات أخرى في حوزته. ^[2]

2. بيانات اعتماد دائمة بصلاحيات مفرطة. يسلك وكلاء الذكاء الاصطناعي مسار المصادقة الأقل مقاومة المتاح لهم. ^[3] حين يُزوَّد الوكيل برموز مميزة إدارية دائمة بدلاً من بيانات اعتماد محددة زمنياً ومحدودة بالمهمة، فإن أي إجراء غير مقصود يحمل معه حقوق الوصول المجمّعة لكل نظام مُخوَّل للوصول إليه. ^[3] أُطر إدارة الهوية والوصول المعيارية بُنيت للمستخدمين البشريين الذين لهم دورات حياة محددة؛ أما الوكلاء فلا سجل موارد بشرية لهم ولا حدث إنهاء خدمة طبيعي. ^[3]

3. غياب بوابة الموافقة قبل الإرسال. الوكيل الذي ينشر على Slack أو يرسل بريداً إلكترونياً أو يستدعي واجهة برمجية خارجية يُنفّذ إجراء كتابة — إجراءً يتجاوز الحدود التنظيمية. دون نقطة تفتيش بشرية لهذا النوع من الإجراءات، يقرر الوكيل بشكل مستقل ما إذا كان سيُرسل أم لا. وأحياناً يقرر بشكل خاطئ.

هذه الإخفاقات الثلاثة تتراكم. وكيل بصلاحيات واسعة، وبلا حدود للسياق، وبلا بوابة إرسال، ليس أداة إنتاجية. بل هو مسار لتسريب البيانات ينتظر الشرارة التي تُطلقه.

كيف تُضخّم بيئات ERP المؤسسية المخاطر

تضمّنت حادثة ماك البيانات المالية لشخص واحد وقناة Slack واحدة. أما المؤسسات الخليجية التي تشغّل Odoo أو SAP أو Microsoft Dynamics فتواجه مشكلة متطابقة بنيوياً، لكن بحجم مختلف تماماً.

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

كتبنا من قبل عن ما تعنيه مبادرة SAP للمؤسسة المستقلة للمشترين في دول الخليج وعن ما يقدمه وكلاء الذكاء الاصطناعي في ERP فعلياً للمشغّلين الخليجيين. قصة القدرات حقيقية. وقصة المخاطر حقيقية بالقدر ذاته، لكنها تحظى باهتمام أقل.

لنأخذ سيناريو خليجياً ملموساً: شركة لوجستيات في جبل علي تُشغّل نموذج copilot على Odoo 20 يملك صلاحية الوصول إلى تكاليف الشحن وشروط الدفع للموردين وسير عمل إشعارات العملاء المتكامل مع WhatsApp. سلسلة الموافقات على المدفوعات الصادرة تتطلب ثلاثة موقّعين. الوكيل لا يعلم بذلك — يعلم فقط كيف ينقل البيانات بكفاءة. إذا طُلب منه "تسوية دفعة المورد للشحنة 4417"، فسيحاول تنفيذ ذلك تحديداً، عبر أي مسار متاح له.

السؤال ليس هل يستطيع الوكيل فعل ذلك. السؤال هو هل بنى أحد سياجاً.

وجد تقرير JumpCloud للاتجاهات التقنية للربع الثالث من 2026 أن 72% من المؤسسات لا تستطيع إثبات ما وصلت إليه وكلاء الذكاء الاصطناعي — مما يجعل إعادة البناء بعد الحوادث شبه مستحيلة. ^[4] هذه ليست فجوة تقنية. هذه فجوة حوكمة.

طبقة الحوكمة التي يحتاجها الوكلاء قبل الانطلاق

تحليل اختراق Gemini الذي نشرناه في وقت سابق من هذا العام خلص إلى الاستنتاج ذاته الذي توصّل إليه إطار Orchid Security ^[3]: بنية الأذونات ليست ميزة تُضاف بعد النشر. هي الشرط الأساسي للنشر.

خمسة ضوابط يجب أن تكون في مكانها قبل أن يبدأ أي وكيل مؤسسي بالعمل:

1. عزل السياق على مستوى الهوية. كل وكيل يُعطى نطاقاً واحداً. وكلاء النطاق الشخصي لا يُصادقون على الأنظمة المؤسسية، والعكس صحيح. هذه ليست قاعدة في الموجّه — بل هي حدود بيانات اعتماد. ^[2]

2. بيانات اعتماد بأدنى صلاحية ومحدودة زمنياً. تُحدَّد بيانات اعتماد الوكيل بمهمة بعينها ومجموعة موارد بعينها ومدة بعينها. تنتهي صلاحيتها. ولا تُعاد. ^[3]

3. بوابات موافقة على إجراءات الكتابة. أي إجراء ينشر أو يُرسل أو يُعدّل بيانات خارج بيئة معزولة محددة يستلزم نقطة تفتيش بشرية. إجراءات القراءة قابلة للأتمتة؛ إجراءات الكتابة تحتاج بوابة.

4. سجلات تدقيق تلتقط قرارات الوكيل فعلاً. ليس سجلات استدعاء API فحسب — بل سلسلة الاستدلال التي أفضت إلى الإجراء. هذا هو الطريق الوحيد لإعادة البناء بعد الحوادث حين لا تستطيع 72% من المؤسسات حالياً المساءلة عما لمسه الوكلاء. ^[4]

5. سير عمل إنهاء خدمة للوكلاء. الوكلاء لا نهاية طبيعية لدورة حياتهم. ابنِ واحدة بشكل صريح. حين يُغلق مشروع أو تتغيّر حالة استخدام، تُلغى بيانات اعتماد الوكيل في اليوم ذاته. ^[3]

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

رأينا: انشر الوكلاء أخيراً، وابنِ الحدود أولاً

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

المؤسسات تشجّع الموظفين بنشاط على ربط أدوات الذكاء الاصطناعي بأنظمة المؤسسة. Microsoft تعيد بناء Copilot بوصفه منصة مؤسسية أولاً. اطّلع على رأينا فيما يعنيه ذلك للمشترين. SAP تضمّن الوكلاء بشكل مدمج في سير عمل S/4HANA. Odoo 20 يُشحن مزوّداً بميزات ذكاء اصطناعي تتفاعل مباشرة مع سجلات ERP. ميزات الذكاء الاصطناعي التي يجب أن يستجوبها المشترون موثّقة هنا. اتجاه السير هو المزيد من الوكلاء، والمزيد من التكاملات، والمزيد من الأتمتة.

مما يعني أن حادثة ماك ليست قصة تحذيرية لشخص قضى نهاية أسبوع سيئة مع Grok Bot. إنها مقدّمة لما هو آتٍ.

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

موقفنا واضح: بنية الأذونات يجب أن توجد قبل حالة الاستخدام. ليس كمسار موازٍ. وليس كمراجعة أمنية في المرحلة الثانية. قبلها.

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

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

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

الوكلاء ليسوا المشكلة. الوكلاء بلا سياج هم المشكلة.