الگو در گزارش‌ها
پنجره‌های انقضا سخاوتمندانه تنظیم می‌شوند تا از شکست‌های میانه‌ی اجرا جلوگیری شود. کاری که گاهی چهل دقیقه طول می‌کشد، اعتبارنامه‌ای می‌گیرد که بیست‌وچهار ساعت معتبر است. وقتی اجرا به‌طور عادی پایان می‌یابد، هیچ چیزی مجوز را باطل نمی‌کند، چون پایان عادی به‌عنوان یک رویداد امنیتی تلقی نمی‌شود. نتیجه، انباشت اختیار خفته‌ای است که هیچ‌کس آن را به‌عنوان سطح ریسک رصد نمی‌کند. در بازبینی‌های دسترسی ظاهر نمی‌شود چون هرگز به‌عنوان یک entitlement تدارک دیده نشده است؛ در لاگ‌ها به‌صورت یک احراز هویت موفق از یک هویت workload که هنوز از نظر فنی زنده است ظاهر می‌شود.
شکست این نیست که agent بدخواه است. شکست این است که چرخه‌ی حیات حالت پایانی ندارد. اعتبارنامه‌ای که برای یک کار صادر می‌شود و پس از آن کار هرگز باطل نمی‌شود، یک اعتبارنامه‌ی موقت نیست. یک مجوز دائمی با نامی گمراه‌کننده است.
چرا انقضا به‌تنهایی آن را حل نمی‌کند
یک اجرای به‌اندازه‌ی کافی طولانی همیشه به مسیر تمدید نیاز خواهد داشت. هر agentی که کار چندمرحله‌ای انجام می‌دهد — واکشی داده، فراخوانی ابزارها، انتظار برای تأیید انسانی، تلاش مجدد روی یک وابستگی ناپایدار — در نهایت از یک انقضای کوتاه فراتر می‌رود. مسیر تمدید جایی است که مجوزها بی‌سروصدا دائمی می‌شوند. اگر تمدید خودکار و وابسته به هویت باشد، agent دسترسی خود را به‌طور نامحدود تازه می‌کند، و انقضا به یک تشریفات تبدیل می‌شود که به‌جای یک کنترل، نویز لاگ تولید می‌کند.
انقضای مبتنی بر زمان همچنین با تکمیل کار همبستگی ندارد. پنجره‌ی خطرناک دوره‌ی پس از موفقیت است، نه پیش از آن. اعتبارنامه‌ای که در یک ساعت منقضی می‌شود اگر اجرا در پنج دقیقه تمام شود و مجوز در زمان تکمیل باطل شود، ایمن است. اگر اجرا در پنج دقیقه تمام شود و مجوز پنجاه‌وپنج دقیقه‌ی دیگر زنده بماند، ناایمن است. کوتاه کردن انقضا پنجره را کاهش می‌دهد اما آن را نمی‌بندد، و یک حالت شکست جدید معرفی می‌کند: اجراهایی که در میانه‌ی کار شکست می‌خورند چون اعتبارنامه منقضی شده، که اپراتورها را به سمت بلندتر کردن دوباره‌ی پنجره سوق می‌دهد. کنترل بین بیش‌ازحد مجاز و بیش‌ازحد شکننده نوسان می‌کند چون چیز اشتباهی را می‌سنجد.
یک مکانیزم مشخص این شکاف را قابل مشاهده می‌کند. مجوزی را در نظر بگیرید که به‌صورت یک توکن امضاشده با claim موضوعِ agent:researcher-07 و دامنه‌ی read:customer_records صادر شده است. توکن یک exp بیست‌وچهار ساعته دارد. اجرایی که به آن نیاز داشت در هشت دقیقه تکمیل شد. برای بیست‌وسه ساعت و پنجاه‌ودو دقیقه‌ی باقی‌مانده، هر فرایندی که بتواند آن توکن را ارائه دهد — خود agent، یک ابزار به‌خطرافتاده، یک بازپخش از لاگ — همان دسترسی اجرای اصلی را دارد. موضوع توکن agent است، نه اجرا، پس هیچ claimی وجود ندارد که مرجع اعتبارنامه بتواند از آن برای تشخیص پایان کار استفاده کند. باطل‌سازی نیازمند برشمردن توکن‌ها بر اساس هویت agent و حدس زدن اینکه کدام‌یک کهنه است، خواهد بود. این یک حدس عملیاتی است، نه یک قرارداد.
یک حالت پایانی برای هر مجوز
راه‌حل یک قرارداد چرخه‌ی حیات است، نه یک انقضای کوتاه‌تر. هر اعتبارنامه در برابر یک شناسه‌ی اجرا صادر می‌شود و یک گذار پایانی اجباری حمل می‌کند: completed، failed، یا abandoned. شناسه‌ی اجرا موضوع مجوز است، نه هویت agent. هویت agent ممکن است به‌عنوان یک صفت ظاهر شود، اما چیزی نیست که مجوز به آن گره خورده است.
Orchestrator رویداد پایانی را منتشر می‌کند. از قبل می‌داند که یک اجرا چه زمانی پایان می‌یابد، چون همان مؤلفه‌ای است که اجراها را شروع و متوقف می‌کند. وقتی اجرا به حالت پایانی می‌رسد، orchestrator رویدادی — run.completed، run.failed، run.abandoned — را به مرجع اعتبارنامه منتشر می‌کند. مرجع اعتبارنامه رویداد را مصرف می‌کند و هر مجوزی که در برابر آن شناسه‌ی اجرا صادر شده را باطل می‌کند. باطل‌سازی مسئولیت agent نیست. Agentی که کرش می‌کند، حلقه می‌زند، یا کشته می‌شود را نمی‌توان برای پاک‌سازی پس از خودش قابل اعتماد دانست، و طراحی‌ای که به همکاری agent وابسته است یک کنترل نیست.
تمدید یک مجوز جدید با شناسه‌ای جدید و توجیهی صریح است. اگر اجرا به زمان بیشتری نیاز دارد، orchestrator یک اعتبارنامه‌ی جدید در برابر همان شناسه‌ی اجرا درخواست می‌کند، و مرجع اعتبارنامه درخواست را با یک دلیل ثبت می‌کند: continuation: awaiting human approval. رد حسابرسی سپس ادامه را نشان می‌دهد، نه تمدید را. اپراتوری که تاریخچه را بازبینی می‌کند، دنباله‌ای از مجوزها را می‌بیند، هرکدام با یک شروع و یک پایان، نه یک مجوز واحد که بی‌سروصدا تازه شده است. این تمایز مهم است چون تمدید لحظه‌ای را پنهان می‌کند که یک مجوز موقت دائمی شد؛ ادامه آن لحظه را صریح و قابل بازبینی می‌کند.
این بده‌بستان واقعی است. یک قرارداد حالت پایانی نیازمند آن است که orchestrator منبع معتبر چرخه‌ی حیات اجرا باشد، و نیازمند آن است که مرجع اعتبارنامه هنگام پایان اجرا قابل دسترسی باشد. اگر orchestrator بدون انتشار رویداد پایانی از کار بیفتد، مجوز تا زمانی که یک فرایند آشتی‌دهی آن را بگیرد باقی می‌ماند. آن آشتی‌دهی یک جاروب است که مجوزهای فعال را با اجراهای فعال مقایسه می‌کند و تفاوت را باطل می‌کند. کندتر از باطل‌سازی رویدادمحور است، و پنجره‌ای معرفی می‌کند که در آن یک مجوز از اجرایش عمر بیشتری می‌کند. قرارداد این پنجره را حذف نمی‌کند؛ آن را کران‌دار و قابل مشاهده می‌کند. سیستمی که حتی یک پنجره‌ی کران‌دار را تحمل نمی‌کند به معماری متفاوتی نیاز دارد — توکن‌های کوتاه‌عمر که به‌ازای هر گام صادر می‌شوند، با orchestrator به‌عنوان تنها دارنده — اما آن معماری هزینه‌ی خودش را در latency و پیچیدگی دارد. قرارداد حالت پایانی میانه‌ی عمل‌گرایانه است: یک پنجره‌ی آشتی‌دهی کرا
بررسی‌های عملیاتی
مجوزهای دائمی‌ای که هویت‌های agent در اختیار دارند را برشمارید و آن‌ها را با اجراهای فعال مقایسه کنید. تفاوت، همان مواجهه است. این یک join بین دو مجموعه‌داده است که بیشتر تیم‌ها از قبل دارند: فهرست مجوزهای صادرشده‌ی مرجع اعتبارنامه و فهرست وظایف در حال اجرای orchestrator. این پرس‌وجو عجیب نیست، اما به‌ندرت اجرا می‌شود، چون اعتبارنامه‌های agent اغلب به‌عنوان زیرساخت تلقی می‌شوند نه entitlement.
برای مجوزهایی که بیش از یک حاشیه‌ی تعریف‌شده از اجرایشان عمر بیشتری می‌کنند هشدار بدهید. حاشیه یک تصمیم سیاستی است، نه یک ثابت فنی. حاشیه‌ای در حد چند دقیقه، تأخیر آشتی‌دهی را در نظر می‌گیرد؛ حاشیه‌ای در حد چند ساعت نشان می‌دهد که رویداد پایانی منتشر یا مصرف نمی‌شود. هشدار باید روی مجوز فعال شود، نه روی agent، چون agent واحد ریسک نیست. مجوز است.
با مجوزهای یتیم به‌عنوان یک آیتم بازبینی دسترسی با همان آهنگ entitlementهای انسانی برخورد کنید. اگر دسترسی یک کارمند انسانی فصلی بازبینی می‌شود، مجوزهای دائمی یک agent باید با همان زمان‌بندی و همان الزامات شواهد بازبینی شوند. بازبینی باید یک پرسش مشخص بپرسد: این مجوزها با کدام اجراها مرتبط‌اند، و آیا آن اجراها هنوز فعال‌اند؟ مجوزی که نمی‌توان آن را با یک اجرای فعال مرتبط کرد یک یافته است، نه یک مثبت کاذب.
نکته‌ی عمیق‌تر این است که اعتبارنامه‌های agent یک مورد خاص نیستند. آن‌ها entitlementهایی با یک چرخه‌ی حیات هستند، و چرخه‌ی حیات به یک حالت پایانی نیاز دارد. انقضا یک ویژگی اعتبارنامه است؛ پایان یک ویژگی مجوز است. اشتباه گرفتن این دو چیزی است که یک اجرای تکمیل‌شده را به یک مجوز دائمی تبدیل می‌کند. راه‌حل یک ساعت کوتاه‌تر نیست. راه‌حل یک قراردادی است که می‌گوید: وقتی کار پایان می‌یابد، دسترسی پایان می‌یابد.
ابتدا چه چیزی را ابزارگذاری کنیم
با شناسه‌ی اجرا شروع کنید. اگر مجوزها را نتوان به یک اجرا گره زد، هیچ قرارداد چرخه‌ی حیاتی ممکن نیست. سپس رویداد پایانی را از orchestrator منتشر کنید، حتی اگر مرجع اعتبارنامه هنوز آن را مصرف نمی‌کند، تا جریان رویداد وجود داشته باشد و قابل بازپخش باشد. سپس جاروب آشتی‌دهی را بسازید، چون پشتیبان هر حالت شکستی است که مسیر رویداد پوشش نمی‌دهد. ترتیب مهم است: ابتدا هویت، دوم رویدادها، سوم آشتی‌دهی. پرش از گام اول هشدارهایی تولید می‌کند که قابل اقدام نیستند؛ پرش از گام سوم سیستمی تولید می‌کند که تنها زمانی درست است که همه‌چیز دیگر درست باشد.