پرش به محتوای اصلی

درخواست‌های دسترسی از سوی agentها به هدر منشأ نیاز دارند، نه رشتهٔ User-Agent

رشته‌های User-Agent نمی‌توانند مشخص کنند چه کسی پاسخگوست. ترافیک agent به فرادادهٔ منشأ امضاشده نیاز دارد که هویت اپراتور، هدف اعلام‌شده و دامنهٔ قابل‌لغو را حمل کند.

Detailed view of an audio mixing console with colorful lights in a professional studio setting.

سرویس دریافت‌کننده در واقع چه می‌بیند

یک 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 است که کند و اغلب بدون پایش است.

Close-up of a woman adjusting her cutting-edge bionic prosthetic arm, showcasing innovation.

ارزش دارد دربارهٔ این شکست دقیق باشیم. مشکل این نیست که 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 امضاشده است نه یک هدر جداگانه که بتوان بازنویسی‌اش کرد.

![Close-up view of a textile production line showcasing white thread spools in an Indian factory.](/media/automated-assembly-line-close-up-ae5d2bf169-09df11.jpg)

### یک 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 معتقد است مجاز به انجام چه کاری است، و چگونه آن مجوز را پس بگیرد. این یک پاکت امضاشده است، نه یک رشته.
اشتراک‌گذاریXLinkedInپیوند یکتا6 دقیقه مطالعه

خواندن مرتبط

پرسش‌هایی که این پاسخ می‌دهد

Why is a User-Agent string insufficient for identifying autonomous agents?

It is self-declared and unauthenticated, so any client can present any value. It carries no revocation path, no scope, no expiry and no operator contact, which means a receiving service cannot verify the claim or act on it during an incident.

What should a provenance envelope for agent traffic contain?

A signature bound to an operator identity, a declared purpose, a scope descriptor naming hosts, path prefixes, a rate ceiling and an expiry, and a well-known endpoint where a receiving service can verify the signature and reach the operator.

Where should signing happen in an agent system?

At the egress gateway rather than in each tool call. Centralising it avoids spreading key material across every component that can make a request and makes rotation a single-place change instead of a fleet-wide coordination problem.

How is a provenance envelope revoked?

It is treated as a session credential: short expiry, frequent reissuance, and a revocation endpoint the receiving service can consult cheaply. If revocation is slower than the incident, the envelope does not provide real accountability.