𝗪𝗵𝘆 𝗬𝗼𝘂𝗿 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗜𝘀 𝗔 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗟𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆
لماذا تُعد بنية وكيل الذكاء الاصطناعي الخاص بك ثغرة أمنية
بحلول عام 2027، ستواجه 40% من عمليات نشر الذكاء الاصطناعي في المؤسسات حوادث حقن الأوامر (prompt injection) أو اختطاف الوكلاء (agent hijack). ويمثل هذا قفزة هائلة مقارنة بأقل من 5% في أوائل عام 2025.
طبقة التنسيق (orchestration layer) تجعل الوكلاء مفيدين، لكنها تجعلهم أهدافاً أيضاً.
خسرت شركة لوجستية في سنغافورة 2.3 مليون دولار مؤخراً. حيث تسبب دعوة تقويم مخترقة في خداع وكيل جدولة، مما دفع الوكيل إلى إرسال سجلات نظام إدارة علاقات العملاء (CRM) إلى مهاجم. لم يكن النموذج يحتوي على أي كود برمجِي خبيث، بل اتبع التعليمات بدقة تامة. كانت المشكلة في البنية التحتية.
الوكلاء ليسوا مجرد روبوتات دردشة؛ بل هم أنظمة تستخدم الأدوات، وتقرأ الملفات، وتنفذ المعاملات. تفترض الأمن التقليدي أن هناك طلباً يصل واستجابة تخرج، لكن الوكلاء يكسرون هذا النموذج.
الوكيل الذي يقوم بصياغة رسائل البريد الإلكتروني وتقديم طلبات الاسترداد يعمل كأنه ثلاثة تطبيقات في بيئة تشغيل واحدة (runtime). كل استدعاء لأداة يمثل مخاطرة، وكل عملية كتابة في الذاكرة تمثل مخاطرة، وكل بريد إلكتروني أو مستند هو بمثابة كود قابل للتنفيذ.
تستخدم الفرق الآمنة نمطاً مكوناً من ثلاث طبقات:
- الهوية (Identity): يحتاج كل استدعاء للأداة إلى هوية منفصلة عن المستخدم.
- المصدر (Provenance): تحتاج كل عملية كتابة في الذاكرة إلى بيانات وصفية (metadata) توضح مصدرها.
- التحقق (Verification): تحتاج كل خطوة في الخطة إلى كائن موقع (signed object) للتنفيذ اللاحق.
لا ينبغي للوكلاء أبداً استدعاء واجهات برمجة التطبيقات (APIs) الخاصة بالإنتاج مباشرة. بدلاً من ذلك، استخدم طبقة أدوات وسيطة. تقوم هذه الطبقة بالتحقق من الوسائط (arguments)، وتحديد نطاق الأذونات، وإنشاء سجلات التدقيق. فكر في هذه الطبقة كجدار حماية جديد لك.
الذاكرة تمثل خطراً هائلاً آخر. يستخدم المهاجمون مستندات أو رسائل بريد إلكتروني مسمومة لتغيير ذاكرة الوكيل، مما يغير سلوك الوكيل بمرور الوقت. وتنمو هجمات تسميم الذاكرة (memory poisoning) بنسبة 300% كل عام.
تضيف معظم الفرق نمذجة تهديدات الذكاء الاصطناعي إلى خطوط الإنتاج الحالية، لكنها لا تضيف الأمن إلى بيئة تشغيل الوكيل (agent runtime) نفسها. 19% فقط من المؤسسات لديها مراقبة للشذوذ في استدعاء الأدوات.
توقف عن معاملة الوكلاء كبرمجيات. عاملهم كموظفين مبتدئين لديهم صلاحية الوصول إلى النظام. لن تمنح موظفاً جديداً صلاحيات الجذر (root access) في يومه الأول، فلا تفعل ذلك مع وكلائك.
الفائزون لن يكونوا أصحاب العروض التوضيحية الأكثر إبهاراً، بل سيكون لديهم وكلاء يجتازون المراجعات الأمنية في قطاعات مثل الخدمات المصرفية أو الرعاية الصحية. ابنِ هذه الطبقات الثلاث الآن، ولا تحاول إضافتها لاحقاً بعد حدوث اختراق.
ما هو القرار المعماري الذي اتخذته مؤخراً والذي قد تغيره لو ركزت على سلامة الوكيل منذ اليوم الأول؟
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi