پروتکل همان محیط پیرامونی است
لایه‌های انتقال به سبک MCP برای یک فراخوانِ واحد و مورد اعتماد که ابزارها را فرامی‌خواند ساخته شده‌اند. در آن مدل، لایه انتقال یک لوله است: فریم‌های JSON-RPC را بین یک کلاینت و یک سرور جابه‌جا می‌کند و تصمیم‌های امنیتی مهم بالاتر از آن، در پیاده‌سازی ابزار، گرفته می‌شوند. وقتی همان لایه انتقال برای عامل‌های همتا با هویت‌های متفاوت به کار می‌رود، این لوله به محیط پیرامونی تبدیل می‌شود. هر گامی که درخواست را دوباره سریال‌سازی می‌کند، جایی است که منشأ پیام از دست می‌رود. پیامی که به‌عنوان درخواست کاربر آغاز شده، توسط یک عامل برنامه‌ریز بازنویسی شده و توسط یک عامل بازیابی ارسال شده، به سرور ابزار می‌رسد بدون هیچ نشانه قابل اعتمادی از اینکه چه کسی چه چیزی را خواسته است.
درهم‌آمیختن کشف قابلیت و مجوزدهی به قابلیت این وضعیت را بدتر می‌کند. کشف به این پرسش پاسخ می‌دهد: «این نقطه پایانی چه کاری می‌تواند انجام دهد؟» مجوزدهی پاسخ می‌دهد: «آیا این هویت مجاز است آن قابلیت را برای این وظیفه فراخوانی کند؟» رجیستری‌های به سبک MCP معمولاً اولی را آشکار می‌کنند و دومی را به فراخوان واگذار می‌کنند. در مدل تک‌فراخوان این قابل دفاع است. در مدل عامل همتا یعنی هر عاملی که بتواند به رجیستری برسد می‌تواند کل سطح قابلیت را برشمارد و فراخوانی را بیازماید، و عامل گیرنده هیچ مبنای سطح‌انتقالی برای رد کردن ندارد. رجیستری به نقشه‌ای از سطح حمله تبدیل می‌شود که به هر شرکت‌کننده داده شده است.
این نقص MCP به‌عنوان یک پروتکل ابزار نیست. گسترش یک پروتکل ابزار به پیام‌رسانی همتا بدون بازبینی مدل اعتمادش، یک خطای مقوله‌ای است. پرسش مرتبط این نیست که آیا فریم‌ها خوش‌ساخت هستند، بلکه این است که آیا لایه انتقال می‌تواند تصدیق کند چه کسی آن‌ها را فرستاده، به نمایندگی از چه کسی، و تحت چه محدودیت‌هایی.
جعل هویت بین عامل‌هایی که یک فضای نام مشترک دارند
وقتی عامل‌ها با یک رشته در یک فیلد پیام شناسایی می‌شوند نه با یک هویت رمزنگارانه، هر عاملی می‌تواند هر هویتی را ادعا کند. در یک ازدحام که یک برنامه‌ریز یک کارگر را با نام خطاب می‌کند، یک کارگر به‌خطرافتاده یا صرفاً دارای اشکال می‌تواند پیام‌هایی بفرستد که به‌نظر می‌رسد از برنامه‌ریز آمده‌اند. عامل‌های پایین‌دستی هیچ راهی برای تشخیص دستور اصیل از جعلی ندارند، چون لایه انتقال نه امضایی حمل می‌کند و نه اتصال کانالی. شکست بی‌صدا است: پیام جعلی خوش‌ساخت است، قابلیت وجود دارد، و فراخوانی موفق می‌شود.
جریان‌های نماینده گیج‌شده
یک عامل کم‌اختیار یک فراخوان پُراختیار را بازپخش می‌کند. این هر زمان رخ می‌دهد که لایه انتقال اتصال را مجاز می‌کند نه پیام را. عاملی که برای کار مشروع خود یک اعتبارنامه گسترده دارد می‌تواند وادار شود آن اعتبارنامه را به نمایندگی از فراخوانی که نباید آن را داشته باشد به کار ببرد. نماینده بدخواه نیست؛ دارد همان کاری را می‌کند که پروتکل اجازه می‌دهد. کاهش‌دهنده کلاسیک — بررسی هویت فراخوان — شکست می‌خورد چون فراخوان همان نماینده است و نماینده مجاز است. آنچه غایب است، پیوندی بین هویت اصلی و فراخوانی مشخص است.
بازپخش پیام در اجراهای بلندمدت
اجراهای بلندمدت عامل وضعیت را نقطه‌گذاری و از سر می‌گیرند. اگر لایه انتقال nonceای حمل نکند که از نقطه‌گذاری جان سالم به در ببرد، پیامی که در یک گام گرفته شده می‌تواند در گام دیگری بازپخش شود. بازپخش ممکن است از نظر معنایی معتبر باشد: قابلیت هنوز وجود دارد، آرگومان‌ها هنوز تجزیه می‌شوند، و عامل گیرنده هیچ خاطره‌ای از دیدن پیام قبلی ندارد. در اجرایی که ساعت‌ها و عامل‌های بسیاری را در بر می‌گیرد، پنجره بازپخش گسترده است، و نبود یک nonce پایدار یعنی لایه انتقال نمی‌تواند تلاش مجدد را از حمله تشخیص دهد.
هر پیام را به یک هویت و یک شناسه وظیفه گره بزنید
یک شناسه نشست کافی نیست. نشست‌ها بازاستفاده، استخر و گاهی بین وظایف مشترک می‌شوند. هر پیام باید یک هویت صریح (چه کسی عمل می‌کند) و یک شناسه وظیفه (این عمل بخشی از چه چیزی است) حمل کند، و هر دو باید توسط امضای پیام پوشش داده شوند. هویت همان درخواست‌کننده اصلی است، نه فرستنده بی‌واسطه. شناسه وظیفه به گیرنده اجازه می‌دهد سیاستی را اعمال کند که به کار محدود است، نه به اتصال.
یک سازوکار مشخص: سریال‌سازی متعارف پوشش پیام را امضا کنید، شامل هویت، شناسه وظیفه، نام قابلیت، و یک شماره ترتیب یکنوا افزایش‌یابنده، با کلیدی که عامل فرستنده نگه می‌دارد. گیرنده امضا را در برابر کلیدی که به هویت گره خورده بررسی می‌کند، شماره ترتیب را با آخرین شماره دیده‌شده برای آن وظیفه می‌سنجد، و تنها پس از آن ارزیابی می‌کند که آیا قابلیت مجاز است. این رمزنگاری بدیعی نیست؛ کمینه چیزی است که
قابلیت‌ها را به پیام محدود کنید، نه به اتصال
مجوزدهی در سطح اتصال ریشه جریان‌های نماینده گیج‌شده است. اتصالی که مجاز به فراخوانی یک قابلیت است می‌تواند آن را به هر دلیلی فراخوانی کند. در مقابل، اعطای قابلیت در سطح پیام، قابلیت، وظیفه، هویت و یک انقضا را نام می‌برد. گیرنده اعطا را بررسی می‌کند، نه اتصال را. این یعنی نماینده نمی‌تواند ارتقا یابد: فقط می‌تواند اعطاهایی را ارائه دهد که به آن صادر شده‌اند، برای وظایفی که به آن داده شده‌اند.
این بده‌بستان واقعی است. اعطاهای سطح پیام به هر فراخوان یک توکن اضافه می‌کنند، به یک صادرکننده نیاز دارند، و یک مسئله ابطال را معرفی می‌کنند. در ازدحام‌های داخلی با توان بالا، سربار در تأخیر و در پیچیدگی صادرکننده قابل اندازه‌گیری است. جایگزین — اعتماد به اتصال — ارزان‌تر است و باز شکست می‌خورد. انتخاب طراحی این است که آیا لایه انتقال باید در برابر منشأ بسته شکست بخورد. برای ارتباط عامل به عامل در مرزهای اعتماد، باید چنین باشد.
لاگ لایه انتقال را به سند معتبر تبدیل کنید
لاگ‌های سمت عامل توصیه‌ای هستند. یک عامل می‌تواند به‌خطر بیفتد، دوباره راه‌اندازی شود، یا صرفاً درباره کاری که کرده اشتباه کند. اگر تنها سند یک پیام در عامل فرستنده یا گیرنده باشد، آن سند شواهد نیست. لایه انتقال باید هر پوشش امضاشده را همراه با نتیجه تأییدش ثبت کند، و آن لاگ باید سند معتبر برای حسابرسی و برای تشخیص بازپخش باشد. این همچنین جایی فراهم می‌کند برای اعمال یکتایی nonce در سراسر نقطه‌گذاری‌ها: لایه انتقال، نه عامل، به یاد می‌آورد چه چیزی دیده شده است.
بده‌بستان صادقانه
هر یک از این قواعد کار را از عامل به لایه انتقال منتقل می‌کند. این همان نکته است، و همان هزینه هم هست. لایه‌های انتقالی که امضاها را تأیید می‌کنند، شماره‌های ترتیب را ردیابی می‌کنند، اعطاهای محدود به پیام را صادر و ابطال می‌کنند، و یک لاگ پایدار نگه می‌دارند، پیچیده‌تر از لوله‌هایی هستند که بایت جابه‌جا می‌کنند. آن‌ها به مدیریت کلید، یک صادرکننده، و لاگی نیاز دارند که از راه‌اندازی مجدد جان سالم به در ببرد. تأخیر و حالت‌های شکست اضافه می‌کنند. در فراخوانی ابزار تک‌فراخوان، این پیچیدگی توجیه ندارد. در ازدحام عامل همتا که هویت‌ها واگرا می‌شوند و اجراهای بلندمدت نقطه‌گذاری و از سر می‌گیرند، پیچیدگی همان ویژگی امنیتی است. پرسش این نیست که آیا باید هزینه‌اش را پرداخت، بلکه کجا: در لایه انتقال، یک بار، یا در هر عامل، به‌طور مکرر و ناسازگار.
گام بعدی چه باشد
با لایه انتقال مانند یک سطح حمله رفتار کنید و آن را به‌عنوان یکی حسابرسی کنید. گام‌هایی را که درخواست دوباره سریال‌سازی می‌شود برشمارید و بپرسید چه منشأیی جان سالم به در می‌برد. کشف قابلیت را از مجوزدهی به قابلیت جدا کنید و در زمان فراخوانی یک اعطا بخواهید. پیام‌ها را به هویت‌ها و وظایف گره بزنید، نه به نشست‌ها. لاگ لایه انتقال را معتبر کنید و از آن برای تشخیص بازپخش استفاده کنید. هیچ‌یک از این‌ها نیازمند رها کردن لایه‌های انتقال به سبک MCP نیست؛ نیازمند گسترش آن‌ها با ابتدایی‌های اعتمادی است که ارتباط همتا لازم دارد. برای کار مرتبط درباره امنیت پروتکل عامل، این تحلیل را ببینید.