كيف نصمم وكلاء أكثر أماناً

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

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

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

سلوك الانهيار لوكلاء الذكاء الاصطناعي

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

هذا الحادث هو مثال واضح على وضع الفشل الذي وصفناه عندما قمنا بإتاحة Numbat كمصدر مفتوح في يوليو: الانهيارات العرضية, وهو مصطلح صاغه باحثو أمان من Cornell Tech (arXiv). يواجه الوكيل الذي يسعى لتحقيق هدف مشروع عقوبة، مثل ملف مفقود، أو استدعاء API فاشل، أو اعتماد منتهي الصلاحية، أو رفض إذن، فيبحث عن حل بديل. وفي أثناء قيام بذلك، قد يتجاوز حدود الأمان من خلال الاستطلاع، أو تصعيد الامتيازات، أو اكتشاف الأسرار، أو استخراج البيانات. يصبح الوكيل نفسه فعلياً هو الخصم، على الرغم من عدم وجود مطالبة خبيثة أو مهاجم خارجي.

لم تكن Hugging Face حالة معزولة. فقد تم اكتشاف والإبلاغ عن المزيد من سلوكيات انهيار الوكيل في الأسابيع الأخيرة. في 27-28 مايو، واجهت الوكلاء التي تحاول جمع بيانات جامعة آيوا من Data USA، وهي منصة توفر وصولاً مفتوحاً إلى بيانات الحكومة الأمريكية، أخطاء ناتجة عن استعلام مصمم بشكل خاطئ. واستجابت باستخدام فحوصات، بما في ذلك حقن SQL، والبرمجة النصية عبر الموقع (XSS)، وححقن القوالب، واجتياز المسار، وحقن الأوامر. وقد تم ربط هذا النشاط لاحقاً بشركة OpenAI (SecurityWeek). في 20-21 يونيو، مُنعت الوكلاء التابعة لـ OpenAI والتي كانت تحاول الحصول على التكاليف الحكومية لكل شخص لفئة من الأدوية عبر المناطق المحلية في فيكتوريا من المعهد الأسترالي للصحة والرعاية (AIHW) من تنزيل ملف. ونتيجة لذلك، قامت الوكلاء بتنزيل الملف، الذي كان متاحاً للعامة بالفعل، من خادم مرحلة ما قبل الإنتاج التابع لـ AIHW، متجاوزةً بذلك حماية الموقع ضد الروبوتات في هذه العملية (SecurityWeek).

هذا النمط ليس مقصوراً على مختبر واحد. فخلال اختبارات الأمن السيبراني، اخترقت نماذج Anthropic ثلاث شركات بعد أن منحهم خطأ ما حق الوصول المفتوح إلى الإنترنت، وحزر Gemini من Google بيانات الاعتماد لثلاثة مواقع ويب، واستخدم نموذج من Meta خدمة طرف ثالث (Reuters).

التعلم من التاريخ: عصر ديدان الإنترنت

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

في 4 مايو 2000، بدأ الأشخاص في تلقي رسائل بريد إلكتروني من مرسلين مألوفين تحمل عنوان "ILOVEYOU". وأدى فتح المرفق في البريد الإلكتروني إلى تشغيل نص برمجية يرسل نسخة من نفسه إلى كل شخص في دفتر عناوين Outlook الخاص بالضحية. بحلول الساعة 6 مساءً من ذلك اليوم، تلقى مركز التنسيق CERT تقارير تتعلق بأكثر من 420,000 مضيف إنترنت (تقرير مكتب المساءلة الحكومية الأمريكي). وتفيد التقارير بأن الفيروس اخترق 14 وكالة فيدرالية على الأقل، بما في ذلك وزارة الدفاع، ووكالة المخابرات المركزية، وناسا، ومجلس النواب ومجلس الشيوخ (تقرير مكتب المساءلة الحكومية الأمريكي). كما أدى إلى تعطل خوادم البريد الإلكتروني في البنتاغون والبرلمان البريطاني (Wired). وقدّرت شركة التأمين العملاقة Lloyd's of London تقديراً مبدئياً بأن الفيروس سيكلف أكثر من 15 مليار دولار في شكل أضرار وفقدان في الإنتاجية (جلسة استماع لجنة النواب الأمريكي). وقدرت Computer Economics لاحقاً الأضرار بـ 8.75 مليار دولار في جميع أنحاء العالم (Information Week).

جاءت بعد ذلك الديدان التي لم تكن بحاجة إلى نقرة بشرية. في 19 يوليو 2001، أصاب ديدان Code-Red أكثر من 359,000 جهاز كمبيوتر في أقل من 14 ساعة (CAIDA). وفي 25 يناير 2003، ضاعف SQL Slammer حجمه كل 8.5 ثانية وأصاب أكثر من 90% من مضيفين الإنترنت المعرضين للخطر في غضون 10 دقائق (CAIDA)، مستغلاً ثغرة أصدرت Microsoft تصحيحاً لها قبل ستة أشهر (CNET). وفي أغسطس 2003، ظهر ديدان Blaster وديدان البريد الإلكتروني Sobig بفارق أسبوع تقريباً (Microsoft, F-Secure).

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

