لماذا يجب ألا تكون بوابة الوكلاء أول طبقة لحماية وكلاء الذكاء الاصطناعي؟

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

وتكتسب هذه المشكلة وزناً عملياً مع توسع نشر الوكلاء. ففي يونيو، أضافت وكالة الأمن السيبراني وأمن البنية التحتية الأميركية (CISA) ثغرة في LiteLLM إلى كتالوج الثغرات المستغلة المعروفة، بعد رصد إساءة استخدامها فعلياً. وكانت الثغرة تتيح تنفيذ أوامر على المضيف عبر البوابة نفسها، كما أمكن، عند دمجها مع ثغرة ثانية، استغلالها من دون بيانات اعتماد. ويذكر المصدر أن البوابة شهدت الكشف عن سبع ثغرات شائعة (CVEs) خلال شهر واحد.

الأمن هنا سلسلة اعتماد لا نقطة تحكم منفردة

يقترح Kale ما يسميه «النشر المحكوم بالاعتماد»، أي ألا تُعد أي طبقة لاحقة مكتملة تشغيلياً قبل اجتياز الاختبارات المطلوبة للطبقات السابقة. ويمكن تطوير الضوابط بالتوازي، لكن تفعيلها في الإنتاج يجب أن يتبع ترتيباً واضحاً:

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

ابدأ بما يمكن تعريفه وإسناده

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

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

قلّص الصلاحيات قبل تحليل السلوك

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

ويستشهد Kale بدراسة Teleport لعام 2026 التي شملت 205 من قادة الأمن؛ إذ أبلغت المؤسسات التي تستخدم ذكاءً اصطناعياً مفرط الصلاحيات عن معدل حوادث بلغ 76%، مقابل 17% لدى المؤسسات التي تطبق مبدأ أقل الصلاحيات. وبحسب تحليله، يدل ذلك على أن نطاق الوصول قد يكون عاملاً أسبق في سلسلة الاعتماد من فرض سياسات وقت التشغيل المدركة للسياق.

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

متى تصبح البوابة مفيدة فعلاً؟

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

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

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

خطة اختبار خلال 30 يوماً

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

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

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