کنترل خروجی عامل: چرا دسترسی یک شکست مسیریابی است

الگوی حادثه

وقتی گزارش می‌شود که یک ناوگان عامل به پورتال دولتی یا بهداشتی‌ای که به آن تعلق نداشته دست پیدا کرده، در کالبدشکافی به‌ندرت ارتقای سطح دسترسی پیدا می‌شود. هیچ اکسپلویت کرنلی، هیچ اعتبارنامه دزدیده‌شده، و هیچ باگ confused-deputy در سرویس مجوزدهی وجود ندارد. یک درخواست HTTP خروجی به یک hostname وجود دارد که عامل هرگز قرار نبود آن را resolve کند، و پاسخی که برگشت.

این همان جزئیاتی است که در خلاصه‌های چنین گزارش‌هایی گم می‌شود: عامل قابلیت جدیدی کسب نکرد. یک hostname قابل‌دسترس کسب کرد. هر چیزی که برای ارسال درخواست لازم داشت — یک پشته TLS، یک resolver DNS، یک ابزار fetch در manifest خود — از قبل حاضر بود و همان‌طور که طراحی شده بود کار می‌کرد. شکست در آنچه عامل می‌توانست انجام دهد نبود. در جایی بود که عامل می‌توانست برود.

فعالیت‌های گزارش‌شده عامل علیه پورتال‌های بخش عمومی حول همین شکل خوشه می‌بندند. سؤال جالب این نیست که چرا مدل آن hostname را انتخاب کرد. سؤال جالب این است که چرا شبکه اصلاً آن اتصال را مجاز دانست.

چرا guardrailهای سطح prompt نمی‌توانند این خط را نگه دارند

دستورالعمل‌ها احتمالاتی‌اند. دسترس‌پذیری شبکه قطعی است. همین عدم‌تقارن تمام استدلال است.

یک system prompt که می‌گوید «با سیستم‌های دولتی تماس نگیر» یک prior روی توالی توکن‌هاست. بیشتر مواقع دوام می‌آورد و به روش‌هایی که برشمردنشان دشوار است تنزل می‌کند: یک برنامه چندمرحله‌ای که هدف را بازقالب‌بندی می‌کند، یک نتیجه ابزار که URL غیرمنتظره‌ای فراهم می‌کند، یک context طولانی که در آن محدودیت از نقطه تصمیم دور است، یک hit بازیابی که با یک لینک خارجی مثل دستورالعمل رفتار می‌کند. هیچ‌یک از این‌ها به یک کنشگر خصمانه نیاز ندارد. به یک توالی محتمل از توکن‌ها نیاز دارد.

یک hostname مسدودشده از جنس دیگری است. یک‌بار در یک گلوگاه که عامل کنترلش را ندارد اعمال می‌شود، و به‌طور یکسان بر هر اجرای آینده، هر نسخه مدل، هر تنظیم temperature، و هر retry اعمال می‌شود. نیازی نیست در prompt بازگو شود. با طول context تحلیل نمی‌رود. نمی‌توان با یک completion به‌اندازه کافی فصیح با آن بحث کرد.

این استدلالی علیه guardrailهای سطح prompt نیست. آن‌ها برای شکل‌دادن به قصد و برای امتناع ارزان و زودهنگام مفیدند. آن‌ها صرفاً لایه اشتباهی برای مرزی هستند که باید وقتی مدل اشتباه می‌کند، خسته است، یا هدایت می‌شود دوام بیاورد. مرزی که بتوان با حرف زدن از وجودش منصرفش کرد، مرز نیست.

طراحی قرارداد خروجی

واحد عملی یک قرارداد خروجی است: مجموعه‌ای قاعده اعلانی که تعریف می‌کند یک هویت عامل می‌تواند به چه چیزی دسترسی داشته باشد، تحت چه شرایطی، و برای چه مدت. اگر درست انجام شود، از یک allowlist hostname مشخص‌تر است.

Two professionals engaging in a business meeting, signing documents for a consulting agreement.

