Category
وكلاء الذكاء الاصطناعي
Share the article
أفادت 88% من المؤسسات عن تسجيل حادثة أمنية مؤكدة أو مشتبه بها تتعلق بوكلاء الذكاء الاصطناعي في العام الماضي. وفي قطاع الرعاية الصحية، ترتفع هذه النسبة لتصل إلى 92.7%.
إن الفجوة مذهلة للغاية: إذ يعتقد 82% من المديرين التنفيذيين أن سياساتهم الحالية تحميهم من الإجراءات غير المصرح بها للوكلاء. ولكن 21% فقط لديهم رؤية فعلية لما يمكن لوكلائهم الوصول إليه، أو الأدوات التي يستدعونها، أو البيانات التي يتعاملون معها.
لقد انتقل وكلاء الذكاء الاصطناعي من العروض التوضيحية التجريبية إلى الأنظمة الإنتاجية بسرعة تفوق قدرة الفرق الأمنية على مواكبتها. ووفقاً لـ تقرير Gravitee لحالة أمن وكلاء الذكاء الاصطناعي لعام 2026، فإن 80.9% من الفرق الفنية قد تجاوزت مرحلة التخطيط إلى الاختبار النشط أو الإنتاج الفعلي. ولم يتم تشغيل سوى 14.4% فقط من هؤلاء الوكلاء بموافقة كاملة من قسم تكنولوجيا المعلومات والأمن.
هذا ليس خطراً مستقبلياً، بل هو أزمة حالية. والمؤسسات التي تتعامل مع أمن الوكلاء كفكرة ثانوية ستدفع ثمن ذلك في شكل اختراقات، وانتهاكات للامتثال، وفقدان للثقة.
الاعتماد قد تجاوز الحوكمة
إن سرعة نشر وكلاء الذكاء الاصطناعي قد خلقت فجوة أمنية هيكلية.وتقوم الفرق بإطلاق الوكلاء في بيئات الإنتاج بينما لا تزال أطر الحوكمة قيد الصياغة.
تأمل هذه الأرقام: يتم مراقبة أو تأمين 47.1% فقط من وكلاء الذكاء الاصطناعي في المؤسسات بشكل فعال. وهذا يعني أن أكثر من نصفهم يعملون دون إشراف أمني مستمر أو تسجيل للأنشطة. وفي الوقت ذاته، يمكن لـ 25.5% من الوكلاء الذين تم نشرهم إنشاء وتكليف وكلاء آخرين، مما يضاعف مساحة الهجوم المعرضة للخطر مع كل عملية نشر جديدة.
تظهر فجوة الحوكمة في كيفية تعامل المؤسسات مع هوية الوكيل. إذ تعامل 21.9% فقط من المؤسسات وكلاء الذكاء الاصطناعي ككيانات مستقلة تحمل هوية خاصة بها. أما البقية فتدمجهم مع حسابات الخدمة الحالية، أو الأسوأ من ذلك، تتوفر بيانات الاعتماد المشتركة عبر الوكلاء. ويعتمد 45.6% بشكل كامل على مفاتيح واجهة برمجة التطبيقات (API) المشتركة للمصادقة بين الوكلاء، ويستخدم 27.2% منطقاً برمجياً مخصصاً ومكتوباً مباشرة في الكود (hardcoded) للحصول على التفويض.
هذا يعادل إعطاء كل موظف نفس كلمة المرور والأمل في ألا يقوم أحد بأي تصرف متهور.
السطح الحقيقي للهجوم
وكلاء الذكاء الاصطناعي ليسوا برمجيات ثابتة. فهم يفكرون، ويخططون، ويستدعون أدوات خارجية، ويتخذون القرارات بشكل مستقل. وكل واحدة من تلك القدرات تقدم ناقلاً مميزاً للهجوم لم يتم تصميم أمن التطبيقات التقليدي للتعامل معه مطلقاً.
حقن الأوامر (Prompt Injection)
صُنف حقن الأوامر كأبرز الثغرات الأمنية في أهم 10 ثغرات لنماذج اللغات الكبيرة (LLM) من OWASP لعام 2025. حيث يمكن للتعليمات العدائية المضمنة في مدخلات المستخدمين، أو المستندات، أو حتى البيانات المسترجعة أن تغير سلوك الوكيل دون إطلاق أي تنبيه أمني تقليدي.
يتضاعف الخطر في الأنظمة المعتمدة على الوكلاء. فعندما يسترجع الوكيل بيانات خارجية، ويعالجها، ويتخذ إجراءً بناءً عليها، فإن تعليمة واحدة محقونة يمكن أن تتوالى تأثيراتها عبر سير العمل بأكمله. وقد أظهرت الهجمات المعتمدة على ضبط الإعدادات الدقيقة تجاوز نظام Claude Haiku في 72% من الحالات ونظام GPT-4o في 57%، وفقاً لـ أبحاث استشهدت بها HelpNetSecurity.
الصلاحيات المفرطة (Over-permissioning)
يتم إطلاق معظم الوكلاء مع صلاحيات وصول أكبر مما يحتاجون إليه بالفعل. وعندما يتمكن وكيل دعم العملاء من قراءة قاعدة المعرفة بأكملها، والاستعلام عن أنظمة الفوترة، وتعديل إعدادات الحساب، فإن نصف قطر الانفجار الناتج عن اختراق واحد ينمو بشكل مضاعف.
يوصي الدرس التعليمي لأمن وكلاء الذكاء الاصطناعي من IBM بمنح الصلاحيات في الوقت المناسب فقط (just-in-time permissions)، حيث يتم منح الوصول فقط طوال مدة مهمة محددة وإلغاؤه فور انتهائها. ومن الناحية العملية، لا تطبق سوى مؤسسات قليلة هذا النهج، فالوضع الافتراضي هو منح صلاحيات واسعة لا تخضع للمراجعة أبداً.
الذكاء الاصطناعي الخفي (Shadow AI)
أبلغت مؤسسة واحدة من كل خمس عن حدوث اختراقات مرتبطة بنشر ذكاء اصطناعي غير مصرح به. فالذكاء الاصطناعي الخفي، وهو استخدام الموظفين لأدوات ذكاء اصطناعي غير مصرح بها، يخلق نقاطاً عمياء حيث يقوم الوكلاء بالوصول إلى البيانات الحساسة ومعالجتها عبر قنوات غير مراقبة.
التكلفة قابلة للقياس: تكلف اختراقات الذكاء الاصطناعي الخفي في المتوسط 670,000 دولار أكثر من الحوادث الأمنية القياسية. ومع احتواء الشركات الكبرى على ما يقرب من 1,200 تطبيق ذكاء اصطناعي غير رسمي في المتوسط، فإن حجم التعرض للمخاطر هائل بالتأكيد.
الذاكرة واستمرارية البيانات
الوكلاء الذين يحافظون على تاريخ المحادثات أو السياق عبر الجلسات يجمعون معلومات حساسة بمرور الوقت. ودون إدارة واضحة لدورة حياة الذاكرة، تصبح نافذة سياق الوكيل مستودعاً متنامياً لبيانات العملاء، والقرارات الداخلية، وبيانات اعتماد الأنظمة.
يوصي الإطار الأمني من IBM بتقييد دورات حياة الذاكرة بحدود صارمة للرموز (tokens) لمنع تراكم البيانات غير المقصود. على سبيل المثال، فإن تحديد سقف للذاكرة عند 20,000 رمز يجبر الوكيل على العمل ضمن حدود معلومات محددة بدلاً من تخزين كل ما يمر عليه.
فجوة الثقة لدى الإدارة التنفيذية
ربما تكون النتيجة الأكثر خطورة في بيانات عام 2026 هي الفجوة بين ثقة الإدارة التنفيذية والواقع التشغيلي.
يشعر 82% من المديرين التنفيذيين بالثقة في أن سياساتهم الحالية تحمي من إجراءات الوكلاء غير المصرح بها. لكن البيانات الميدانية تروي قصة مختلفة: يعمل أكثر من نصف الوكلاء الذين تم نشرهم دون إشراف أمني أو تسجيل للأنشطة. وفقط 21% من المديرين التنفيذيين لديهم رؤية كاملة لصلاحيات الوكلاء، أو استخدام الأدوات، أو أنماط الوصول إلى البيانات.
توجد هذه الفجوة لأن معظم المؤسسات قامت بتوسيع أطر أمن التطبيقات الحالية لتشمل وكلاء الذكاء الاصطناعي. المشكلة هي أن الوكلاء ليسوا مجرد تطبيقات؛ فهم يتخذون قرارات مستقلة، ويستدعون أدوات خارجية، ويمكن التلاعب بهم من خلال مدخلاتهم بطرق تعجز البرمجيات التقليدية عن مجاراتها.
إن جدار الحماية لا يمنع حقن الأوامر. وبوابة واجهة برمجة التطبيقات (API gateway) لا تمنع وكيلاً ذا صلاحيات مفرطة من تسريب البيانات عبر استدعاء أداة مشروع. يجب أن يتطابق النموذج الأمني مع نموذج التهديد، وهو ما لا يتوفر لدى معظم الشركات الكبرى.
كيف يبدو الهيكل الآمن للوكيل
المؤسسات التي تأخذ أمن الوكلاء على محمل الجد تشترك في بعض الممارسات الشائعة. لا توجد بينها ممارسات غريبة أو مكلفة، بل هي أساسية، ومع ذلك تتجاهلها معظم الشركات.
التحكم في الوصول القائم على الهوية أولاً
يحتاج كل وكيل إلى هويته الخاصة مع صلاحيات محددة وواضحة. إن مفاتيح واجهة برمجة التطبيقات المشتركة وبيانات اعتماد حسابات الخدمة الموروثة تعادل في عالم الوكلاء ترك الباب الأمامي مفتوحاً بلا قفل.
يجب أن يعمل التحكم في الوصول القائم على الأدوار (RBAC) على أربعة مستويات: المؤسسة، ومساحة العمل، والوكيل، والإجراء الفردي. في Beam، يعمل RBAC في كل طبقة. وتحدد رموز OAuth ما يسمح به كل نظام متصل. وإذا كان المستخدم يفتقر إلى الصلاحية في النظام الخارجي، ف سيفشل إجراء الوكيل، ليس بشكل صامت، بل مع ظهور خطأ صريح من ذلك النظام.
بوابات التحقق من الصلاحيات
يجب أن يتطلب كل استدعاء أداة تحققاً صريحاً من الصلاحية قبل التنفيذ. يغلف إطار عمل IBM كل أداة بمدير صلاحيات (PermissionManager) يتحكم في الوصول أثناء وقت التشغيل، وليس فقط عند النشر.
هذا يعني أن الوكيل لا يمكنه استدعاء استعلام قاعدة بيانات، أو إرسال بريد إلكتروني، أو الوصول إلى نظام ملفات دون المرور أولاً عبر فحص الصلاحيات. العبء الإضافي هنا بسيط للغاية، لكن الحماية كبيرة.
سجلات المراجعة (Audit Trails)
أنت بحاجة إلى مسارات تتبع التنفيذ التي توضح بالضبط ما حدث: كل محفز، ومدخل، وقرار، وإجراء. وتثبت سجلات المراجعة غير القابلة للتغيير ما فعله الوكيل، ومتى، ولماذا.
هذا الأمر ليس اختيارياً للصناعات الخاضعة للتنظيم. فالرعاية الصحية (بمعدل حوادث 92.7%)، والقطاع المالي، والمؤسسات الحكومية تواجه متطلبات امتثال تستدعي هذا المستوى من التتبع. ولكن حتى خارج القطاعات الخاضعة للتنظيم، فإن سجلات المراجعة هي الطريقة الموثوقة الوحيدة لاكتشاف الوكلاء المخترقين الذين يبدو أنهم يعملون بشكل طبيعي بينما يقدمون مخرجات متلاعب بها بمهارة أو يسربون البيانات عبر قنوات جانبية.
المحاكاة المستمرة للاختراق (Red-Teaming)
لا تجدي مراجعات الأمن الثابتة نفعاً مع الأنظمة التي تفكر وتستجيب ديناميكياً. تحتاج المؤسسات إلى دمج عمليات المحاكاة المستمرة للاختراق في عمليات الوكلاء، واختبار حقن الأوامر، وتصعيد الامتيازات، وتسريب البيانات بصورة مستمرة.
وقد أظهرت أدوات المحاكاة الآلية للاختراق خفضاً في التكاليف بنسبة 42-58% مقارنة بالأساليب التقليدية مع الحفاظ على تغطية أوسع للثغرات الأمنية. إن جدوى هذا الاستثمار واضحة ومباشرة: اعثر على الثغرات قبل أن يجدها المهاجمون.
تحذير Moltbook
يوضح مثال حديث ما يحدث عندما يتم التعامل مع أمن الوكلاء كفكرة ثانوية. فقد تم الاستحواذ على Moltbook من قبل Meta في 10 مارس، وهي شبكة التواصل الاجتماعي لوكلاء الذكاء الاصطناعي التي لاقت انتشاراً واسعاً في يناير 2026. وسمحت المنصة لوكلاء الذكاء الاصطناعي بالتفاعل بشكل مستقل في منتديات شبيهة بـ Reddit؛ حيث ينشرون ويعلقون ويصوتون دون تدخل بشري.
بدا الأمر مبتكراً حتى اكتشفت 404 Media قاعدة بيانات غير مؤمنة سمحت لأي شخص باختطاف أي وكيل على المنصة. وقد تبين أن المنشور المنتشر الذي أثار قلق الملايين —والذي أظهر وكيل ذكاء اصطناعي ينظم على ما يبدو لغة سرية مشفرة للاختباء من البشر— كان في الواقع لشخص يستغل هذه الثغرة الأمنية للنشر باستخدام بيانات اعتماد أحد الوكلاء.
إن Moltbook منتج استهلاكي وليس نظاماً للشركات. لكن الدرس المستفاد ينطبق مباشرة: عندما يعمل الوكلاء دون إدارة سليمة للهوية، وبوابات للصلاحيات، وتسجيل للمراجعة، فلن تتمكن من التمييز بين سلوك الوكيل المشروع والتلاعب العدائي.
فجوة أطر العمل
توفر أطر الحوكمة الحالية مثل NIST AI RMF و ISO 42001 هيكلاً تنظيمياً، لكنها لا تعالج الضوابط التقنية المحددة التي تحتاجها عمليات نشر الوكلاء. إن التحقق من معلمات استدعاء الأدوات، وتسجيل حقن الأوامر، والمصادقة بين الوكلاء، وفحوصات الصلاحيات أثناء وقت التشغيل تقع جميعها خارج نطاق هذه الأطر.
تحتاج المؤسسات إلى وضع الضوابط التقنية فوق أطر الحوكمة، وليس اختيار أحدهما دون الآخر. ويقدم إطار دورة حياة تطوير الوكلاء (ADLC) من IBM نموذجاً واحداً: تطبيق مبادئ الأمن بدءاً من التصميم ومروراً بنمذجة التهديدات، والتطوير الآمن، والاختبار، والنشر، والمراقبة.
كحد أدنى، يجب على كل شركة تقوم بنشر وكلاء الذكاء الاصطناعي تنفيذ ما يلي:
هوية على مستوى الوكيل والتحكم في الوصول القائم على الأدوار (RBAC) مع صلاحيات محددة تمنح في الوقت المناسب
بوابات التحقق من الصلاحيات عند كل استدعاء لأداة، وليس فقط عند النشر
سجلات مراجعة غير قابلة للتغيير تغطي المحفزات، والمدخلات، والقرارات، والإجراءات
قيود على دورة حياة الذاكرة لمنع تراكم البيانات غير المحدود
محاكاة آلية مستمرة للاختراق (Red-Teaming) للكشف عن حقن الأوامر وتصعيد الامتيازات
بنية الثقة الصفرية (Zero Trust) حيث يتم مصادقة كل إجراء للوكيل كما لو كان طلباً جديداً بالكامل
الخيار
أصبح وكلاء الذكاء الاصطناعي يشكلون بنية تحتية أساسية. والسؤال الآن ليس ما إذا كان ينبغي نشرهم، بل كيفية نشرهم بشكل آمن.
البيانات واضحة: عانت 88% من المؤسسات بالفعل من حوادث أمنية. ونسبة الـ 14.4% التي قامت بالنشر بموافقة أمنية كاملة لا تتحرك ببطء، بل تتحرك بإنضباط ومنهجية، وهم من سيستمرون في تشغيل الوكلاء في بيئات الإنتاج بعد عام من الآن دون أن تصدر أخبار اختراقاتهم العناوين الرئيسية.
المؤسسات التي تبني الأمن في هيكلية وكلائها من اليوم الأول ستتوسع بثقة. أما البقية فستتعلم بالطريقة الصعبة أن استراتيجية "التحرك السريع والإصلاح لاحقاً" لا تجدي نفعاً عندما يمتلك وكلاء الذكاء الاصطناعي صلاحية الوصول إلى بيانات العملاء، و الأنظمة المالية، وسير العمل الحاسم للأعمال.
إن النشر الصحيح لوكلاء الذكاء الاصطناعي في الشركات يعني تحقيق الأمن في كل طبقة، بدءاً من الهوية والصلاحيات ووصولاً إلى سجلات المراجعة والمراقبة المستمرة. الأدوات متوفرة، وأطر العمل متوفرة، والسؤال الوحيد هو ما إذا كانت مؤسستك ستستخدمها قبل الحادثة الأولى أم بعدها.
