اعتبارنامه امانی: دسترسی عامل هوش مصنوعی بدون نگهداری رازها

از عامل حساب‌های پرداختنی خواسته می‌شود یک سفارش خرید تأییدشده را بخواند، آن را با فاکتور تطبیق دهد و فاکتور منطبق را وارد صف بررسی سامانه برنامه‌ریزی منابع سازمان کند. در پیاده‌سازی سریع، کلید حساب خدمت ERP داخل محیط اجرای عامل کپی می‌شود. این کلید همه سفارش‌ها را می‌خواند، در چند صف می‌نویسد و ماه‌ها معتبر می‌ماند. ممکن است در رد ابزار، گزارش خرابی، prompt کپی‌شده یا پردازش فرزند عامل ظاهر شود. حتی اگر مدل وظیفه درست را انجام دهد، اعتبارنامه پیشاپیش از مرز نادرست گذشته است.

تصمیم خواننده از پرسش کلی «عامل هوش مصنوعی را چگونه امن کنیم؟» محدودتر و کاربردی‌تر است: آیا عامل اصلاً باید اعتبارنامه بگیرد و اگر پاسخ مثبت است، چگونه آن را به بار کاری، کاربر یا خدمت آغازگر، وظیفه، مشتری، مقصد، عمل و بازه زمانی مقید کنیم؟ در عملیات پرپیامد، پاسخ بهتر اغلب این است که یک واسط مورد اعتماد عمل را انجام دهد و فقط نتیجه را به عامل برگرداند.

هویت، اختیار و اعتبارنامه را از هم جدا کنید

سه مفهوم معمولاً در عبارت «کلید API عامل» ادغام می‌شوند:

• هویت می‌گوید کدام نمونه بار کاری، از کدام نرم‌افزار و محیط اجرا شده و در صورت لزوم کدام کاربر یا خدمت وظیفه را آغاز کرده است.
• اختیار می‌گوید آن هویت با کدام نسخه سیاست، برای کدام مشتری و هدف، اجازه چه عملی را روی چه منبعی دارد.
• اعتبارنامه مدرکی است که به یک منبع مشخص ارائه می‌شود. این مدرک باید فقط اختیار لازم در همان مقصد و برای مدتی کوتاه را حمل یا به آن ارجاع دهد.

این جداسازی مهم است؛ زیرا یک هویت برای وظایف مختلف اختیار متفاوت می‌گیرد و یک وظیفه ممکن است برای چند مقصد اعتبارنامه جدا بخواهد. توکن مورد قبول مخزن سند نباید در API پرداخت کار کند. کاربر شاید حق تأیید فاکتور داشته باشد، اما مجاز نباشد یک هویت تأییدکننده و قابل‌استفاده مجدد به عامل ببخشد. طراحی باید زنجیره را حفظ کند، نه آنکه عامل، کاربر و خدمت را در یک حساب تخت ادغام کند.

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

«بدون اعتبارنامه» را به گزینه واقعی معماری تبدیل کنید

بررسی هر اتصال را با سه الگو آغاز کنید؛ از کمترین تا بیشترین اختیار قابل‌استفاده مجدد در مرز عامل:

«بدون اعتبارنامه» به معنای «بدون دسترسی» نیست. عامل درخواستی نوع‌دار مانند read_purchase_order(tenant, po_id) به واسط می‌دهد. واسط هویت بار کاری را احراز، پاکت وظیفه را اعتبارسنجی، سیاست و تازگی را بررسی و منبع را با هویت کنترل‌شده خود فراخوانی می‌کند؛ سپس پاسخ را محدود و نتیجه را برمی‌گرداند. راز منبع هرگز وارد زمینه مدل، آرگومان ابزار، پردازش افزونه یا حافظه عمومی عامل نمی‌شود.

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

پیش از صدور دسترسی، مسیر اعتماد را بسازید

واسط نباید ادعای «من عامل خرید هستم» را از prompt یا بدنه درخواست بپذیرد. به هویت قابل‌اثبات بار کاری نیاز دارد که ریشه آن سکوی اجرا باشد. NIST SP 800-207A که در سپتامبر ۲۰۲۳ منتشر شد، اعتماد صفر در محیط ابری را بر هویت برنامه و خدمت بنا می‌کند و اجرا را به اجزایی مانند دروازه API، همراه جانبی و زیرساخت هویت می‌سپارد، نه صرفاً محل شبکه.

مدل هویت بار کاری SPIFFE سازوکاری عملی ارائه می‌کند: بار کاری بدون دریافت راز احراز هویت هم‌مکان می‌تواند سند هویت کوتاه‌عمر و خودچرخان X.509 یا JWT بگیرد. سند، هویت بار کاری را ثابت می‌کند؛ به‌خودی‌خود همه مجوزهای برنامه را نمی‌دهد. SPIFFE همچنین یادآور می‌شود سند JWT توکن حامل است و تا انقضا بازپخش می‌شود، در حالی که هویت X.509 در ارتباط TLS دوسویه اثبات کلید خصوصی را می‌خواهد.

