‏هویت ایجنت‌های هوش مصنوعی؛ کدوم مدل درسته؟

نویسنده به این سوال جواب می‌ده که وقتی یه ایجنت هوش مصنوعی کاری انجام می‌ده، باید با چه هویتی اون کارو بکنه. به گفتهٔ نویسنده همین انتخاب تعیین می‌کنه که بشه کار ایجنت رو بهش نسبت داد، بتونه موقعی که تو خوابی هم کار کنه، بعد از عوض‌شدن تیم یا رفتنت از شرکت دووم بیاره، و لو رفتن یه اعتبارنامه چقدر خسارت بزنه. سه راه کلی هست و یه لایهٔ زیرساختی هم روی هر سه سوار می‌شه.

مدل اول، ساده‌ترینه: ایجنت به‌جای خود کاربر کار می‌کنه، با سشن و دسترسی‌های خودت. چیزی لازم نیست ساخته بشه و برای کارهای کوتاه و تعاملی عالیه. ولی نویسنده می‌گه تا کار از سشن طولانی‌تر می‌شه همه‌چی به‌هم می‌ریزه؛ سشن وسط کار منقضی می‌شه و مکانیزم‌های re-auth که برای آدم ساخته شدن برای ایجنت جواب نمی‌دن. بدترش اینه که تو لاگ‌ها معلوم نیست خودت اون کارو کردی، ایجنت به دستور تو، یا ایجنت خودسر — و این مدل تک‌نفره‌ست، پس با رفتنت workflow می‌شکنه.

مدل دوم، دادن یه سرویس‌اکانت با توکن API به ایجنته؛ همون دنیای هویت‌های غیرانسانی (NHI). نویسنده معتقده این بدترین گزینه‌ست: توکن‌ها معمولاً عمر طولانی دارن، اغلب تک‌عاملی‌ان و آخرش توی وُلت‌های اشتراکی و متغیرهای محیطی بین همه پخش می‌شن. راهنمای Zero Trust شرکت Anthropic هم صریح می‌گه کلیدهای API ثابت رو باید همون‌اول لو رفته فرض کنی و توکن‌های کوتاه‌عمر رو پایه بذاری.

مدل سوم، دادن یه workload identity به ایجنته، با استانداردهایی مثل SPIFFE و پیاده‌سازی‌هایی مثل SPIRE. اینجا workload اول با attestation ثابت می‌کنه چیه، بعد یه هویت کوتاه‌عمر و قابل‌راستی‌آزمایی می‌گیره که هیچ رازِ موندگاری برای دزدیدن نداره. Uber روش یه سرویس توکن گذاشته که زنجیرهٔ actor رو حمل می‌کنه تا انتساب توی چند مرحله حفظ بشه. عیبش هزینهٔ راه‌اندازیه؛ به گفتهٔ نویسنده گاهی راه‌اندازی SPIRE شش تا بیست‌وچهار ماه طول می‌کشه.

روی هر سه مدل هم می‌شه یه لایهٔ plumbing گذاشت که دو کار می‌کنه. اولی بروکرینگه — مثل Cross App Access اوکتا روی افزونهٔ ID-JAG که به‌جای grant پهن، توکن‌های کوتاه‌عمر و محدود صادر می‌کنه. نویسنده تأکید می‌کنه این یه مدل چهارم نیست، فقط توکن‌ها رو تمیزتر می‌کنه. کار دوم حاکمیته: Entra Agent ID و Okta for AI Agents ایجنت‌ها رو کشف می‌کنن، به هرکدوم یه صاحبِ انسانی می‌دن، اعتبارنامه‌شونو می‌چرخونن و کلید قطع و رد لاگ بهت می‌دن.

مهم‌ترین تحول به گفتهٔ نویسنده پیش ارائه‌دهنده‌های ابریه که مدل سوم رو آماده می‌فروشن. AWS Bedrock AgentCore Identity و Google Agent Identity (که زیرش SPIFFE هست) هویت workload به‌علاوهٔ وُلت توکن و بروکرینگ رو باهم می‌دن. اگه رو AWS یا GCP زندگی می‌کنی، می‌تونی workload identity مدیریت‌شده رو بخری به‌جای اینکه بسازی؛ ولی تو محیط چندابری کار چسبوندنش بیشتر می‌شه.

توصیهٔ نویسنده اینه که بیشتر سازمان‌ها الان ترکیبی از مدل ۱ و ۲ رو دارن. از مدل ۱ شروع کن و دور و برش حاکمیت و کاربردپذیری بساز؛ مدل ۲ عالی نیست ولی اگه راهی به ۳ نداری، همونو تا می‌تونی امن کن؛ و مدل ۳ فقط برای بخش کوچیکی از تیم‌های مهندسی‌محور شدنیه. هشدار آخرش هم اینه که اگه امنیت فقط بگه «نه»، آدم‌ها ایجنت رو می‌برن یه جایی که دیگه اصلاً نمی‌بینیش.

نکات کلیدی:

• هویت ایجنت روی انتساب کارها، دووم workflow و خسارت لو رفتن توکن مستقیم اثر می‌ذاره
• سه مدل: به‌جای کاربر، سرویس‌اکانت (NHI)، و workload identity مثل SPIFFE
• کلیدهای API ثابت رو باید لو رفته فرض کرد؛ توکن کوتاه‌عمر پایه‌ست
• بروکرینگ (XAA/ID-JAG) و حاکمیت (Entra، Okta) لایه‌ای هستن روی هر سه مدل، نه مدل جدا
• ابری‌ها (AWS Bedrock، Google Agent Identity) مدل سوم رو آماده می‌فروشن