ملخص تقني: من يملك هذا العميل؟ تتبع الوكلاء الذكيين وصولاً إلى مالكيهم

١. تعريف المشكلة: إسناد العميل (Agent Attribution)

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

هذه الفجوة في المساءلة موجودة عبر كامل طيف سلوك الوكيل:

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

في كلتا الحالتين، يلاحظ الأطراف المتضررة (الضحايا) السلوك الضار، ويمتلك المزودون (مزودو النماذج اللغوية الكبيرة LLMs) سجلات الجلسات، ولكن لا يمكن لأي طرف ربط السلوك الخارجي الملحوظ بالحساب المزود (vendor account) المسؤول. تفشل آليات الاسترداد الحالية لأن:

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

يرى المؤلفون أن هذه المشكلة قابلة للتنفيذ بشكل خاص في بيئة النماذج اللغوية الكبيرة المستضافة لدى المزود (vendor-hosted LLM). فحتى المهاجمين المتطورين يعتمدون غالباً على نماذج مستضافة لدى مزودين (مثل OpenAI أو Anthropic أو النماذج مفتوحة المصدر المستضافة) لقدراتها في الاستنتاج. وبينما يتحكم المشغل في وقت التشغيل (runtime) والمغلفات (wrappers)، فإن استدعاءات النموذج تمر عبر المزود ويتم تسجيلها مقابل حساب معين.

٢. المنهجية: بروتوكول القناري (Canary-Based Protocol)

يقترح المؤلفون بروتوكول إسناد يعتمد على "القناري" (Canary) يعمل على سد الفجوة بين ملاحظة الضحية وسجلات المزود. يتضمن البروتوكول خمسة أطراف: الوكيل (Agent)، المشغل (Operator)، المزود (Vendor)، الضحية (Victim)، والسلطة (Authority) (مثل جهات إنفاذ القانون أو كيان تجاري).

الآلية الجوهرية

١. الحقن (Injection): تقوم سلطة مخولة ($\mathcal{D}$) بحقن قناري (canary) في تدفق المحتوى الذي يُحتمل أن يستهلكه الوكيل ($\mathcal{A}$).
* التفاعل المباشر: تتفاعل السلطة مع الوكيل مباشرة (عبر الدردشة مثلاً) وتحقن القناري.
* التفاعل غير المباشر: تضع السلطة قنارٍ في مواقع يُتوقع أن يزورها الوكيل (مثل صفحات ويب محددة أو ملفات) وتزودها بخطافات (hooks).
٢. الانتشار (Propagation): يعالج الوكيل المحتوى. إذا قام الوكيل بتمرير هذا المحتوى إلى النموذج المستضاف لدى مزوده، فسيظهر القناري في سجلات جلسة المزود.
٣. البحث (Search): تبدأ السلطة بطلب إسناد لدى المزود ($\mathcal{V}$)، مع تحديد وقت الحقن ($\tau$) وقيم القناري.
٤. الاسترداد (Recovery): يبحث المزود في نافذة زمنية ضيقة من سجلات الجلسات النشطة بحثاً عن القنارٍ. إذا وُجد، يربط المزود الجلسة بحساب المشغل ($\mathcal{O}$) المسؤول.

بناءات القناري (Canary Constructions)

تميز الورقة بين حالتين، تتطلبان أنواعاً مختلفة من القناري:

• البيئة غير العدائية (Non-Adversarial Setting): حيث لا يحاول المشغل التهرب من الإسناد.

  • القناري المعجمي (Lexical Canaries): تسلسلات رمزية (tokens) بسيطة ومطابقة تماماً (مثل سلاسل نصية عشوائية، أو معرفات فريدة UUID، أو معرفات ذات صلة بالمهمة مثل أكواد المشاريع). وهي كافية لأن الوكيل يمرر المحتوى الوارد إلى النموذج كما هو حرفياً.

• البيئة العدائية (Adversarial Setting): حيث ينشر المشغل مغلفاً ($\mathcal{W}$) لفلترة أو إعادة صياغة أو إعادة كتابة المحتوى الوارد لكبح العلامات.

  • القناري ذات المنفعة (Utility-Bearing Canaries): لمواجهة التهرب، قدم المؤلفون قنارٍ تكون غير قابلة للتمييز عن محتوى المهمة المشروع. إزالة هذه القنارٍ ستؤدي إلى تدهور قدرة الوكيل على أداء مهمته.
  • القناري المعجمية ذات المنفعة: معرفات حرجة للمهمة (مثل أسماء الملفات في قائمة دليل، أو معرفات محددة في استعلام قاعدة بيانات) التي يجب على الوكيل الحفاظ عليها للنجاح.
  • القناري الدلالية (Semantic Canaries): بصمات محددة بالمعنى بدلاً من الشكل السطحي (مثل أساليب الكلام، أو الأنماط الهيكلية، أو إشارات الاستعجال، أو العادات البلاغية المحددة). هذه تصمد أمام إعادة الصياغة بشكل أفضل من النصوص الصريحة.
  • استراتيجية القناري المتعددة (Multi-Canary Strategy): تقوم السلطة بأخذ عينة ($K$) من كونٍ واسع للقنارٍ ($N$) وتقوم بحقنها. يتطلب الكشف عن حد أدنى ($m$) من المطابقات. وهذا يخلق عدم تماثل لصالح المدافع (defender-favorable asymmetry): يجب على المهاجم تصفية المحتوى بقوة لإزالة القنارٍ، مما يؤدي حتماً إلى تدهور منفعة الوكيل، بينما يمكن للمدافع رفع احتمالية الإسناد إلى ما يقرب من ١.

