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

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

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

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

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

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

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

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

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