كيف تُنشئ وكلاء الذكاء الاصطناعي مخاطر أمنية جديدة للمؤسسات؟ فهم استدعاءات الأدوات وحدود الأذونات

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

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

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

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

• ذكر بيان التحقيق الأولي لشركة Binance، الصادر في 3 نوفمبر 2026، أن المهاجمين استخدموا أجهزة مهندسين مخترقة وأدوات ذكاء اصطناعي داخلية للوصول بشكل أكبر إلى أجهزة مهندسين آخرين وأذوناتهم.

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

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

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

كيف يختلف وكلاء الذكاء الاصطناعي عن روبوتات الدردشة التقليدية المعتمدة على الذكاء الاصطناعي؟

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

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

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

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

كيف يستدعي وكلاء الذكاء الاصطناعي الأدوات؟

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

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

تأتي مخاطر استدعاء الأدوات أساسًا من جانبين.

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

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

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

لماذا يمكن لوكلاء الذكاء الاصطناعي توسيع سطح هجوم المؤسسة؟

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

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

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

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

لماذا يمكن لحقن الموجّهات أن يؤثر في استدعاءات أدوات وكلاء الذكاء الاصطناعي؟

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

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

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

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

ما المخاطر المتعلقة بأدوات الذكاء الاصطناعي وإدارة الأذونات التي يكشف عنها حادث أمن Binance؟

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

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

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

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

ما حد أذونات وكيل الذكاء الاصطناعي؟ ولماذا يُعد مبدأ الحد الأدنى من الصلاحيات مهمًا جدًا؟

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

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

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

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

ما التحديات الأمنية الجديدة التي يمكن أن تنشئها بروتوكولات ربط الأدوات مثل MCP؟

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

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

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

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

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

كيف ينبغي للمؤسسات حماية هويات وكلاء الذكاء الاصطناعي وأذونات الوصول؟

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

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

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

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

كيف يمكن للمؤسسات تقليل المخاطر الأمنية لاستدعاءات أدوات وكلاء الذكاء الاصطناعي؟

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

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

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

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

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

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

لماذا أصبح أمن وكلاء الذكاء الاصطناعي قضية مهمة للبنية التحتية لـ ويب3؟

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

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

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

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

الخلاصة

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

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

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

الأسئلة الشائعة

لماذا تنطوي وكلاء الذكاء الاصطناعي على مخاطر أمنية أكبر من روبوتات الدردشة العادية؟

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

ما هو استدعاء أدوات وكيل الذكاء الاصطناعي؟

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

هل يمكن لحقن الموجّهات التحكم في وكيل الذكاء الاصطناعي دائمًا؟

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

هل يثبت حادث أمن Binance وجود ثغرات لدى وكلاء الذكاء الاصطناعي؟

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

هل يزيد MCP من مخاطر أمن وكلاء الذكاء الاصطناعي؟

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

كيف ينبغي للمؤسسات تقييد أذونات وكلاء الذكاء الاصطناعي؟

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