«كاسبرسكي»: يجب معاملة وكلاء الذكاء الاصطناعي كـ«متعاقدين خارجيين» وبقدرات محدودة

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

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

الخطر يبدأ من الصلاحيات

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

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

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

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

هوية مستقلة عن الإنسان

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

ومن الإجراءات التي يركز عليها عزل الوكيل وعدم السماح له بالعمل ببساطة على الجهاز نفسه الذي يستخدمه الموظف العادي.

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

خطأ ذاتي أم تلاعب خارجي؟

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

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

هل يمكن أن يؤثر وكيل في آخر؟

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

الأمن التقليدي لم يفقد دوره

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

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

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

ما الذي يجب ألا يلمسه الوكيل؟

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

متى يجب إيقاف الوكيل؟

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

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

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

الإنسان يبقى داخل الحلقة

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

السعودية والخليج… البيانات الحساسة داخل الحدود

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

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

جدار حماية للوكلاء

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