گزارش‌های ایجنت سرکش پیش از آنکه یک مسئله ایمنی باشند، یک مسئله انتساب هستند

گزارش‌ها در واقع چه چیزی را توصیف می‌کنند

وقتی یک ایجنت بدون آنکه انسانی در آن لحظه دستور را صادر کرده باشد به یک endpoint دولتی یا API شرکتی می‌رسد، روایتی که در پی می‌آید معمولاً درباره مدل است. یک آزمایشگاه، یک شماره نسخه، یک آستانه توانمندی. این قالب‌بندی خوانا است و خوب منتقل می‌شود، اما به پرسشی پاسخ می‌دهد که پاسخ‌دهندگان به حادثه در واقع به آن نیازی ندارند. پرسشی که تعیین می‌کند در ادامه چه اتفاقی می‌افتد محدودتر است: کدام credential ارائه شد، چه scope‌ای داشت، و از طریق کدام زنجیره واگذاری به آن endpoint رسید.

چندین گزارش اخیر تعامل ایجنت‌ها با سیستم‌های خارجی را به شیوه‌هایی توصیف می‌کنند که اپراتور در آن زمان مستقیماً دستور نداده بود. جزئیات متفاوت است، اما شکل ثابت است: یک فرایند خودمختار یا نیمه‌خودمختار درخواستی را ترکیب کرد، و درخواست پذیرفته شد چون یک credential معتبر آن را مجاز کرده بود. مدل قصد را تولید کرد. credential دسترسی را تولید کرد. تنها یکی از این دو در ده دقیقه آینده قابل لغو است.

انتساب در اینجا یک تمرین فلسفی درباره عاملیت نیست. یک پرسش مدل داده است. چه کسی عمل کرد، به نمایندگی از چه کسی، تحت کدام grant، در کدام مرحله از اجرا. اگر سیستم شما بتواند به این پرسش به‌صورت یک query پاسخ دهد، حادثه یک رویداد عملیاتی محدود است. اگر نتواند، حادثه به یک پروژه پزشکی قانونی تحت فشار زمانی تبدیل می‌شود، و پاسخی که در نهایت تولید می‌کنید یک استنتاج خواهد بود نه یک سابقه.

چرا زنجیره واگذاری وجود ندارد

دلیل اینکه بیشتر استک‌ها نمی‌توانند زنجیره را بازسازی کنند این است که هرگز برای نگهداری آن طراحی نشده‌اند. سه الگو مسئول بخش عمده این شکاف هستند.

اول، credentialها به یک سرویس محدود می‌شوند نه به یک task. به یک ایجنت یک token یا key با مجوزهایی که integration نیاز دارد صادر می‌شود، و آن grant در تمام اجراهایی که ایجنت انجام می‌دهد باقی می‌ماند. مجوز از قصدی که آن را توجیه می‌کرد بیشتر عمر می‌کند. یک grant که صادر شده بود تا ایجنت برای یک task زمان‌بندی تقویم را بخواند، شش ماه بعد که همان ایجنت کار کاملاً دیگری انجام می‌دهد هنوز معتبر است، چون هیچ‌چیز در credential آن task را رمزگذاری نمی‌کند.

دوم، hopهای میانی به‌جای تضعیف credential والد، آن را دوباره استفاده می‌کنند. یک planner یک sub-agent ایجاد می‌کند. sub-agent یک tool proxy را فراخوانی می‌کند. proxy endpoint شخص ثالث را فراخوانی می‌کند. در هر hop، همان bearer token بدون تغییر به جلو می‌رود. sub-agent دقیقاً همان اختیار principal ریشه را دارد، حتی اگر کار واقعی‌اش ممکن است کسری از آن را نیاز داشته باشد. این راحت است، و بزرگ‌ترین عامل واحد در شعاع انفجار در سیستم‌های ایجنت است.

سوم، logها درخواست را ثبت می‌کنند، نه زنجیره امانت‌داری که آن را تولید کرده است. یک access log نشان می‌دهد که درخواستی با یک token معتبر در یک timestamp مشخص رسیده است. نشان نمی‌دهد کدام مرحله planner قصد را تولید کرده، کدام sub-agent آن را اجرا کرده، یا کل توالی به کدام task تعلق داشته است. بنابراین بازسازی پس‌رویدادی به همبستگی timestampها و شناسه‌های session در سیستم‌هایی وابسته است که هرگز برای پیوند خوردن طراحی نشده‌اند. آن همبستگی استنتاج است. استنتاج برای یک postmortem خوب است و برای لغو بی‌فایده.

یک سابقه انتساب حداقل قابل اجرا

راه‌حل یک ارتقای logging نیست. تغییری است در آنچه یک اقدام خروجی حمل می‌کند و جایی که سابقه نوشته می‌شود.

هر اقدام خروجی باید حداقل چهار فیلد را حمل کند:

• یک principal — هویتی که اقدام به اختیار آن انجام می‌شود، قابل ارجاع به یک حساب واقعی یا هویت سرویس
• یک شناسه task — یک id پایدار برای واحد کاری که اقدام به آن خدمت می‌کند، نه session و نه فرایند
• یک شناسه مرحله والد — مرحله‌ای که این اقدام را تولید کرده، تا زنجیره یک ساختار پیوندی باشد نه یک فهرست تخت
• scope‌ای که واقعاً اعمال شده — مجوز مشخصی که اقدام مصرف کرده، بیان‌شده با همان واژگانی که نقطه اجرا بر اساس آن بررسی می‌کند

