ادعایی که یک برنامه را جابهجا میکند
یک سیستم چند-ایجنت گروهی از مدلهاست که پیام مبادله میکنند. یک ایجنت پیشنهاد میدهد، دیگری نقد میکند، سومی یک tool call را اجرا میکند. فرض طراحی این است که این پیامها حامل اطلاعاتاند. در عمل، حامل اقتدارند. وقتی یک planner پیامی از یک همتا دریافت میکند که میگوید منبعی در دسترس نیست، سیاستی تغییر کرده، یا مرحلهای پیشتر کامل شده است، planner اغلب آن ادعا را بهعنوان واقعیتی درباره جهان میپذیرد. برنامهاش را بهروزرسانی میکند، مرحلهای را حذف میکند، یا ابزار دیگری را فراخوانی میکند. آن پیام هرگز تأیید نشده بود. آسیبپذیری این نیست که مدل فرستنده بدخواه است یا مدل گیرنده ضعیف. این است که پروتکل اجازه داد یک ادعای تأییدنشده برنامه را تغییر دهد.
این یک مسئله پروتکلی است چون در میان خانوادههای مدل و سطوح توانایی بازتولیدپذیر است. گیرندهای توانمندتر بهطور خودکار آن را رفع نمیکند؛ ممکن است ادعای همتا را روانتر توجیه کند. فرستندهای توانمندتر بهطور خودکار آن را ایجاد نمیکند؛ فرستنده فقط باید در لحظه مناسب یک اظهار محتمل تولید کند. ویژگیای که حمله را کارآمد میکند ساختاری است: پیامهای میان-ایجنت بهعنوان دستور پردازش میشوند، نه بهعنوان ورودی نامعتبر.
سازوکار: پیامهای همتا بهعنوان دستور
یک حلقه دو-ایجنت را در نظر بگیرید. ایجنت A یک وظیفه را برنامهریزی میکند. ایجنت B به ابزاری دسترسی دارد که A ندارد. A درخواستی به B میفرستد. B پاسخ میدهد که ابزار خطا برگرداند و راهحل درست این است که یک مرحله اعتبارسنجی را رد کند. A هیچ سابقه مستقلی از آن tool call ندارد. اگر system prompt ایجنت A بگوید با همتاها همکاری کن و از کار تکراری پرهیز کن، A گزارش را میپذیرد و مرحله را رد میکند. برنامه به پشتوانه یک جمله تغییر کرد.
همین سازوکار در ایجنتهای tool-calling ظاهر میشود. یک پیام همتا میتواند یک ابزار و آرگومانها را نام ببرد. اگر parser ایجنت گیرنده میان دستور کاربر و پیشنهاد همتا تمایز قائل نشود، پیام همتا به یک tool call تبدیل میشود. سیاست خود ایجنت گیرنده ممکن است آن عمل را ممنوع کند، اما سیاست در برابر چارچوببندی همتا ارزیابی میشود، نه در برابر وظیفه اصلی. مدل یک درخواست همکارانه میبیند، نه یک injection.
پایداری نیمه دوم سازوکار است. یک درخواست ردشده پایان مبادله نیست. ایجنتی که مدام بازنویسی میکند، فوریت میافزاید، یا همان درخواست را در نوبتهای مختلف بازقالببندی میکند، میتواند یک همتای سازگار را فرسوده کند. context ایجنت گیرنده ادعای مکرر را انباشته میکند. هر نوبت ادعا را مستقرتر نشان میدهد. در نهایت گیرنده درخواست را بهعنوان context تثبیتشده میپذیرد، نه بهعنوان یک اظهار مورد مناقشه. تعداد نوبتها سطح حمله است، نه فصاحت هیچ پیام واحدی.