allowlist بر اساس مقصد، متد و کلاس payload

hostname به‌تنهایی بیش از حد درشت است. قاعده‌ای که api.example.gov را مجاز می‌کند، هر مسیر، هر متد، و هر بدنه را مجاز می‌کند. یک قرارداد سخت‌گیرانه‌تر سه چیز را با هم نام می‌برد:

مقصد: scheme، host، و پیشوند مسیر — https://api.example.gov/v1/records/ به‌جای کل origin.
متد: GET و HEAD مسیرهای خواندن‌اند؛ POST، PUT، PATCH و DELETE مسیرهای نوشتن‌اند و باید جداگانه توجیه شوند.
کلاس payload: شکل آنچه می‌تواند خارج شود. یک عامل بازیابی که فقط یک شناسه می‌فرستد ریسک متفاوتی از عاملی دارد که می‌تواند بدنه یک سند را ضمیمه کند. کلاس payload را می‌توان با schema، با سقف اندازه، یا با یک classifier در proxy اعمال کرد.

قاعده‌ای که هر سه را مقید می‌کند، به شکلی قابل‌حسابرسی است که یک فهرست hostname نیست. وقتی یک بازبین می‌پرسد «آیا این عامل می‌توانست داده‌ای به یک پورتال بهداشتی ارسال کند؟»، پاسخ یک lookup است، نه یک استنتاج.

رد به‌صورت پیش‌فرض، با یک تیکت صریح

وضعیت پیش‌فرض رد است. دسترسی با یک استثنا اعطا می‌شود که نام می‌برد:

requesting_agent: intake-classifier-v3
purpose: fetch public reference data for citation
destination: https://api.example.gov/v1/records/
methods: [GET, HEAD]
payload_class: identifier-only
requested_by: platform-team
justification: ticket OPS-4821
expires_at: 2026-09-30T00:00:00Z

انقضا فیلد باربر است. استثناهای دائمی انباشته می‌شوند؛ استثناهای منقضی‌شونده یک توجیه مجدد دوره‌ای را تحمیل می‌کنند، و همان‌جاست که دسترسی کهنه حذف می‌شود. شناسه تیکت قاعده شبکه را به تصمیم انسانی‌ای که آن را مجاز کرده گره می‌زند، تا بازبینی حادثه بتواند از یک اتصال به یک شخص و یک دلیل عقب برگردد.

ردها را به‌عنوان رویدادهای درجه‌یک ثبت کنید

بیشتر proxyها ترافیک مجاز را با جزئیات ثبت می‌کنند و ردها را به‌صورت یک شمارنده. این تأکید را معکوس کنید. یک رد حامل هویت عامل، مقصد تلاش‌شده، متد، قاعده‌ای که فعال شده، و یک شناسه همبستگی به اجراست.

فراوانی رد یک شاخص پیشرو برای drift در prompt است. یک عامل پایدار نرخ پایداری از ردها تولید می‌کند، عمدتاً از retryها و اشتباهات تایپی. نرخ صعودی، یا یک خوشه جدید از ردها علیه یک کلاس مقصد، معمولاً یعنی رفتار عامل پیش از وقوع هر exfiltration موفق تغییر کرده است. ردها سیگنال زودهنگام‌اند

یک پیاده‌سازی عملی، یک broker بین runtime عامل و شبکه قرار می‌دهد. ابزار fetch عامل سوکت باز نمی‌کند. با یک درخواست ساخت‌یافته broker را صدا می‌زند:

Close-up view of Westminster Palace's intricate Gothic architecture in London, UK.

{
  "agent": "intake-classifier-v3",
  "run_id": "r-8f21c",
  "method": "GET",
  "url": "https://api.example.gov/v1/records/4412",
  "payload_class": "identifier-only"
}

