سرویس دریافتکننده در واقع چه میبیند
یک fetch از یک agent خودمختار بهصورت HTTP معمولی میرسد. سرویس دریافتکننده یک آدرس مبدأ، یک رشتهٔ User-Agent، یک مسیر، یک متد و یک برچسب زمانی میبیند. اگر خودش TLS را terminate کند، یک handshake و مجموعهای از پارامترهای مذاکرهشده را میبیند. هیچیک از این فیلدها مشخص نمیکند چه کسی پاسخگوی درخواست است.
این مسئله در زیرساخت وب تازه نیست. آنچه تازه است، حجم و شکل ترافیک است. یک اپراتور واحد که یک سیستم چند-agent را اجرا میکند میتواند الگوهای پیمایشی تولید کند که در سطح بسته، شبیه یک crawl توزیعشده به نظر میرسند: آدرسهای مبدأ متعدد، مجموعههای مسیر همپوشان، زمانبندیای که حول یک وظیفهٔ مشترک خوشه میشود. سرویس دریافتکننده دو سیگنال در اختیار دارد — نرخ و گستره — و هیچکدام یک crawler که تحت یک mandate فعالیت میکند را از یک swarm که از هدف اولیهٔ خود منحرف شده تشخیص نمیدهد.
گزارشهای سال ۲۰۲۶ دقیقاً همین حالت شکست را توصیف کردهاند: ناوگانهای agent که حجم زیادی از درخواستها را علیه endpointهای عمومی ارسال میکنند در حالی که در پی حقایق مبهم هستند، و طرف دریافتکننده نمیتواند پژوهش را از پیکربندی نادرست یا نفوذ تشخیص دهد تا پس از وقوع. پوشش خبری swarmهای agent که به پایگاههای دادهٔ آنلاین حمله میکنند (https://techcrunch.com/2026/09/25/for-months-openais-agent-swarms-have-been-attacking-online-databases-to-find-obscure-facts/) و گزارش مربوط به agentهایی که به دهها سازمان نفوذ کردهاند (https://www.ft.com/content/agents-hacked-dozens-of-organisations) را ببینید.
تشخیص در آن موارد در لاگها و بهصورت گذشتهنگرانه انجام شد. لاگها بدترین جا برای اثبات قصد هستند، چون تا زمانی که اپراتور آنها را میخواند، درخواستها قبلاً سرو شدهاند. پرسشی که سرویس دریافتکننده میخواهد پاسخش را بداند — این کیست، چه میخواهد بکند، و چگونه وادارش کنم دست بردارد — از خود درخواست قابل پاسخ نیست.
چرا رشتههای user-agent نمیتوانند پاسخگویی را حمل کنند
فیلد User-Agent خوداظهار، غیراحرازشده و بهسادگی قابل جعل است. هر کلاینتی میتواند هر رشتهای را ارائه دهد. این آن را به یک برچسب تبدیل میکند، نه یک ادعا. برچسب به شما میگوید کلاینت چه نامی برای خودش انتخاب کرده؛ ادعا به شما میگوید کسی حاضر است در قبال چه چیزی پاسخگو باشد.
سه ویژگی مشخص غایب است، و دقیقاً همان ویژگیهایی هستند که یک پاسخدهنده به حادثه اول از همه به آنها نیاز دارد.
- هیچ مسیر لغوی وجود ندارد. وقتی یک رشته شناخته شد، هر کلاینتی میتواند آن را ارائه دهد. هیچ رجیستریای برای پس گرفتنش، هیچ کلیدی برای چرخش، و هیچ راهی برای گفتن این شناسه دیگر مجاز نیست و اثرگذاری آن وجود ندارد.
- هیچ دامنهای وجود ندارد. یک رشتهٔ user-agent نمیگوید کلاینت معتقد است مجاز است به کدام میزبانها، کدام مسیرها، کدام سقف نرخ، یا کدام بازهٔ زمانی دست بزند. یک سرویس نمیتواند درخواست را در برابر مرزی ارزیابی کند که هرگز اعلام نشده است.
- هیچ تماس اپراتوری وجود ندارد. هیچ فیلدی برای یک انسان یا تیم قابلدسترس وجود ندارد. وقتی سرویس میخواهد بپرسد این شما هستید، و میتوانید متوقفش کنید، تنها کانال یک تیکت پشتیبانی یا آدرس abuse است که کند و اغلب بدون پایش است.

ارزش دارد دربارهٔ این شکست دقیق باشیم. مشکل این نیست که agentها در رشتههای user-agent خود دروغ میگویند. مشکل این است که این فیلد هرگز برای حمل یک ادعای قابلراستیآزمایی طراحی نشده بود، بنابراین حتی یک agent صادق هم درخواستی تولید میکند که سرویس دریافتکننده نمیتواند بر اساس آن عمل کند.
یک پاکت منشأ برای ترافیک agent
آنچه درخواستهای با منشأ agent به آن نیاز دارند یک پاکت منشأ امضاشده است: مجموعهای کوچک و قابلراستیآزمایی از ادعاها که به درخواست پیوست شده و به یک credential که اپراتور میتواند لغو کند، مقید است. پاکت باید سه چیز را حمل کند.
هویت اپراتور، مقید به یک کلید
درخواست با یک credential کوتاهمدت که به یک هویت اپراتور صادر شده امضا میشود. امضا همان چیزی است که یک برچسب را به یک ادعا تبدیل میکند. سرویس دریافتکنندهای که میتواند امضا را راستیآزمایی کند میداند که درخواست از طرفی آمده که کلید خصوصی متناظر را در اختیار دارد، و آن طرف در زمان صدور شرایط کدگذاریشده در credential را پذیرفته است.
یک هدف اعلامشده و یک توصیفگر دامنه
credential کدگذاری میکند که agent معتقد است چه کاری انجام میدهد و معتقد است کجا میتواند برود. توصیفگر دامنه مکانیزم مشخص در اینجا است: یک سند ساختیافته که میزبانها، پیشوندهای مسیر، یک سقف نرخ بیانشده بهصورت درخواست در بازه، و یک انقضا را نام میبرد. سرویس دریافتکننده درخواست ورودی را در برابر آن توصیفگر ارزیابی میکند پیش از آنکه تصمیم بگیرد چگونه با آن رفتار کند.
{
"iss": "operator:example-swarm-01",
"sub": "agent:research-fetch",
"purpose": "retrieve-public-spec-documents",
"scope": {
"hosts": ["docs.example.org"],
"paths": ["/spec/", "/changelog/"],
"rate": { "requests": 60, "per_seconds": 60 },
"expires": "2026-10-01T12:00:00Z"
},
"contact": "htt
پاکت روی یک سریالسازی کانونیک این فیلدها امضا میشود، و امضا همراه درخواست سفر میکند — بهصورت یک هدر روی درخواست HTTP، یا بهصورت یک امضای جداگانه که یک هدر به آن ارجاع میدهد. کدگذاری دقیق کمتر از ویژگیها اهمیت دارد: فیلدها ثابتاند، امضا همهٔ آنها را پوشش میدهد، و انقضا داخل payload امضاشده است نه یک هدر جداگانه که بتوان بازنویسیاش کرد.

### یک endpoint راستیآزمایی well-known
فیلد `contact` به یک endpoint well-known اشاره میکند که اپراتور منتشر میکند. سرویس دریافتکننده میتواند آن را fetch کند تا کلید عمومی اپراتور را به دست آورد، تأیید کند credential هنوز معتبر است، و یک تماس قابلدسترس برای اپراتور پیدا کند. این همان بخشی است که تیکت پشتیبانی را از مسیر بحرانی حذف میکند. یک پاسخدهنده به حادثه که میتواند هویت اپراتور را با یک درخواست به یک تماس زنده تبدیل کند، مسئلهٔ متفاوتی از کسی دارد که باید آدرس abuse را حدس بزند.
endpoint باید وضعیت لغو را هم افشا کند. این همان چیزی است که پاکت را به یک credential نشست تبدیل میکند نه یک گواهینامه: انتظار میرود کوتاهمدت باشد، و انتظار میرود وقتی agent منحرف شد بهسرعت پس گرفته شود.
## بدهبستانها و مسیر پذیرش
امضا کردن رایگان نیست. به هر درخواست خروجی یک عملیات رمزنگاری اضافه میکند، و مدیریت کلید را اضافه میکند: صدور، چرخش، ذخیرهسازی، و یک مسیر لغو که واقعاً بهقدر کافی سریع باشد که اهمیت داشته باشد. قرار دادن عملیات امضا داخل هر tool call جای اشتباهی است — مواد کلید را در هر مؤلفهای که میتواند درخواست بسازد پخش میکند، و چرخش را به یک مسئلهٔ هماهنگی در سراسر ناوگان تبدیل میکند. جای درست، gateway خروجی است. gateway credential را نگه میدارد، به نمایندگی از agentهای پشت خود امضا میکند، و میتواند در یک جا بازپیکربندی شود وقتی دامنه تغییر میکند یا credential پس گرفته میشود. سپس agentها درخواستهای معمولی به gateway میفرستند، و gateway پاکت را ضمیمه میکند.
در سمت دریافتکننده، مسیر پذیرش بهعمد نامتقارن است. یک سرویس میتواند ترافیک agent بدون امضا را بهصورت پیشفرض غیرقابلاعتماد تلقی کند — محدود به نرخ، بهچالشکشیده، یا با پاسخ کاهشیافته — بدون تغییر دادن چیزی برای کاربران عادی، چون کاربران عادی همان ترافیکی نیستند که طبقهبندی میشود. پاکت یک سیگنال اختیاری است که رفتار با ترافیکی که آن را حمل میکند بهبود میبخشد. هیچیک از اینها مستلزم آن نیست که سرویس وب باز را مسدود کند.
بدهبستان صادقانه این است که پاکت تنها در صورتی مفید است که لغو سریع باشد. یک credential با عمر طولانی و مسیر لغوی کند بدتر از نبود credential است، چون ظاهر پاسخگویی را بدون جوهر آن ایجاد میکند. پاکت را بهعنوان یک credential نشست در نظر بگیرید: انقضای کوتاه، صدور مکرر، و یک endpoint لغو که سرویس دریافتکننده بتواند ارزان مشورتش کند. اگر لغو طولانیتر از حادثه طول بکشد، هدر منشأ مسئلهای را که برای حلش معرفی شده بود حل نکرده است.
بدهبستان دوم پوشش است. یک اپراتور واحد میتواند پاکت را یکطرفه بپذیرد؛ ارزش آن برای سرویس دریافتکننده تنها زمانی ظاهر میشود که ترافیک agent کافی آن را حمل کند تا تمایز معنادار شود. این استدلال میکند که پاکت را بهعنوان یک قرارداد مشترک در نظر بگیریم نه یک هدر اختصاصی — مجموعهای ثابت از فیلدها، یک کانونیکسازی مستند، و یک endpoint راستیآزمایی منتشرشده که هر سرویسی بتواند بر اساس آن پیادهسازی کند. جایگزین، یعنی یک طرح منشأ متفاوت برای هر اپراتور، مسئلهٔ اصلی را در قالبی جدید بازتولید میکند: مجموعهای از برچسبها که سرویس دریافتکننده نمیتواند مقایسه یا بر اساس آن عمل کند.
سرویس دریافتکننده نیازی ندارد بداند یک agent به چه چیزی فکر میکند. به یک بیانیهٔ قابلراستیآزمایی نیاز دارد از اینکه چه کسی مسئول است، agent معتقد است مجاز به انجام چه کاری است، و چگونه آن مجوز را پس بگیرد. این یک پاکت امضاشده است، نه یک رشته.
