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

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

خلال العامين أو الثلاثة الماضية، توقفت الشركات الروسية عن النظر إلى الذكاء الاصطناعي التوليدي كتجربة مثيرة للفضول، وبدأت في دمجه في العمليات اليومية. ولم يعد الأمر مقتصراً على دردشات الدعم أو مسودات النصوص: فالنماذج تساعد المطورين، وتشارك في مراجعة الشيفرة (code review)، وتولّد شيفرة البنية التحتية، وتعمل مع الإعدادات، وتتحول بصورة متزايدة إلى جزء من المنتجات الفعلية. وتشير التوصيات الدولية إلى الاتجاه نفسه: فمعهد NIST يقترح النظر إلى الذكاء الاصطناعي التوليدي بوصفه عنصراً من البنية التحتية الحيوية، وتتناول ENISA بشكل منفصل دوره في DevSecOps وأتمتة الهندسة. والمنطق بسيط: فبمجرد أن يحصل النموذج على إمكانية الوصول إلى البيانات والأدوات وعلى القدرة على تنفيذ إجراءات، يكف عن كونه مجرد واجهة ويصبح عقدة عاملة في النظام.

ويتغير معه أيضاً نمط التهديدات. فإلى جانب المشكلات الكلاسيكية مثل أخطاء التفويض وهجمات الحقن، تضاف المخاطر التي يصفها OWASP Top 10 for LLM Applications: حقن الأوامر (prompt injection)، والمعالجة غير الآمنة لمخرجات النموذج، وتسرب الأسرار عبر السياق، والصلاحيات الواسعة جداً الممنوحة للوكلاء، والتصميم غير الآمن للإضافات (plugins) أو الأدوات (tools). وأظهرت دراسة شملت عدة وكلاء ذكاء اصطناعي صورة متكررة: لدى جميعهم تقريباً وصول إلى shell عبر الأوامر المحلية أو Docker أو SSH، والكثير منهم قادر على العمل مباشرة مع git وإنشاء الفروع وتنفيذ commits، وكثيراً ما تظهر في الإعدادات أوضاع خطرة من نوع bypassPermissions.

وفي مثل هذه البنية يكفي حقن واحد ناجح، أو معالجة غير آمنة لمخرجات النموذج مرة واحدة، لكي ينفّذ الوكيل أمراً عشوائياً، أو يسحب الرموز (tokens) والمفاتيح، أو يعدّل الشيفرة خلسة، أو يبدأ بالتجول في الخدمات الداخلية وسلسلة CI/CD.

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

فإذا كانت هذه الخدمة قادرة على قراءة الملفات وتعديلها، وتشغيل الأوامر، واستدعاء واجهات API الخارجية، ودفع الشيفرة (push)، فيجب فحصها عبر المجالات المألوفة: من الذي يطلق الإجراءات تحديداً، وما الصلاحيات التي يحصل عليها الوكيل، وأين يعمل، وإلى أي مجلدات وشبكات وأدوات يمكنه الوصول، وما الذي يُسجَّل، وإلى أي مدى يرى الفريق الشذوذ بسرعة.

ومن هذا ينبثق ملف حماية عملي تماماً. أولاً، يلزم وضع قواعد واضحة للتفويض وللحد الأدنى من الامتيازات: أي مستودع يراه الوكيل، وهل يمكنه الكتابة أم القراءة فقط، وهل يُسمح له بتشغيل الاختبارات أو عمليات الترحيل (migrations) أو أوامر shell. ثانياً، يكتسب العزل أهمية: حاوية، أو runner منفصل، أو بيئة مخصصة ذات نقاط ربط (mounts) محدودة بصرامة، ودون وصول زائد إلى docker.

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

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

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