الگوی گزارش‌شده
سیستم‌های عامل به‌طور فزاینده‌ای برای انجام وظایفی مستقر می‌شوند که نیازمند دسترسی به داده‌های شرکت هستند: خواندن مخازن، پرس‌وجو از پایگاه‌های داده، فراخوانی APIهای داخلی. مشاهده‌ای مکرر در بازبینی‌های عملیاتی این است که پس از پایان اجرای یک عامل، اعتبارنامه‌های آن همچنان معتبر باقی می‌مانند. عامل دیگر در حال اجرا نیست، اما توکن یا کلیدی که استفاده کرده هنوز دسترسی می‌دهد. این مسئلهٔ استخدام یا خروج از سازمان نیست. شکاف بین اتمام وظیفه و انقضای اعتبارنامه است.
در جریان‌های کاری متعارف انسانی، دسترسی به نقش فرد گره خورده و به‌صورت دوره‌ای بازبینی می‌شود. در جریان‌های کاری عامل، دسترسی به یک وظیفه گره خورده، اما چرخهٔ عمر اعتبارنامه اغلب از رازهای ایستا یا حساب‌های سرویس بلندمدت به ارث می‌رسد. نتیجه، دسته‌ای از اعتبارنامه‌هاست که از کاری که برای آن صادر شده‌اند عمر بیشتری می‌کنند.
چرا TTLها ابتدایی نادرست هستند
یک زمان‌به‌انقضا (time-to-live) ثابت، حدسی دربارهٔ مدت زمان انجام یک وظیفه است. اجراهای عامل انفجاری‌اند: ممکن است در چند ثانیه کامل شوند، یا برای دقایقی در انتظار محدودیت نرخ، تأیید انسانی، یا رویدادی خارجی متوقف بمانند. TTLی که به‌قدر کافی کوتاه باشد تا برای یک پرس‌وجوی سریع ایمن باشد، در میانهٔ یک کار طولانی‌مدت مشروع منقضی می‌شود. TTLی که به‌قدر کافی بلند باشد تا بدترین حالت را پوشش دهد، پنجرهٔ گسترده‌ای از دسترسی غیرضروری باقی می‌گذارد.
عامل‌های طولانی‌مدت با checkpointing می‌توانند از هر TTL معقولی عمر بیشتری کنند. وقتی عاملی وضعیت را ذخیره و بعداً از سر می‌گیرد، اعتبارنامهٔ اصلی ممکن است منقضی شده باشد و تجدید را ایجاب کند. اگر تجدید خودکار باشد و وظیفه را دوباره مجاز نکند، اعتبارنامه عملاً به‌طور نامحدود تمدید می‌شود. TTL به یک تشریفات تبدیل می‌شود: اعتبارنامهٔ کوتاه‌مدتی که بدون بازبینی تجدید می‌شود، یک اعتبارنامهٔ دائمی با چند مرحلهٔ اضافی است.
مسئلهٔ عمیق‌تر این است که TTLها زمان را می‌سنجند، نه اختیار را. آن‌ها به «چه مدت؟» پاسخ می‌دهند، اما نه به «برای چه؟» یا «تحت کنترل چه کسی؟» عاملی که وظیفه‌اش را در ده ثانیه تمام می‌کند و عاملی که ده ساعت اجرا می‌شود، هر دو همان دستهٔ اعتبارنامه را دریافت می‌کنند، فقط با مهرهای زمانی انقضای متفاوت.
گره زدن اختیار به اجرا
مدل مقاوم‌تر، اعتبارنامه‌ها را به شناسهٔ اجرا و وظیفهٔ اعلام‌شده گره می‌زند. به‌جای صدور توکنی با انقضای ثابت، orchestrator اعتبارنامه‌ای صادر می‌کند که تنها تا زمانی که اجرا فعال است و تنها برای عملیات اعلام‌شده در مشخصات وظیفه معتبر است. اعتبارنامه یک توکن حامل نیست که هر جایی قابل استفاده باشد؛ یک capability است که به اجرایی مشخص و مجموعه‌ای مشخص از کنش‌ها محدود شده است.
orchestrator به‌عنوان مرجع ابطال
orchestratori که اجرا را آغاز می‌کند باید همان مرجعی باشد که می‌تواند اعتبارنامه را باطل کند. وقتی اجرا پایان می‌یابد — چه با اتمام، شکست، یا لغو — orchestrator اجرا را غیرفعال علامت می‌زند. هر اعتبارنامه‌ای که با آن شناسهٔ اجرا ارائه شود رد می‌شود. این پیش‌فرض را معکوس می‌کند: به‌جای تکیه بر انقضا، سیستم بر زنده‌بودن تکیه می‌کند. اجرای زنده‌ای نباشد، اعتبارنامهٔ معتبری نیست.
از سرگیری به‌عنوان رویداد مجوزدهی جدید
وقتی عاملی از یک checkpoint از سر می‌گیرد، در حال آغاز یک زمینهٔ اجرای جدید است. orchestrator باید این را به‌عنوان یک رویداد مجوزدهی جدید تلقی کند: وظیفه را دوباره ارزیابی کند، اعتبارنامه‌ای محدود به اجرای از سر گرفته‌شده صادر کند، و همان بررسی‌های سیاستی اجرای اصلی را الزامی کند. این مانع از آن می‌شود که یک checkpoint به دری پشتی برای دسترسی نامحدود تبدیل شود. هزینهٔ این کار تأخیر و پیچیدگی افزوده است: هر از سرگیری یک رفت‌وبرگشت مجوزدهی را تحمیل می‌کند، و orchestrator باید وضعیت این‌که کدام اجراها فعال‌اند را نگه دارد. برای عامل‌های پربسامد و کوتاه‌مدت، این سرباز ممکن است قابل قبول باشد؛ برای خطوط لولهٔ حساس به تأخیر، ممکن است نیازمند caching یا پیش‌مجوزدهی برای الگوهای وظیفهٔ شناخته‌شده باشد.
سازوکار مشخص: توکن‌های محدود به اجرا
یک پیاده‌سازی عملی از توکنی امضاشده استفاده می‌کند که شناسهٔ اجرا، دامنهٔ وظیفه، و امضای orchestrator را در خود جای می‌دهد. توکن به یک نقطهٔ اجرای سیاست (PEP) ارائه می‌شود که دو چیز را بررسی می‌کند: امضا معتبر است، و شناسهٔ اجرا در مخزن وضعیت orchestrator فعال علامت خورده است. PEP تنها بر انقضای توکن تکیه نمی‌کند. اگر orchestrator اجرا را پایان‌یافته علامت زده باشد، توکن رد می‌شود حتی اگر انقضایش در آینده باشد. این سازوکار نیازمند یک مخزن وضعیت مشترک بین orchestrator و PEP است، و مسیری برای ابطال که به‌قدر کافی سریع باشد تا اهمیت داشته باشد. هزینهٔ این کار وابستگی به دسترس‌پذیری orchestrator است: اگر مخزن وضعیت در دسترس نباشد، PEP باید تصمیم بگیرد که fail open کند یا fail closed. fail closed ایمن‌تر ا
تشخیص
حتی با اعتبارنامه‌های محدود به اجرا، تشخیص ضروری است. گزارش‌های حسابرسی باید طوری ابزارگذاری شوند که اعتبارنامه‌های استفاده‌شده پس از پایان اجرای صادرکننده‌شان را علامت‌گذاری کنند. این یک پرس‌وجوی سرراست است اگر اعتبارنامه شناسهٔ اجرا را حمل کند: گزارش استفادهٔ اعتبارنامه را با گزارش چرخهٔ عمر اجرا join کنید و رویدادهای استفاده‌ای را بیابید که اجرا پیش از مهر زمانی استفاده پایان یافته است.
سنجهٔ دوم، شکاف بین آخرین tool call و انقضای اعتبارنامه است. در یک سیستم سالم، این شکاف برای اجراهای کامل‌شده باید نزدیک به صفر باشد: اعتبارنامه باید به‌محض پایان اجرا نامعتبر شود. شکاف پایدار نشان می‌دهد که اعتبارنامه‌ها از اجراهایشان عمر بیشتری می‌کنند، چه از طریق تجدید، caching، یا ناکامی در ابطال. ردیابی این شکاف در طول زمان، پس‌رفت‌ها در مسیر ابطال را آشکار می‌کند.
سیگنال سوم، نرخ رویدادهای از سرگیری است که مجوزدهی مجدد را برنمی‌انگیزند. اگر از checkpointها برای تمدید دسترسی بدون رویداد مجوزدهی جدید استفاده می‌شود، این نقض سیاست است که باید در رد حسابرسی قابل مشاهده باشد.
واقعیت عملیاتی
پیاده‌سازی اعتبارنامه‌های محدود به اجرا و ابطال مبتنی بر orchestrator رایگان نیست. نیازمند تغییراتی در نحوهٔ درخواست دسترسی توسط عامل‌ها، نحوهٔ ردیابی وضعیت اجرا توسط orchestrator، و نحوهٔ اعتبارسنجی اعتبارنامه‌ها توسط نقاط اجرای سیاست است. وابستگی به زنده‌بودن orchestrator و گلوگاه بالقوه در مخزن وضعیت را معرفی می‌کند. برای سیستم‌هایی که از قبل یک orchestrator مرکزی با مدیریت وضعیت قابل اعتماد دارند، تغییر تدریجی است. برای سیستم‌هایی که عامل‌ها زیرعامل تولید می‌کنند یا در چند orchestrator عمل می‌کنند، همگام‌سازی وضعیت پیچیده‌تر می‌شود.
جایگزین — تکیه بر TTLها و بازبینی‌های دوره‌ای — پیاده‌سازی ساده‌تری دارد اما شکافی ساختاری باقی می‌گذارد. شکاف بین استخدام و اخراج نیست؛ بین اتمام وظیفه و انقضای اعتبارنامه است. بستن آن شکاف نیازمند برخورد با اعتبارنامه‌ها به‌عنوان capabilityهای گره‌خورده به یک اجرا است، نه رازهایی با یک تایمر.