broker درخواست را در برابر قرارداد کامپایل‌شده resolve می‌کند، مقصد، متد و کلاس payload را ارزیابی می‌کند، و یا تماس را proxy می‌کند یا آن را رد می‌کند. ردها در همان log فقط-افزودنی‌ای نوشته می‌شوند که موفقیت‌ها، با شناسه قاعده و همبستگی اجرا. DNS برای بارهای کاری عامل به broker پین می‌شود تا hostnameی که در قرارداد نیست، از همان ابتدا resolve نشود.

broker تنها مرز قابل‌حسابرسی است. یک جا برای بازبینی، یک جا برای تغییر، و یک جا که در آن یک رد یک واقعیت ثبت‌شده است نه فقدان شواهد.

معامله صادقانه

یک broker خروجی مرکزی یک وابستگی است. به هر تماس خروجی یک hop تأخیر اضافه می‌کند، برای عامل‌هایی که به شبکه نیاز دارند یک نقطه شکست واحد است، و به انضباط عملیاتی نیاز دارد: تغییرات قرارداد باید مثل کد بازبینی، مستقر و نسخه‌بندی شوند. تیم‌هایی که آن انضباط را نادیده می‌گیرند به brokerی می‌رسند که «موقتاً» برای یک بار کاری دور زده می‌شود، و یک دور زدن موقت یک حفره دائمی است.

هزینه واقعی است. جایگزین یک ناوگانی است که دسترسی‌اش با هر hostnameی که تصادفاً در یک نتیجه ابزار ظاهر شود تعریف می‌شود، که اصلاً مرز نیست. تأخیر و یک صف بازبینی ارزان‌تر از یک سطح خروجی بی‌کران است.

پیامدهای عملیاتی

دو رویه از برخورد با خروجی به‌عنوان یک قرارداد نتیجه می‌شود.

قواعد خروجی به مصنوعات نسخه‌بندی‌شده تبدیل می‌شوند. آن‌ها در همان مخزنی زندگی می‌کنند که manifest ابزار عامل، و در همان تغییر بازبینی می‌شوند. یک pull request که ابزاری اضافه می‌کند که از یک origin جدید fetch می‌کند، باید قاعده خروجی متناظر را اضافه یا اصلاح کند، و یک بازبین هر دو را با هم می‌بیند. manifest ابزار می‌گوید عامل قصد دارد چه کند؛ قرارداد خروجی می‌گوید چه چیزی برایش مجاز است. واگرایی بین آن دو یک یافته بازبینی است، نه یک غافلگیری زمان اجرا.

بازبینی حادثه از log شبکه شروع می‌شود. وقتی چیزی اشتباه می‌شود، اولین مصنوع log broker برای پنجره اجرای متأثر است: مقصدها، متدها، کلاس‌های payload، ردها، و شناسه قواعد دخیل. transcript بعد از آن مشورت می‌شود، برای فهم قصد. این ترتیب مهم است چون log شبکه قطعی است و transcript یک بازسازی. شروع از log به «واقعاً چه چیزی خارج شد» پاسخ می‌دهد، پیش از آنکه کسی بر سر «مدل چه قصدی داشت» بحث کند.

جمع‌بندی

رسیدن یک عامل به پورتالی که نباید لمس کند، در درجه اول یک داستان رفتار مدل نیست. یک داستان مسیریابی است. دسترسی جایی اعطا شده — با یک پیش‌فرض سهل‌گیرانه، یک استثنای کهنه، یک resolver پین‌نشده — و همان اعطا جایی است که اصلاح به آن تعلق دارد. guardrailهای سطح prompt به قصد شکل می‌دهند؛ آن‌ها دسترسی را اعمال نمی‌کنند. یک مرز خروجی قابل‌حسابرسی واحد، با رد به‌صورت پیش‌فرض، ثبت ردها با همان وفاداری موفقیت‌ها، و نسخه‌بندی‌شده در کنار manifest ابزار، چیزی است که پاسخ به «آیا این عامل می‌توانست به آن host برسد؟» را به یک lookup تبدیل می‌کند نه یک امید.

عاملی که به یک پورتال دولتی می‌رسد، یک شکست در مسیریابی است