عددی که اهمیت دارد سهم فعالیت نیست
گزارش‌دهی درباره ناوگان‌های عامل معمولاً به شکل یک آماره فعالیت ارائه می‌شود: تیتر خبر می‌گوید بیشتر عامل‌ها غیرفعال‌اند، اما همچنان اعتبارنامه‌ها و اتصال‌های باز را حفظ می‌کنند. رقم فعالیت کم‌جالب‌ترین بخش این جمله است. واقعیت عملیاتی، ماندگاری حق دسترسی است — اعتبارنامه‌ها از کار جان سالم به در می‌برند.
گزارش‌های پشت این چارچوب‌بندی ارزش خواندن مستقیم را دارند (یک روایت، و روایتی دیگر). هیچ‌کدام سازوکار زیربنایی را تغییر نمی‌دهند: عاملی که ماه‌ها هیچ ابزاری را فراخوانی نکرده، همچنان به هر سرویس پایین‌دستی که زمانی به آن دسترسی گرفته، توکن معتبر ارائه می‌دهد.
غیرفعال بودن یک مصنوع استقرار است، نه یک تصمیم طراحی. نمونه‌های اولیه‌ای که هرگز ارتقا نیافتند. کارهای فصلی که فصلشان گذشته است. یکپارچه‌سازی‌هایی که با تغییر فروشنده رها شدند. نسخه‌های جایگزین‌شده عاملی که با نامی جدید دوباره مستقر شد، چون کنسول این کار را از مهاجرت آسان‌تر کرده بود. هیچ‌یک از این‌ها قرار نبود ماندگار باشند. ماندگار می‌مانند چون هیچ‌چیز در خط لوله یک وضعیت پایانی را تحمیل نمی‌کند. ایجاد یک دکمه است؛ از رده خارج کردن یک پروژه.
در مرز منابع — دروازه API، نقش پایگاه داده، مستأجر SaaS — یک principal بی‌کار با توکن معتبر از یک principal فعال قابل تشخیص نیست. توکن معتبر است، دامنه دسترسی حاضر است، فراخوانی موفق می‌شود. تنها سابقه چرخه حیات می‌تواند این دو را از هم تفکیک کند، و در بیشتر ناوگان‌ها چنین سابقه‌ای به شکلی که ماشین بتواند پرس‌وجو کند وجود ندارد.
چرا عامل‌ها متفاوت از حساب‌های سرویس فرسوده می‌شوند
حساب سرویس معمولاً یک اعتبارنامه با یک دامنه دسترسی است که تیم پلتفرم صادر می‌کند و طبق برنامه چرخانده می‌شود. اختیار یک عامل ترکیبی است و هر جزء آن با ساعت خودش کار می‌کند:
- کلید ارائه‌دهنده مدل، که اغلب میان چند عامل مشترک است و بنابراین هرگز برای هیچ‌یک به‌تنهایی چرخانده نمی‌شود؛
- اعتبارنامه‌های ابزار — یک گذرواژه پایگاه داده، یک کلید API داخلی — که هنگام ساخت فراهم و هنگام استقرار فراموش می‌شوند؛
- مجوزهای OAuth پایین‌دستی، که انقضای خود و رفتار تازه‌سازی خود را دارند و اغلب در یک مخزن توکن نگهداری می‌شوند که کسی فهرستش را ندارد؛
- دامنه دسترسی تفویض‌کننده، جایی که عامل به نمایندگی از یک انسان عمل می‌کند و هر آنچه آن انسان در لحظه رضایت می‌توانست به آن دست یابد را به ارث می‌برد.
چون این‌ها مستقل از هم منقضی می‌شوند، ترکیب تقریباً هرگز به‌صورت یک واحد از کار نمی‌افتد. کلید مدل چرخانده می‌شود، مجوز OAuth بی‌صدا تازه می‌شود، گذرواژه پایگاه داده سر جایش می‌ماند. عامل نگهداری‌شده به نظر می‌رسد. اما نیست: مجموعه‌ای از اعتبارنامه‌ها در مراحل مختلف فرسایش است و هیچ نمای واحدی اجتماع آن‌ها را نشان نمی‌دهد.
تفاوت دوم منشأ است. عامل‌ها معمولاً توسط تیم‌هایی خارج از کارکرد پلتفرم و از طریق کنسول‌هایی که برای اصطکاک کم طراحی شده‌اند ایجاد می‌شوند. این طراحی برای پذیرش درست و برای فهرست‌برداری نادرست است. تعداد principalها سریع‌تر از تعداد مالکان رشد می‌کند و شکاف میان این دو منحنی همان قرارگیری در معرض خطر است.
بازپس‌گیری به‌عنوان یک کنترل زمان‌بندی‌شده
برخورد با بازپس‌گیری به‌عنوان یک پروژه پاک‌سازی تضمین می‌کند که تکرار شود. پاک‌سازی رویدادی با شروع و پایان است؛ انبوه کار هفته بعد از بسته شدنش دوباره پر می‌شود. کنترل باید فرایندی زمان‌بندی‌شده با یک نتیجه پیش‌فرض باشد.
انقضا پیش‌فرض است. برای هر کلاس عامل — دستیارهای تعاملی، کارهای زمان‌بندی‌شده، پاسخ‌دهندگان رویدادمحور — آستانه بی‌فعالیتی تعریف کنید و آستانه را محرک تعلیق خودکار اعتبارنامه‌ها قرار دهید، نه بلیتی برای بازبینی توسط کسی. مجوزدهی مجدد کنش صریح است؛ اختیار مستمر چیزی است که نیاز به توجیه دارد. مقادیر آستانه تصمیمی سیاستی برای هر سازمان است؛ سازوکار چیزی است که اهمیت دارد.
مالکیت و هدف پیش‌شرط‌اند. عامل بدون مالک نام‌دار و هدف اعلام‌شده نمی‌تواند ایجاد شود و بدون برقرار بودن هر دو نمی‌تواند مجوزدهی مجدد شود. این تغییری کوچک در شِما با اثری بزرگ است: فهرست خودتوصیف می‌شود و principalهای بی‌سرپرست به‌طور ساختاری در بررسی شکست می‌خورند، نه از طریق حسابرسی.
عمر اعتبارنامه از عمر فرایند جدا می‌شود. اعتبارنامه باید طبق برنامه خودش منقضی شود، چه عامل در حال اجرا باشد چه نباشد. گره زدن انقضا به چرخه حیات کانتینر یعنی یک فرایند متوقف‌شده یک راز زنده را به‌طور نامحدود نگه می‌دارد — دقیقاً همان شکست غیرفعالی. توکن‌های کوتاه‌عمر که برای هر فراخوانی صادر می‌شوند و راز بلندعمر که در یک broker نگهداری می‌شود و عامل هرگز آن را نمی‌بیند، ماندگاری را کاملاً حذف می‌کنند.
رویدادهای بازپس‌گیری به همان رد حسابرسی کنش‌های عامل می‌روند. بیشتر گزارش‌های حسابرسی ثبت می‌کنند که یک principal چه کرد. کمتر پیش می‌آید که ثبت کنند اختیار چه زمانی و توسط کدام فرایند و تحت کدام نسخه سیاست پس گرفته شد. اگر رد فقط استفاده را نشان دهد، بازرس نمی‌تواند عاملی که ساکت بود را از عاملی که لغو شده تشخیص دهد — و نمی‌تواند اثبات کند که لغو اصلاً رخ داده است.
یک سابقه بازپس‌گیری حداقلی چنین است:
{
"principal_id": "agent:invoice-recon-v3",
"event": "credentials_revoked",
"reason": "inactivity_threshold_exceeded",
"last_successful_tool_call": "2025-01-14T09:22:07Z",
"grants_revoked": ["oauth:ledger.read", "db:recon_rw"],
"owner": "finance-ops",
"policy_version": "reclamation-v4",
"reauthorisation_path": "ticket:OPS-2214"
}
این بده‌بستان واقعی است و باید صریح بیان شود. بازپس‌گیری تهاجمی چیزها را می‌شکند. کارهای فصلی در فصل خود شکست می‌خورند اگر کسی مجوزدهی مجدد نکرده باشد؛ نمونه اولیه‌ای که به یک شریک سپرده شده وسط نمایش متوقف می‌شود؛ مهندس آنکال یک شب را صرف صدور مجدد دسترسی‌ها می‌کند. هزینه فوراً بر دوش افراد است و منفعت، نفوذی است که رخ نمی‌دهد، به‌صورت نامرئی. همین عدم تقارن دلیل فرسایش بازپس‌گیری است مگر آنکه خودکار شود و شکست‌هایش پرصدا و ارزان برای رفع باشند — یک مسیر مجوزدهی مجدد خودخدمت که دقیقه‌ها طول می‌کشد، نه یک هیئت مشورتی تغییر.
چه چیزی را باید پایش کرد
سنجه‌ای که اهمیت دارد سلامت کانتینر نیست.
آخرین فراخوانی موفق ابزار به ازای هر اعتبارنامه، نه آخرین ضربان به ازای هر فرایند. یک کانتینر در حال اجرا ممکن است هیچ کار مفیدی انجام ندهد در حالی که یک دسترسی زنده را نگه داشته است؛ یک کانتینر متوقف ممکن است همان دسترسی را نگه دارد بدون هیچ فرایندی برای مشاهده. اعتبارنامه واحد ریسک است، پس اعتبارنامه واحد سنجش است.
دسترسی‌های پایین‌دستی به‌عنوان اقلام فهرست درجه‌یک، هر یک با مالک و انقضای خودش، متصل به عاملی که آن‌ها را نگه می‌دارد. این تنها راه پاسخ به این است که یک عامل به چه چیزی می‌تواند دست یابد، بدون خواندن چهار سیستم و حدس زدن.
هشدارهای انحراف در مجموعه دسترسی‌ها. principalی که مجوزهایش بدون سابقه تغییر متناظر عوض شده، یا پیکربندی نادرست است یا نفوذ، و این دو بدون سابقه قابل تفکیک نیستند. روی دلتا هشدار بدهید، نه روی دامنه مطلق.
قاعده طراحی
هر principal عامل باید بتواند در هر لحظه به سه پرسش پاسخ دهد: چه کسی مالک آن است، به چه چیزی می‌تواند دست یابد، و اختیارش چه زمانی منقضی می‌شود. نه در یک ویکی، نه در یک صفحه‌گسترده که هر کسی که آن را ساخته نگه می‌دارد — بلکه در سیستمی که اعتبارنامه را صادر می‌کند، قابل پرس‌وجو با همان ابزارهایی که کنش‌هایش را حسابرسی می‌کنند.
اگر هر یک از این پاسخ‌ها نیازمند بازسازی توسط یک انسان از حافظه، تاریخچه گفتگو یا جست‌وجوی مخزن باشد، ناوگان ریسک اعلام‌نشده حمل می‌کند. عامل‌های غیرفعال استثنای این قاعده نیستند. آن‌ها دلیل وجود آن‌اند: عاملی که از عمل دست کشیده هنوز یک principal است، و principalی بدون چرخه حیات اعتبارنامه‌ای است بدون مالک.