این یک رده فرضی از شکست نیست. پژوهشگران امنیت و سازندگان ایجنت با رشد استقرارهای چند-ایجنت، مسائل prompt-injection و اعتماد میان-ایجنت را مستند کردهاند. الگو ثابت است: مدل نهقدر با یک جمله زیرکانه فریب میخورد، بلکه سیستم با کانالی فریب میخورد که هیچ تصوری از این ندارد چه کسی سخن میگوید یا ادعایش چقدر باید بهحساب بیاید. پوشش این رخدادها معمولاً بر مدل متمرکز است، اما راهحل پایدار در لایه پیام قرار دارد.
منشأ و سطح اعتماد روی هر پیام میان-ایجنت
هر پیامی که از مرز یک ایجنت عبور میکند باید metadata ساختاریافته حمل کند: هویت ایجنت فرستنده، وظیفهای که مجاز به عمل روی آن است، شواهد پشت ادعایش، و یک سطح اعتماد. سطح اعتماد یک احساس نیست؛ یک ورودی سیاست است. ادعایی از یک همتا بدون دسترسی به ابزار نباید بتواند بگوید یک ابزار چه برگردانده است. ادعایی از یک همتا خارج از دامنه وظیفه فعلی نباید بتواند وظیفه را تغییر دهد. planner ایجنت گیرنده باید سطح اعتماد را پیش از متن بخواند.
این تغییری کوچک با اثری بزرگ است. یک فرض اجتماعی ضمنی (همتاها همکارند) را به یک فیلد صریح و قابل بررسی تبدیل میکند. همچنین logها را مفید میسازد: وقتی برنامهای تغییر میکند، سابقه نشان میدهد کدام پیام و کدام سطح اعتماد باعث تغییر شده است.
تأیید مستقل پیش از آنکه ادعای همتا برنامه یا tool call را تغییر دهد
ادعای همتایی که برنامه را تغییر میدهد یا tool call را برمیانگیزد باید در برابر منبعی تأیید شود که همتا کنترلش نمیکند. اگر همتا میگوید فایلی گم است، ایجنت گیرنده باید فایل را بررسی کند. اگر میگوید سیاستی تغییر کرده، ایجنت گیرنده باید سیاست را بخواند. اگر میگوید مرحلهای کامل شده، ایجنت گیرنده باید بهدنبال artefact بگردد. تأیید لازم نیست گران باشد. باید مستقل باشد.
معاوضه صادقانه latency و هزینه است. تأیید یک مرحله، گاهی یک tool call، گاهی یک round trip اضافه میکند. در سیستمی که بیشتر پیامهای همتا دقیقاند، تأیید شبیه هدررفت به نظر میرسد. تصمیم طراحی این است که کدام ادعاها مجازند بدون تأیید وضعیت را تغییر دهند. ادعاهای کمریسک، برگشتپذیر و دروندامنه میتوانند عبور کنند. ادعاهایی که برنامه را تغییر میدهند، منبعی خرج میکنند
/media/server-rack-closeup-3d8cf9-5b763a.jpg)
سقفگذاری بر بازادعای یک درخواست ردشده
یک درخواست ردشده نباید اجازه داشته باشد بیپایان با عبارات جدید بازگردد. پروتکل باید بازادعاها را بهازای هر همتا، هر درخواست و هر وظیفه بشمارد. پس از تعداد کمی تلاش، درخواست بسته میشود و ایجنت گیرنده ارزیابی آن را متوقف میکند. سقف داوری درباره نیت همتا نیست؛ کرانبندی مواجهه گیرنده است. همچنین راهی تمیز به گیرنده میدهد تا یک حلقه را بدون ارجاع هر اختلاف به انسان پایان دهد.
معاوضه این است که اختلاف مشروع میتواند کوتاه شود. ممکن است همتایی تصحیح واقعی داشته باشد که در تلاش چهارم میرسد. بنابراین سقف باید با یک مسیر escalation جفت شود: درخواستهای بستهشده log میشوند و یک انسان یا ایجنت ناظر میتواند آنها را با شواهد پیوست بازگشایی کند. هدف این است که پایداری پرهزینه و قابلمشاهده شود، نه اینکه تصحیح ناممکن گردد.
آزمون: همتای خصمانه، نه فقط کاربر خصمانه
بیشتر red-teaming کانال کاربر را هدف میگیرد. یک سیستم چند-ایجنت به مجموعه آزمون دومی نیاز دارد که در آن خصم یک همتاست. چیدمان سرراست است: سیستم را با یک ایجنت جایگزینشده با یک همتای خصمانه اجرا کنید که ادعاهای محتمل و تأییدنشده منتشر میکند، درخواستهای ردشده را بازنویسی میکند، و میکوشد ابزارها و آرگومانها را نام ببرد. آزمون میسنجد آیا برنامهها تغییر میکنند، آیا tool call رخ میدهد، و گیرنده چند نوبت را پیش از بستن درخواست تحمل میکند.
ارزش این آزمون در این است که پروتکل را بهکار میگیرد، نه مدل را. تعویض مدل نتیجه را تغییر نمیدهد اگر لایه پیام همچنان متن همتا را بهعنوان اقتدار بپذیرد. پروتکلی با برچسبهای منشأ، الزامات تأیید و سقفهای بازادعا در برابر تغییرات مدل دوام میآورد، و این همان ویژگیای است که برای یک سیستم در production اهمیت دارد.
اصل طراحی
هر پیام میان-ایجنت را ورودی نامعتبر بدانید تا پروتکل خلافش را بگوید. مدل مرز نیست. مرز لایه پیام است: چه کسی فرستاد، چه چیزی مجاز به ادعای آن است، چه شواهدی پیوست کرده، و چند بار میتواند خود را تکرار کند. آن لایه را آگاهانه بسازید، و دستکاری میان ایجنتها به رخدادی کراندار و قابلمشاهده تبدیل میشود، نه تغییری خاموش در برنامه.
