يحتاج وكلاء الذكاء الاصطناعي إلى حدود أمان لا يمكنهم تعديلها

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

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

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

أمّن الإجراء، ليس النموذج فقط

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

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

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

امنح كل وكيل هوية وتفويضًا ضيقًا

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

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

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

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

احتفظ بالتفويض خارج حلقة التفكير

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

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

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

احفظ موافقة الإنسان للحظات المهمة

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

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

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

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

راقب السلوك واحفظ الأدلة

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

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

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

صمم مسار الإيقاف قبل الإطلاق

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

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

الهدف هو الاستقلالية المسؤولة

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

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

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

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

ما الحمايات والبوابات التي سيحصلون عليها؟

تقدم وفقًا لذلك.