این چهار فیلد برای بازسازی یک گراف جهت‌دار از هر اقدام به principal ریشه‌اش، و از هر principal به هر اقدامی که تحت آن انجام شده، کافی است.

مکانیزمی که این را ممکن می‌کند تضعیف scope در هر hop است. وقتی یک sub-agent ایجاد می‌شود، یک grant دریافت می‌کند که زیرمجموعه اکید اختیار فراخوان‌کننده‌اش است — هرگز ابرمجموعه، هرگز مجموعه برابر مگر آنکه task واقعاً به اختیار کامل نیاز داشته باشد و آن نیاز صریح باشد. تضعیف در مرزی که فرزند ایجاد می‌شود اعمال می‌شود، نه اینکه توسط فرزند ادعا شود. یک tool proxy که درخواستی دریافت می‌کند grant تضعیف‌شده خودش را ارائه می‌دهد، نه token فراخوان‌کننده را.

مکانیزم دوم جایی است که سابقه نوشته می‌شود. داده انتساب باید در نقطه اجرا منتشر شود — جایی که واقعاً تصمیم می‌گیرد آیا درخواست ادامه یابد — نه اینکه بعداً از application logها جمع‌آوری شود. application logها توسط کدی نوشته می‌شوند که ممکن است باگ داشته باشد، دور زده شود یا به‌سادگی در برخی مسیرها وجود نداشته باشد. نقطه اجرا طبق تعریف هر درخواست را می‌بیند، و از قبل scope‌ای که بررسی کرده را می‌داند. نوشتن principal، task id، parent step id و scope اعمال‌شده در آنجا سا

{ "principal": "svc:reporting-agent",
  "task_id": "tsk_8f21",
  "parent_step": "stp_04",
  "scope": "calendar.read",
  "target": "external.example.gov",
  "decision": "allow" }

سابقه‌ای مانند این یک خط log به معنای متعارف نیست. یک یال در یک گراف است، و توسط کامپوننتی نوشته می‌شود که اختیار گفتن نه را داشته است.

پیامدهای طراحی

وقتی زنجیره وجود داشته باشد، پاسخ به حادثه تغییر ماهیت می‌دهد. پرسش «ایجنت چه کرد» به یک پیمایش تبدیل می‌شود: از principal شروع کن، به جلو تا task برو، به جلو تا هر مرحله برو، هر endpoint لمس‌شده را فهرست کن. پرسش «چگونه به آنجا رسید» به یک پیمایش به عقب از endpoint تا grant ریشه تبدیل می‌شود. هر دو queryهایی علیه ساختاری هستند که از قبل نگهداری می‌کنید، نه تحقیقاتی که پس از واقعه انجام می‌دهید.

لغو به یک task محدود می‌شود نه به یک service account. اگر یک task واحد بدرفتاری کند، grantهای صادرشده برای آن task و هر چیزی پایین‌دست آن را لغو می‌کنید. بقیه کار ایجنت ادامه می‌یابد. این تفاوت بین مهار یک حادثه و غیرفعال کردن یک توانمندی است. همچنین تفاوت بین لغوی است که در چند ثانیه اعمال می‌شود و لغوی که نیاز دارد قبل از آنکه جرات خاموش کردنش را داشته باشید هر integration که service account لمس می‌کند را حسابرسی کنید.

استدلال‌های مسئولیت یک بستر واقعی پیدا می‌کنند. وقتی یک اقدام مورد اختلاف است، زنجیره نشان می‌دهد چه چیزی مجاز شده بود — scope‌ای که اعطا شده بود، مرحله‌ای که آن را اعمال کرده بود، principal که پشت آن ایستاده بود. این نوع متفاوتی از ادعا نسبت به آنچه یک فروشنده درباره رفتار مدل اظهار می‌کند است، و توسط هر دو طرف قابل بررسی است.

معاوضه صادقانه این است که تضعیف و سوابق هر اقدام هزینه مهندسی دارند و اصطکاک ایجاد می‌کنند. هر hop باید یک grant محدودتر مذاکره کند، که یعنی کامپوننت‌هایی که sub-agent ایجاد می‌کنند باید بدانند sub-agent قبل از اجرا به چه چیزی نیاز خواهد داشت. این یک محدودیت طراحی است، و واقعاً سخت‌تر از عبور دادن یک token است. همچنین هزینه عملکرد و ذخیره‌سازی واقعی برای نوشتن یک سابقه یال در هر نقطه اجرا به‌جای نمونه‌برداری از logها وجود دارد. برای ترافیک ایجنت با حجم بالا، حجم سابقه متناسب با حجم اقدام است، و این رایگان نیست.

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

انتساب یک ویژگی ایمنی پیچ‌شده به یک استک ایجنت نیست. خاصیتی از نحوه مدل‌سازی و انتشار اختیار است. مدل داده را درست انجام دهید و گفتگوی ایمنی چیزی مشخص برای ایستادن روی آن دارد. اشتباه انجام دهید و هر گزارش حادثه به بحثی درباره مدل تبدیل می‌شود، چون زنجیره‌ای که می‌توانست پرسش را حل کند هرگز نوشته نشده بود.