٣. المساهمات الرئيسية

١. صياغة المشكلة: هذا هو العمل الأول الذي يحدد ويعرف "إسناد الوكيل" كمشكلة أمنية متميزة ويصنف كافة سيناريوهات الهجوم (غير المقصود مقابل المتعمد، وأنواع الأهداف المختلفة).
٢. بروتوكول عملي: بروتوكول إسناد يتوسط فيه المزود، يعمل دون الحاجة لتسجيل مسبق شامل أو كشف مستمر للهوية. وهو يعتمد على التبعية الهيكلية للوكلاء للنماذج المستضافة لدى المزودين.
٣. بناءات قناري قوية:
* تطوير قنارٍ ذات منفعة (معجمية ودلالية) تخلق مقايضة للمهاجمين: التهرب من الإسناد يتطلب تدهور أداء الوكيل.
* صياغة عدم التماثل حيث يمكن للمدافع التحكم في احتمالية الإسناد بينما يدفع المهاجم تكلفة المنفعة مقابل التهرب.
٤. التقييم التجريبي: اختبار شامل عبر ثلاثة مجالات:
* وكلاء التواصل: تفاعلات الدردشة والمنتديات.
* وكلاء الويب: استيعاب وثائق HTML والزحف (scraping).
* الوكلاء السيبرانيون: الوكلاء الذين يستخدمون الأدوات بشكل مستقل في بيئات "التقاط العلم والتربيع" (CTF).

٤. النتائج التجريبية

أظهر التقييم أن البروتوكول موثوق، قوي، وقابل للتوسع.

• الأداء في البيئة غير العدائية:

  • حققت القناري المعجمية كشفاً شبه مثالي (TPR $\approx$ 1.0) مع معدل إنذار كاذب (FPR) يقترب من الصفر عندما يتم تمرير المحتوى دون تغيير.
  • حققت القناري الدلالية أيضاً معدلات كشف عالية (AUC $\approx$ 0.98–0.99) في بيئات الدردشة والمنتديات.

• المتانة ضد الهجمات العدائية:

  • هجمات إعادة الصياغة: عندما يقوم المغلف بإعادة صياغة المحتوى، تفشل القناري المعجمية الدقيقة (ينخفض TPR إلى $\approx$ 0.20). ومع ذلك، تظل القناري الدلالية قوية. في بيئات الدردشة، يظل TPR فوق 0.97 حتى تحت إعادة الصياغة عند استخدام عتبة القناري المتعددة ($m$-of-$k$).
  • وكلاء الويب: القناري المعجمية المرئية (المدمجة في النص المعروض) تصمد أمام المعالجة المسبقة وإعادة الصياغة بمعدلات $>60\%$. أما القناري الهيكلية (المخفية في DOM) فهي أكثر هشاشة. وتوفر القناري الهيكلية الدلالية قناة ثانوية قوية.
  • الوكلاء السيبرانيون (CTF): هذا هو الاختبار الأقوى. تسبب مهاجم مدرك لوجود القناري في محاولة إزالة القنارٍ من مخرجات الأدوات في انهيار معدل حل الوكيل من 51% إلى 9%. وهذا يؤكد مقايضة (المنفعة-التهرب): قمع أدلة الإسناد يدمر مهمة الوكيل.
  • دقة الإسناد: في البيئات السيبرانية، حقق الإسناد على مستوى الجلسة نسبة TPR $\ge$ 98% مع FPR يقترب من الصفر، حتى في الظروف العدائية.

• القابلية للتوسع:

  • أظهر البحث أن البحث من جانب المزود عملي تشغيلياً. من خلال البحث فقط في نافذة زمنية محدودة من الجلسات المتزامنة واستخدام مطابقة مستوى الـ tokens (بالاستفوة من سجلات الـ tokenized)، تكون تكاليف البحث متناسبة خطياً مع عدد الجلسات النشطة، وليس مع إجمالي حجم السجلات. وقد وُجد أن البحث على مستوى الـ token أسرع بحوالي ضعفين ($\approx$2x) من المطابقة على مستوى الحروف (character-level).

٥. الأهمية والادعاءات

تدعي الورقة أنها أول عمل يحدد إسناد الوكيل ويقدم حلاً عملياً. تكمن أهميتها في:

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

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