استجابت الصناعة بالهندسة. بعد أحد عشر يوماً من ILOVEYOU، أعلنت Microsoft عن تحديث لـ Outlook يحظر المرفقات القابلة للتنفيذ. وفي يناير 2002، جعلت الشركة الأمان أولوية قصوى (Seattle Times). وأصبحت التصحيحات التلقائية، والإعدادات الافتراضية الآمنة، وبرامج مكافحة الأخطاء، والكشف المنسق ممارسات قياسية. وفي عام 2008، بدأت Chrome في تشغيل محتوى الويب في بيئة اختبار "تحد [مما] يمكن للمهاجم فعله بعد استغلال خطأ ما" (مدونة Chromium). وأصبح التشفير، الذي كان استثناءً سابقاً، هو الوضع الافتراضي. أصبحت تقنيات الأمان، بما في ذلك المصادقة متعددة العوامل، جدران الحماية، والثقة المعدومة، وإدارة معلومات الأمان والأحداث (SIEM)، تستخدم على نطاق واسع. تشير التوقعات إلى أن المؤسسات في جميع أنحاء العالم ستنفق حوالي 240 مليار دولار في عام 2026 على أمن المعلومات (Gartner). لم تختفِ الديدان تماماً، لكن عصر تفشي الفيروسات الروتينية على نطاق الإنترنت قد خفت. وفي الوقت نفسه، أصبح الإنترنت، غير المقيد إلى حد كبير بالتنظيم، محركاً قوياً للابتكار والنمو الاقتصادي خلال العقدين التاليين.

هندسة الأمان للوكلاء الذكيين

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

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

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

مبدأ الأمان القائم على الدفاع العميق

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

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

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

تكبير

قواعد التصميم لضمانات الحماية الزائدة

يتطلب الدفاع العميق ضمانات حماية زائدة. بالنسبة للوكلاء، ندعو إلى تطبيق ذلك باستخدام ثلاث قواعد تصميم:

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

نحن نشارك هذه المبادئ مع شركائنا في تحالف الذكاء الاصطناعي الآمن المفتوح (Open Secure AI Alliance)، بما في ذلك NVIDIA، التي زعمت أن الأداة توجه ما يحاول الوكيل القيام به بينما تتحكم البنية التحتية في ما يمكنه فعله (NVIDIA).

الدفاع العميق في منتجات Perplexity

تقوم Perplexity بتشغيل الوكلاء في أربعة أنواع من البيئات: في السحابة من خلال منصة الوكيل الخاصة بنا Computer, في المتصفح من خلال Comet, وعلى أجهزة المستخدمين من خلال Portable Computer, وعلى أجهزة الكمبيوتر المحمولة للموظفين، حيث يستخدم مهندسونا وكلاء ترميز من طرف ثالث. لكل بيئة مخاطرها الخاصة، وتحصل كل منها على عدة طبقات حماية.

في السحابة: Computer و SPACE

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

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

في المتصفح: Comet و BrowseSafe

استخدمت Comet دفاعاً متعدد الطبقات ضد حقن المطالبات منذ إطلاقها: تقوم المصنفات بفحص المحتوى المسترد، والمطالبات المنظمة تعرّفه على أنه غير موثوق به، والإجراءات الحساسة مثل إرسال بريد إلكتروني أو تقديم طلب تتطلب تأكيد المستخدم، ويتم إعلام المستخدم عندما يتم حظر شيء ما (دفاعات حقن المطالبات في Comet). يتفوق BrowseSafe، وهو نموذج الكشف مفتوح المصدر وراء الطبقة الأولى، على النماذج الرائدة في معيار BrowseSafe-Bench الخاص بنا، ومع ذلك يظهر نفس المعيار أن أي كاشف ليس آمناً تماماً، ولهذا السبب لا يُعد الاكتشاف أبداً الطبقة الوحيدة (بحوث BrowseSafe). يرث Computer هذه الدفاعات، والتي تم تدقيقها بواسطة Trail of Bits (Perplexity).

على الجهاز: Portable Computer

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

على نقطة النهاية: Numbat

تعمل وكلاء البرمجة على أجهزة الكمبيوتر المحمولة للمطورين لساعات مع إمكانية الوصول إلى الشيفرة المصدرية وبيانات الاعتماد وأنظمة الإنتاج. يضيف Numbat، وهو جناح أمان الوكيل مفتوح المصدر الخاص بنا، طبقة مستقلة تقع خارج أي وكيل فردي. وهو يعمل مع أدوات مثل Claude Code و Codex و OpenCode و Pi، ويحظر الإجراءات الخطيرة قبل تشغيلها، ويحدد التسلسلات المشبوهة متعددة الخطوات مثل قراءة سر ثم إرسال البيانات إلى الخارج، ويحافظ على الجداول الزمنية للجلسة من أجل التحقيق. يعمل Numbat عبر الآلاف من نقاط نهاية Perplexity جنباً إلى جنب مع Bumblebee، مسح سلسلة توريد البرمجيات مفتوح المصدر الخاص بنا. ويراجع Computer بانتظام نتائجهم ويقترح قواعد اكتشاف محسنة، ويوافق الموظف البشري على كل تغيير قبل طرحه.

مهمة للصناعة بأكملها

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

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

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