در Kubernetes، ابزار ترجیحی توکن چرخان و تزریق‌شده حساب خدمت برای مقصدی مشخص است، نه Secret دستی با عمر طولانی. راهنمای حساب خدمت Kubernetes صریحاً API درخواست توکن یا حجم توکن تزریقی را توصیه می‌کند و توکن بلندعمر مبتنی بر Secret را نامناسب می‌داند.

مسیر اعتماد حاصل چنین است:

1. سکو نمونه بار کاری و استقرار تأییدشده را گواهی می‌کند؛
2. برنامه آغازگر، مشتری، هدف، عمل، منبع، سیاست و مهلت را به پاکت وظیفه متصل می‌کند؛
3. واسط هر دو مدرک، لغو و تأیید را می‌سنجد و اختیار کوچک‌تری محاسبه می‌کند؛
4. واسط فراخوانی را انجام می‌دهد یا مدرک را با اعتبارنامه موقت مخصوص مقصد مبادله می‌کند؛
5. منبع اختیار را اجرا و رسید اثر را بازمی‌گرداند؛
6. شواهد، هویت، وظیفه، سیاست، درخواست و اثر را بدون ثبت اعتبارنامه متصل می‌کند.

موقعیت شبکه می‌تواند نشانه کمکی باشد، اما هویت نیست. پردازشی در subnet درست که توکن کپی‌شده دارد، همچنان بار کاری نادرست است.

مدرک را مبادله کنید، نه کلید مادر را

RFC 8693 درباره تبادل توکن OAuth 2.0 که در ژانویه ۲۰۲۰ استاندارد شد، تعامل با خدمت توکن امنیتی را تعریف می‌کند؛ یک توکن با توکن دیگری مبادله می‌شود. مفاهیم subject و actor می‌توانند میان کسی که کار به نمایندگی او انجام می‌شود و کسی که عمل می‌کند تفاوت بگذارند. این سند همچنین impersonation را، که در آن عامل از صاحب اختیار قابل‌تشخیص نیست، از delegation جدا می‌کند؛ در تفویض، عامل همچنان شناخته می‌شود.

این تفاوت برای عامل‌ها حیاتی است. ممیزی پایین‌دستی باید بگوید «نسخه ۷ عامل خرید برای کارمند ۴۲ و در وظیفه ۹۱۳ عمل کرد»، نه فقط «کارمند ۴۲ ERP را فراخواند». اگر قرارداد مقصد هر دو هویت را حمل نمی‌کند، رابطه حذف‌شده را در سابقه مبادله‌ای تغییرناپذیر و متصل با شناسه‌ای غیرمحرمانه نگه دارید. claimای نسازید که مقصد آن را اعتبارسنجی نمی‌کند.

RFC 9700، رویه برتر امنیت OAuth 2.0 که در ژانویه ۲۰۲۵ منتشر شد، توکن دسترسی محدود به مقصد و مقید به فرستنده را برای کاهش سوءاستفاده از توکن نشت‌کرده توصیه می‌کند. همچنین بر کمینه‌سازی دامنه و حفاظت توکن نوسازی، از جمله چرخش یا تقید به فرستنده برای client عمومی، تأکید دارد. ترجمه عملی آن روشن است:

• تبادل در آخرین لحظه مسئولانه، پس از سیاست و تأیید کاربر انجام شود؛
• توکن برای یک خدمت مقصد و کوچک‌ترین مجموعه عمل صادر شود؛
• عمر توکن از زمان باقی‌مانده وظیفه کوتاه‌تر باشد؛
• در صورت پشتیبانی اکوسیستم، توکن با TLS دوسویه یا اثبات مالکیت به فرستنده مقید شود؛
• توکن نوسازی و ماده امضای بلندعمر داخل واسط بماند و وارد وضعیت قابل‌مشاهده مدل یا افزونه نشود؛
• اعتبارنامه ناسازگار با مقصد، مشتری، subject، actor، وظیفه یا نسخه سیاست رد شود.

اعتبارنامه موقت در سکوهای اصلی ابری تثبیت شده است. اعتبارنامه موقت AWS STS پویا ساخته و منقضی می‌شود و نیاز به جاسازی اعتبارنامه بلندعمر را از میان می‌برد. راهنمای Google Cloud برای هم‌پیمانی هویت بار کاری تبادل اعتبار بیرونی با دسترسی کوتاه‌عمر را توضیح می‌دهد، هویت اختصاصی را به‌جای مجوز سراسری pool توصیه می‌کند و endpoint منطقه‌ای توکن را پیشنهاد می‌دهد. این‌ها مصالح‌اند، نه اثبات درستی سیاست عامل.

