ثمانية افتراضات أمنية تحطّمها الوكلاء الذكية: من أسبوعين إلى عشر ساعات

حين يستطيع المهاجم أن يتحمّل الفشل

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

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

ثمانية أخطاء حرجة يجب إعادة النظر فيها

1. استعدّوا لمهاجم يستطيع أن يتحمّل الفشل

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

2. قيسوا الزمن من الكشف إلى الاحتواء

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

3. احموا البيئة المحيطة، لا النموذج فقط

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

4. استعدّوا لأسراب من الوكلاء

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

5. كفى منح الوكلاء بيانات اعتماد دائمة

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

6. افترضوا أن حقن التوجيهات (prompt injection) سينجح

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

7. ضعوا الحد الأمني خارج النموذج

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

8. احموا أنفسكم من الوكلاء بوكلاء

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

لا بد من مجاراة المهاجمين بالاستفادة من الذكاء الاصطناعي، وفي الوقت نفسه تجنّب خلق مشكلة أمنية جديدة.