الذكاء الاصطناعي
تعد حماية أنظمة الذكاء الاصطناعي أصعب بكثير من حماية تكنولوجيا المعلومات التقليدية — سواء من أخطاء المشغّلين، أو التدخل الخبيث، أو حتى مجرد السلوك غير المستقر. ويرجع ذلك لسببين رئيسيين. أولاً، تعتمد مخرجات الذكاء الاصطناعي على الاحتمالات، لذا يمكن للمطالبة نفسها أن تُعطي إجابات مختلفة مع كل تشغيل. ثانيًا، لا تستطيع النماذج اللغوية الكبيرة (LLMs) الحالية التمييز بدقة وموثوقية بين الأوامر والبيانات. ورغم المشكلات الأمنية المثبتة لأنظمة الذكاء الاصطناعي التي غطيناها مرارًا، من المستحيل تجاهل العائد الاقتصادي المحتمل من تبنيها. ولهذا السبب، تتجاوز العديد من الشركات مرحلة المساعدات البسيطة للذكاء الاصطناعي لتنتقل إلى وكلاء الذكاء الاصطناعي. وينفذ هؤلاء الوكلاء المهام بشكل مستقل، ويمتلكون وصولاً مباشرًا إلى الأدوات نفسها المتاحة للبشر — بدءًا من قراءة قواعد البيانات وصولاً إلى تغيير الإعدادات في عمليات الإنتاج. يبحث خبراؤنا في دراستهم الجديدة كيفية تحديد وتقليص المخاطر الناتجة عن ذلك بوضوح للحد من المشكلات المحتملة إلى أدنى مستوى ممكن. وهو نهج يستعير ويكيف مبادئ المناعة السيبرانية والأمان عبر التصميم.
المبادئ الأساسية للأمان عبر التصميم
تنطبق جميع مبادئ هذا التخصص بصورة شاملة على تصميم أي نظام حاسوبي — بما في ذلك وكلاء الذكاء الاصطناعي. أما وجه الاختلاف، فيكمن في مدى عمق المواءمة وإعادة الصياغة التي يتطلبها كل مبدأ ليتناسب مع سيناريوهات الذكاء الاصطناعي.
- يُعد الأمان عنصرًا مستقلاً وبالغ الأهمية منذ مرحلة التصميم الأولى. وتُحدد الأهداف والافتراضات الأمنية منذ اليوم الأول ويجري الالتزام بها عبر كافة مراحل التطوير. وبالنسبة لوكلاء الذكاء الاصطناعي، ينبغي أن تتضمن هذه الافتراضات ثلاث نقاط رئيسية: (1) التعامل مع النموذج اللغوي بوصفه غير موثوق، (2) اعتبار أي نوع من البيانات الخارجية بيانات خبيثة محتملة، (3) عدم جواز تنفيذ أي إجراءات غير قابلة للإلغاء بشكل ذاتي دون موافقة بشرية إلزامية.
- يُصمم النظام استنادًا إلى فرضية حتمية تعرضه للهجوم.
- يتم تقليص قاعدة الحوسبة الموثوقة وسطح الهجوم إلى الحد الأدنى. ولا يُمنح الوكلاء سوى الأدوات التي يحتاجون إليها فعليًا، وصلاحيات محدودة، وأقل قدر ممكن من السياق. ويُسند إنفاذ سياسات الأمان بالكامل إلى مكونات حتمية: أداة مراقبة السياسات، وبيئة تحكّم الوكيل وتوجيهه، وآليات العزل (صناديق الحماية).
- ينطبق مبدأ الامتياز الأدنى. ويمتلك كل وكيل مجموعة بيانات الاعتماد وصلاحيات الوصول الخاصة به (هويته)، والمقتصرة على الحد الأدنى الضروري لأداء مهامه. وإذا احتاج الوكيل مؤقتًا إلى صلاحيات أعلى، فلا تُمنح له إلا بعد الحصول على موافقة خارجية، على أن تنتهي صلاحيتها بانتهاء المهمة التي تطلبتها تحديدًا.
- يتم عزل المكونات. وهي إحدى أكثر المشكلات المعمارية تعقيدًا وتعددًا في الطبقات داخل الأنظمة القائمة على الوكلاء. وينبغي تشغيل بيئة تحكّم الوكيل وتوجيهه في بيئة معزولة (صندوق حماية أو آلة افتراضية)، مع الفصل التام بين الوكلاء وبعضهم بأقصى قدر ممكن. ويجب الفصل أيضًا بين معالجة البيانات في السياقات الموثوقة وتلك غير الموثوقة. على سبيل المثال، يتولى أحد الوكلاء قراءة طلب السحب وكتابة مسودة التعليمات البرمجية، في حين يراجع وكيل آخر هذا العمل دون أن يطّلع إطلاقًا على النص البرمجي للطلب، والذي قد ينطوي على محتوى خبيث.
- الرفض التلقائي هو القاعدة الحاكمة. وتتبع السياسات الأمنية القاعدة القائلة: “كل ما لم يُسمح به صراحةً فهو محظور”. ويسري هذا المبدأ على استدعاءات الأدوات، والتفاعلات بين الوكلاء وبعضهم، وحركة المرور عبر الشبكة.
- تطبيق مبدأ الدفاع في العمق. حيث ينبغي لتدابير الحماية المختلفة أن تعمل بالتزامن وأن يُعزّز بعضها بعضًا. ولا يمكن لآليات الدفاع الاحتمالية — مثل حواجز حماية الذكاء الاصطناعي (وهي بمثابة “جدار حماية” للنماذج اللغوية) أو المحاذاة (إدراك النموذج الذاتي لما هو مقبول وما هو غير مقبول) — أن تقدم أي ضمانات أمنية قطعية (رسمية). ومع ذلك، فإنها ترفع مستوى أمان النظام ككل، وتُشكّل مصدرًا قيّمًا لبيانات القياس عن بُعد.
- حماية سلسلة التوريد. يستطيع بعض الوكلاء تثبيت المهارات، والمكتبات البرمجية، والمكونات الأخرى ذاتيًا، ومن ثمّ تتطلب هذه القدرات ضوابط وقواعد صارمة، إما بحظرها تمامًا، أو بقصرها على قائمة مغلقة ومُعتمدة مسبقًا لإصدارات محددة من مكونات بعينها. وتواجه الأنظمة القائمة على النماذج اللغوية الكبيرة السحابية خطرًا إضافيًا يتمثل في: تحديثات النماذج. وقد يتم الرد على طلب واجهة برمجة التطبيقات (API) نفسه في يوم ما بواسطة نموذج لغوي مختلف يحمل خصائص أمنية متباينة.
مزالق أمان الذكاء الاصطناعي
إن المبادئ العامة للأمان عبر التصميم معروفة جيدًا وتبدو بسيطة على الورق، غير أن تطبيقها على أنظمة الذكاء الاصطناعي أمر بالغ التعقيد نظرًا للمرونة الفائقة التي يتمتع بها الوكلاء. على سبيل المثال، قد يعتقد فريق الأمان أن الوكيل الذي يعمل على كمبيوتر المطور محصور داخل صندوق حماية ولا يمكنه تعديل أي شيء خارجه. لكن المهاجم — أو حتى الوكيل نفسه — قادر على ابتكار عشرات الطرق للالتفاف على هذه الحماية التي تبدو متينة في ظاهرها: بدءًا من تشغيل الأوامر عبر خادم بروتوكول سياق النموذج (MCP) المحلي الذي لا تقيده بيئة العزل، وصولاً إلى إعادة تكوين وكيل ذكاء اصطناعي آخر مثبت على النظام. ومما يزيد الأمر صعوبة، أن نطاق مسارات الهجوم شاسع للغاية: يمتد من الحقول العشوائية في ملف تكوين الوكيل، إلى سلاسل نصية تبدو بريئة تماماً داخل ملف المهارة.
تتمثل إحدى المشكلات الخطيرة التي كثيرًا ما يستهين بها المصممون في إنهاك المستخدم. حيث يستطيع الوكيل النشط إطلاق عشرات الطلبات في الدقيقة الواحدة، طالبًا من المستخدم تأكيد إجراءات قد تنطوي على خطورة. وخلال ساعة واحدة، يجد الشخص نفسه ينقر على زر موافقة تلقائيًا دون قراءة ما يوافق عليه فعليًا. ولهذا السبب، من الضروري ضبط كل من وتيرة ظهور هذه الطلبات وصياغتها اللغوية بعناية فائقة. ولن يقرأ أحد وصفاً طويلاً ومستفيضًا للطلب، في حين أن الوصف المقتضب للغاية قد يحجب التفاصيل الجوهرية التي يحتاجها المستخدم لاتخاذ القرار السليم.
تُعد الثغرات الأمنية في الوكلاء والأدوات المرتبطة بهم معضلة ملحة — ويزداد تفاقمها بفعل الوتيرة المتسارعة لتطور هذه الفئات من البرامج وتدفق تحديثاتها. فالمنصات والتطبيقات المتوافقة مع المعايير في هذا القطاع — مثل LangGraph وMicrosoft Semantic Kernel وClaude Code — خضعت لتصحيح ثغرات أمنية حرجة أكثر من مرة. ولذا، ينبغي لمهندسي المعمارية دائمًا التفكير في استبدال أطر العمل الضخمة ومتعددة الأغراض بنظام مدمج ومقتضب يقتصر فقط على المزايا والوظائف التي يحتاجها وكيل معين بالفعل.
علاوة على ذلك، يُسهم التطبيق الدقيق لتدابير الأمان القياسية والراسخة داخل الأدوات المتاحة في الحد بدرجة كبيرة من الأضرار في حال تعرّض الوكيل لهجوم أو سلك مسارًا غير متوقع. ومن الأمثلة على ذلك: اعتماد قائمة سماح صارمة للنطاقات التي يُسمح لأداة جلب محتوى الويب بفتحها بناءً على طلب الوكيل. غير أن المصممين نادرًا ما يضعون في الحسبان المشكلات الخفية والعبء التشغيلي المرتبط بصيانة هذه القائمة. ونتيجة لذلك، تصبح القائمة متقادمة تدريجيًا وتترك ثغرات يستغلها المهاجمون. ولعل أبرز مثال على ذلك هو هجوم EchoLeak. ولدى نظام Microsoft 365 Copilot قائمة سماح مطبقة بطريقة صحيحة وفعالة إلى حد كبير للوصول إلى المواقع الخارجية، إلا أن المهاجمين تمكنوا من الالتفاف عليها عبر خاصية في أداة ثانوية ونطاق خدمة MS Teams.
نصائح عملية لمهندسي المعمارية وفرق الأمان
ينبغي لمهندسي معمارية أنظمة الذكاء الاصطناعي ورؤساء الفرق الهندسية والأمنية تضمين أمان الوكلاء منذ مرحلة التصميم الأولى. وينبغي عليهم الاعتماد أساسًا على آليات حتمية قابلة للتحقق مثل: عزل المكونات، والتحكم في التفاعلات، وتقليص قاعدة الحوسبة الموثوقة إلى الحد الأدنى.
تشمل القرارات الهيكلية الرئيسية تحديد مستوى الاستقلالية المقبول للوكلاء، وتقييد الوصول إلى البيانات السرية ومجموعات القدرات الخطيرة المتداخلة، واستخدام صناديق الحماية، وفصل الأدوار بين النماذج المختلفة، وتوظيف بوابات التحكم في الوصول. ومع أن القيود المضافة كفكرة لاحقة تحد من المخاطر، إلا أنها لا تشكل بأي حال بديلاً عن المعمارية الآمنة.
على المستويين المؤسسي والتشغيلي، يتعين على الشركات الاحتفاظ بحصر شامل لوكلائها، وتنسيق الجهود بين فرق الأمان وفرق النشر، وتأمين بيئات الحاويات، وإدارة سلسلة التوريد (قائمة مكونات الذكاء الاصطناعي – AIBOM)، ودمج منظومة دفاع متعددة الطبقات.
تتطلب إمكانية المراقبة عناية خاصة. وينبغي لها في أنظمة الذكاء الاصطناعي أن تشمل تسجيل طلبات النموذج اللغوي الكبير واستجاباته وتسلسل تفكيره واستدلاله، إلى جانب بيانات القياس عن بُعد المفصلة الواردة من الأنظمة المضيفة والبيئات السحابية التي تعمل فيها بيئة تحكم الوكيل وتوجيهه.
يتمثل الجزء الأصعب في تصميم الوكلاء في تحقيق التوازن بين الأمان والأداء والجدوى العملية. ولمعرفة كيفية الوصول إلى هذا التوازن عبر نمذجة التهديدات وتحديد أهداف أمنية واضحة، ندعوكم لقراءة النسخة الكاملة من الدراسة.
النصائح