در OAuth کاربر، رضایت اتصال، مجوز فعلی منبع و اجازه همین وظیفه را جدا نگه دارید. توکن نوسازی در خدمت اختصاصی اعتبارنامه بماند و عامل فقط دستگیره‌ای مبهم بگیرد. واسط هنگام فراخوانی وضعیت کاربر، مشتری، scope و تأیید تکمیلی را دوباره می‌سنجد و سپس دسترسی را نوسازی یا مبادله می‌کند. اگر scope ارائه‌دهنده درشت است، میانجی اتصال باید روش، فیلد، شناسه منبع، نرخ و داده پاسخ را باریک کند.

اختیار را به پاکت وظیفه مقید کنید

واسط به درخواستی تغییرناپذیر و غنی‌تر از یک رشته scope نیاز دارد. پاکت عملی می‌تواند این فیلدها را داشته باشد:

مدل می‌تواند پیشنهاد را پر کند، اما نباید فیلد مطمئن را امضا، گسترش یا انتخاب کند. دستگیره منبع را در سرور حل کنید: «فاکتور ۸۱۱» پس از جست‌وجوی محدود به مشتری باید به شناسه تغییرناپذیر شیء پایگاه داده تبدیل شود، نه مسیر پیشنهادی مدل. هر تبادل پایین‌دستی فقط پاکت را کوچک می‌کند؛ هیچ‌کدام حق افزایش انقضا، افزودن عمل، تغییر مشتری یا جایگزینی منبع را ندارد.

اینجاست که جداسازی مشتری قطعی می‌شود. توکن دارای invoice:write که برای همه مشتریان پذیرفته شود محدود نیست. هویت مشتری باید از عضویت مطمئن مشتق، به تصمیم سیاست متصل و در خود منبع دوباره اجرا شود؛ نه اینکه از آرگومان ابزار پذیرفته شود.

مثال عملی: یک فاکتور و دو اثر

به وظیفه آغازین برگردیم. کارمند U-42 می‌تواند برای مشتری T-8 فاکتور ثبت کند، اما مجوز آزادسازی پرداخت ندارد. گردش کار مجاز خواندن سفارش PO-91، مقایسه با فاکتور INV-811 و ساخت سابقه تطبیق در صف بررسی است.

1. هماهنگ‌کننده هویت ap-agent@prod را می‌گیرد، طرح ابزار تأییدشده را هش می‌کند و وظیفه TASK-913 را با مهلت پنج دقیقه می‌سازد.
2. واسط PO-91 و INV-811 را درون T-8 حل می‌کند، باقی‌بودن نقش ثبت‌کننده برای U-42 را می‌سنجد و نسخه ۳۱ سیاست را ثبت می‌کند.
3. برای خواندن، مدرک بار کاری با توکن ۴۵ثانیه‌ای مبادله می‌شود که فقط API خرید آن را می‌پذیرد و عمل po:read آن به همان سابقه محدود است. توکن نه صف را فراخوانی می‌کند و نه مشتری دیگر را.
4. عامل فیلدهای محدود را مقایسه و سابقه تطبیق را پیشنهاد می‌کند. هرگز اعتبارنامه بلندعمر ERP یا توکن نوسازی را نمی‌بیند.
5. برای نوشتن، واسط schema سخت را بررسی، جمع مبلغ را دوباره محاسبه و review_queue:create را مستقیم با کلید یکتایی TASK-913:match اجرا می‌کند. عامل رسید می‌گیرد، نه اعتبارنامه صف.
6. آزادسازی پرداخت به تأیید جداگانه انسان نیاز دارد. هیچ توکن این وظیفه آن عمل را در خود ندارد.

prompt injection داخل فاکتور نمی‌تواند فروشندگان دیگر را بخواند، زیرا توکن به یک مقصد و سابقه محدود است. اگر توکن نشت کند، ۴۵ ثانیه تنها دفاع نیست؛ مقصد، منبع، عمل، مشتری و ترجیحاً فرستنده بازپخش را محدود می‌کنند. اگر نقش U-42 وسط وظیفه حذف شود، تغییر نسخه عضویت باعث رد نوشتن می‌شود، هرچند خواندن قبلی مشروع بوده است.

شکست، بازپخش و انجام ناقص را طراحی کنید

اگر مسیر عادی باریک باشد اما بازیابی بی‌صدا اختیار را وسیع کند، واسطه‌گری شکست خورده است. این حالت‌ها را بیازمایید:

