التلاعب بين الوكلاء مشكلة بروتوكول

الادعاء الذي يحرّك خطة

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

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

الآلية: رسائل النظير كتعليمات

تأمّل حلقة بين وكيلين. الوكيل A يخطط لمهمة. الوكيل B يملك وصولاً إلى أداة لا يملكها A. يرسل A طلباً إلى B. يردّ B بأن الأداة أعادت خطأً وأن الحل الصحيح هو تخطي خطوة تحقق. لا يملك A سجلاً مستقلاً بذلك tool call. إذا كان system prompt الخاص بـ A يقول بالتعاون مع النظير وتجنّب العمل المكرر، سيقبل A التقرير ويتخطى الخطوة. تغيّرت الخطة بقوة جملة.

الآلية نفسها تظهر في الوكلاء الذين يستدعون الأدوات. رسالة النظير يمكن أن تسمّي أداة ووسائط. إذا لم يميّز محلّل المستقبِل بين تعليمة مستخدم واقتراح نظير، تصبح رسالة النظير tool call. قد تحظر سياسة المستقبِل نفسه الإجراء، لكن السياسة تُقيَّم مقابل تأطير النظير لا مقابل المهمة الأصلية. يرى النموذج طلباً تعاونياً، لا حقناً.

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

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

المصدر ومستوى الثقة على كل رسالة بين الوكلاء

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

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

التحقق المستقل قبل أن يغيّر ادعاء نظير خطة أو tool call

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

المقايضة الصادقة هي زمن الاستجابة والكلفة. يضيف التحقق خطوة، وأحياناً tool call، وأحياناً رحلة ذهاب وإياب. في نظام تكون فيه معظم رسائل النظير دقيقة، يبدو التحقق هدراً. قرار التصميم هو أي الادعاءات يُسمح لها بتغيير الحالة دون تحقق. الادعاءات منخفضة المخاطر، القابلة للعكس، وداخل النطاق يمكن أن تمر. الادعاءات التي تغيّر خطة، أو تستهلك مور/media/server-rack-closeup-3d8cf9-5b763a.jpg)

وضع حد لإعادة تأكيد طلب مرفوض

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

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

الاختبار: نظير خصمي، لا مستخدم خصمي فقط

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

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

مبدأ التصميم

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