تأمين الوكلاء عبر نقاط نهاية عملاء Perplexity باستخدام Numbat

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

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

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

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

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

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

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

البنية النظامية للوكلاء المحميين بواسطة Numbat. يركز Numbat على الاكتشاف المحلي أولاً والتحليلات الجنائية المستقلة عن الوكيل.

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

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

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

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

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

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

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

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

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

نقاط التكامل الرئيسية بين Numbat وتسخير الوكيل هي الخطافات، وعناصر الجلسة، وقياسات OTLP. نناقش كل منها تباعاً.

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

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

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

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

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

وبالتالي، يسترد Numbat عناصر الجلسة مباشرة من نظام الملفات نفسه. ونظراً لأن معظم تسخير وكلاء جانب العميل تخزن العناصر الأصلية على نظام الملفات (عادةً داخل دليل نقطة خاص بالوكيل تحت $HOME)، فإن الاستفادة من نظام الملفات توفر الطريق الأكثر مباشرة لهذه البيانات في شكلها الأكثر قابلية للاستخدام والنقاء. يمكن لفرق الأمان التي تستخدم Numbat جمع هذه العناصر بتنسيق خط زمني NDJSON مُطبع من خلال numbat scan, إما للمعالجة المحلية على نقطة نهاية العميل أو التحليل البعيد غير المتزامن. ونظراً لأن عناصر الجلسة هي سجلات ثابتة ومكتفية ذاتياً، فإن Numbat قادر على إعادة بناء هذه الجداول الزمنية حتى بالنسبة للجلسات التي حدثت قبل وقت طويل من تثبيت Numbat.

توفر معظم تسخير وكلاء جانب العميل قياسات واسعة النطاق من خلال بروتوكول OpenTelemetry (OTLP). توفر هذه القياسات عادةً العديد من الإشارات التي تتجاوز تلك المتاحة من خلال الخطافات أو عناصر الجلسة.

يمكن أن يعمل Numbat كمستقبل OTLP عبر الأمر numbat collect. يبدأ هذا الأمر خادمًا ترسل إليه وكلاء التشفير قياسات OTLP للتحليل اللاحق. والأهم من ذلك أن هذا الخادم محلي ويستمع افتراضيًا فقط على المضيف المحلي، مما يعني أن جميع القياسات تبقى على الجهاز بشكل افتراضي. يمكن لمسؤولي الأمان بعد ذلك تحديد ما يجب فعله بالقياسات المسجلة، سواء كان ذلك يتضمن تنفيذ معالجة خفيفة الوزن على الجهاز، أو معالجة عن بُعد عبر numbat ship، أو تحليل أكثر تعقيدًا على منصات التحليلات مثل ClickHouse.

داخل Perplexity، نستخدم Numbat لتأمين استخدام مهندسينا لوكلاء التشفير من جانب العميل بما في ذلك Claude Code، وCodex، وOpenCode، وPi.

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

على سبيل المثال، تكتشف القاعدة المدمجة privilege.sudoers_tamper عمليات الكتابة على سياسة sudoers، واستخدام visudo، ومحاولات تثبيت منح NOPASSWD. هذه إجراءات ذات إشارة عالية يمكنها تحويل عملية وكيل محدودة إلى وصول جذري دائم.

yaml

# privilege.sudoers_tamper (simplified for readability)
id: privilege.sudoers_tamper
severity: high
expr: |
  (
    event.event_type == "file.write" &&
    event.file_path.matches("(^|/)etc/sudoers$|(^|/)etc/sudoers\\.d/[^/]+$")
  ) || (
    event.event_type == "command.exec" &&
    event.command.matches("\\bvisudo\\b|\\bNOPASSWD\\s*:")
  )

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

yaml

# chain.secret_manager_read_then_egress (simplified for readability)
id: chain.secret_manager_read_then_egress
severity: high
sequence:
  within_events: 64
  steps:
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("secretsmanager|get-secret|vault read")
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("curl.*(--data|--upload-file)|wget.*--post")

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

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

خط الأنابيب الداخلي لـ Perplexity لمراقبة قياسات Numbat. تقوم مهمة Perplexity Computer المجدولة بمراجعة الإشارات والتنبيهات الجديدة غير المتزامنة لفريق الأمان بشأن النشاط المحفوف بالمخاطر.

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

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

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

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

يتوفر Numbat اليوم كـ مشروع مفتوح المصدر لنظام التشغيل macOS، وLinux، وWindows. نقاط نهاية عملائنا محمية بواسطة Numbat، مما يُمكّن أعضاء فريق Perplexity من استخدام الوكلاء بثقة عبر مهام واسعة النطاق وآفاق زمنية طويلة. ندعو فرق الأمان في كل مكان للاستفادة من نهج Numbat على مستوى النظام لتمين وحماية عمليات نشر الوكلاء الخاصة بهم.

BibTeX

@online{perplexity2026SecuringAgentsAcrossPerplexitySClientEndpointsWithNumbat,
  author = {{Perplexity} and Adel Karimishiraz and Bex Brooker and Phi Hoang and Jerry Ma},
  title = {{Securing agents across Perplexity's client endpoints with Numbat}},
  date = {2026-07-29},
  url = {https://perplexity.coolkeypoint.com/hub/blog/securing-agents-across-perplexity-s-client-endpoints-with-numbat}
}

مقدمة

تحديد مشهد الثغرات الأمنية

تأمين وكلاء التشفير من خلال عمليات التكامل الأصلية للتسخير

الخطافات

عناصر الجلسة

قياسات OTLP

نشر Numbat داخل Perplexity

إدارة ومراقبة Numbats عبر الأسطول

خاتمة

اقتباس