1. انقضای توکن هنگام retry پس از پایان مهلت اصلی وظیفه؛
2. صدور توکن پیش از حذف کاربر، تعلیق مشتری، تغییر سیاست یا rollback مدل؛
3. بازپخش همان درخواست تبادل، دستگیره قابلیت یا عمل پرخطر؛
4. ارائه توکن با مقصد غلط به gateway سهل‌گیر؛
5. کپی توکن معتبر از بار کاری تأییدشده به پردازش فرزند تأییدنشده؛
6. درخواست عامل با شناسه مشتری بیگانه، دستگیره جعلی یا عمل اضافی؛
7. قطع واسط پس از commit منبع و پیش از ثبت رسید؛
8. رقابت چرخش توکن، اختلاف ساعت یا مسیر اضطراری که واسط را دور می‌زند.

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

اختیار را بسنجید، نه استفاده از گاوصندوق را

نموداری که می‌گوید «صد درصد رازها در vault هستند» نشان نمی‌دهد عامل چه می‌تواند بکند. اختیار صادرشده و مصرف‌شده را بسنجید:

خود توکن را لاگ نکنید. اثر انگشت محافظت‌شده، مقصد، عمل، subject، actor، مشتری، وظیفه، صدور و انقضا، نسخه سیاست، تصمیم، رسید اثر و علت رد را ثبت کنید. شواهد را محافظت کنید؛ ردی که اعتبارنامه قابل‌استفاده دارد خود مسیر نفوذ است.

راهنمای شواهد ممیزی معیار مناسبی می‌دهد: ورودی تصمیم و رسید اثر لازم برای اثبات کنترل را حفظ کنید، نه فقط تصویر تنظیمات یا روایت عامل از کاری که انجام داده است.

دروازه انتشار واسط اعتبارنامه

پیش از فعال‌کردن اتصال عامل بررسی کنید:

• منبع، عمل، مشتری، subject، actor، هدف و بیشینه مدت وظیفه تعریف شده است؛
• هویت بار کاری ریشه‌دار در سکو مستقل از خروجی مدل تأیید می‌شود؛
• پیش از تصمیم به صدور اعتبارنامه، اجرای عمل توسط واسط ارزیابی شده است؛
• هر توکن یک مقصد، مجموعه باریک عمل و منبع و عمر متناسب با ریسک دارد؛
• برای توکن حامل، تقید به فرستنده یا تصمیم صریح پذیرش خطر بازپخش وجود دارد؛
• توکن نوسازی، کلید امضا، کلید حساب خدمت و راز client بیرون وضعیت قابل‌خواندن عامل می‌ماند؛
• منبع اختیار را مستقل اجرا می‌کند و مشتری یا منبع را فقط از آرگومان ابزار نمی‌پذیرد؛
• تفویض هم صاحب اختیار و هم عامل را حفظ می‌کند و در صورت محدودیت قرارداد مقصد، پیوند تغییرناپذیر دارد؛
• تأیید انسان به همان درخواست پرخطر نرمال‌شده مقید است و retry تغییرکرده را مجاز نمی‌کند؛
• یکتایی، بازیابی commit ناقص، لغو، اختلاف ساعت و قطعی واسط در مقصد اثر واقعی آزموده شده‌اند؛
• لاگ، prompt، trace، حافظه و داده ارزیابی برای ماده اعتبارنامه پویش می‌شوند؛
• استثنای اعتبارنامه ایستای قدیمی مالک، میانجی جبرانی، برنامه چرخش و تاریخ حذف دارد.

چه زمانی تصمیم را بازبینی کنیم

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

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

یادداشت منابع — بازبینی‌شده در ۱۷ اوت ۲۰۲۶

• RFC 9700: رویه برتر امنیت OAuth 2.0 — ژانویه ۲۰۲۵؛ محدودیت مقصد، تقید فرستنده، کمینه‌سازی و حفاظت توکن نوسازی.
• RFC 8693: تبادل توکن OAuth 2.0 — ژانویه ۲۰۲۰؛ تبادل، subject، actor، impersonation و delegation.
• NIST SP 800-207A: الگوی معماری اعتماد صفر برای کنترل دسترسی برنامه ابری — سپتامبر ۲۰۲۳؛ هویت برنامه و خدمت ابری.
• SPIFFE: مفاهیم — بازبینی اوت ۲۰۲۶؛ هویت کوتاه‌عمر، چرخش و خطر بازپخش.
• Kubernetes: حساب‌های خدمت — بازبینی اوت ۲۰۲۶؛ توکن تزریقی چرخان و هشدار توکن بلندعمر.
• AWS IAM: اعتبارنامه امنیتی موقت — بازبینی اوت ۲۰۲۶؛ اعتبارنامه پویا و محدود STS.
• Google Cloud: رویه‌های برتر هم‌پیمانی هویت بار کاری — بازبینی اوت ۲۰۲۶؛ تبادل کوتاه‌عمر، هویت اختصاصی، مجوز باریک و endpoint منطقه‌ای.