گذرنامه عامل: هویت و اختیار برای سامانه‌های هوش مصنوعی

دادن کلید API بلندمدت کاربر به عامل هوش مصنوعی «تفویض اختیار» نیست؛ اشتراک اعتبارنامه با فراخوانی پیش‌بینی‌ناپذیر است. وقتی کلید به ابزار می‌رسد، سرور مقصد شاید حساب کاربر را بشناسد، اما نمی‌داند کدام عامل اقدام کرده، چه کاری آن را توجیه می‌کرده، چه کسی تأیید داده یا اختیار هنوز معتبر بوده است.

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

پیش از نوشتن سیاست، بازیگران را جدا کنید

تراکنش عامل ممکن است چند طرف مستقل داشته باشد:

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

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

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

به بارکاری هویت کوتاه‌عمر مستقل بدهید

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

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

هویت خدمت بومی ابر، هویت دستگاه مبتنی بر سخت‌افزار یا مرجع گواهی داخلی دقیق نیز می‌تواند این نقش را داشته باشد. در هر انتخاب، این موارد را بخواهید:

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

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

اختیار را به‌صورت کار محدود بیان کنید

نقش‌هایی مانند admin یا finance-agent برای اجرای خودکار بسیار گسترده‌اند. پوش مجوز باید دست‌کم این اجزا را داشته باشد:

این پوش باید ماشین‌خوان و در مرز منبع اعمال شود. RFC 9396 با عنوان Rich Authorization Requests ساختار استاندارد authorization_details را برای حمل جزئیات ریزدانه مجوز معرفی می‌کند. این RFC واژگان اقدام کسب‌وکار شما را تعریف نمی‌کند و خودبه‌خود درخواست را ایمن نمی‌سازد؛ سرور صدور و سرور منبع باید معنای مشترک داشته و آن را اعمال کنند.

در هر واگذاری، اختیار باید ثابت بماند یا کوچک‌تر شود. زیرعامل پژوهش شاید اجازه خواندن فایل‌های منتخب را بگیرد، نه اجازه ارسال ایمیل عامل والد. زمان‌بند شاید درخواست نگهداری موقت یک نوبت را بگیرد، نه اعتبارنامه قابل انتقال کاربر.

تفویض را حفظ کنید؛ خود را جای کاربر جا نزنید

RFC 8693 تبادل توکن OAuth، شامل معنای تفویض و جعل هویت را تعریف می‌کند. در تفویض، عامل اجراکننده می‌تواند به‌صورت «عمل‌کننده از طرف» فرد دیگر قابل مشاهده بماند. در جعل هویت، سامانه پایین‌دست ممکن است واسطه را خودِ فرد تلقی کند. هرجا معماری مقصد پشتیبانی می‌کند، برای عامل تفویض صریح بهتر است، چون زنجیره ممیزی کاربر و عامل را با هم نگه می‌دارد.

توکن تفویض‌شده یا قابلیت مشابه بهتر است شامل این موارد باشد:

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

تبادل توکن مدل اعتماد کامل نیست. RFC 8693 سیاست محلی، رفتار لغو و بسیاری از تصمیم‌های اعتماد را به استقرار واگذار می‌کند. فرض نکنید صرف تبادل توکن از افزایش اختیار جلوگیری می‌کند.

برای مسیر پرارزش از توکن مقید به فرستنده استفاده کنید. DPoP در RFC 9449 توکن را به کلید عمومی متصل می‌کند و در هر درخواست اثبات مالکیت کلید می‌خواهد؛ در نتیجه توکن حامل سرقت‌شده کم‌فایده‌تر می‌شود. TLS دوجانبه گزینه جاافتاده دیگری است. این قید جلوی سوءاستفاده عامل آلوده از اختیار معتبر خودش را نمی‌گیرد؛ بنابراین سیاست اقدام همچنان لازم است.

اجرای سیاست را در همه ابزارهای مهم قرار دهید

دستور پرامپت نقطه اعمال امنیت نیست. مدل اقدام را پیشنهاد می‌دهد، اما دروازه قطعی و سرور منبع باید اجرای آن را تصمیم بگیرند.

مسیر مقاوم چهار جزء دارد:

1. اطلاعات سیاست: فرد، عامل، مستأجر، وضعیت رکورد، ریسک، تأیید، زمان و کار؛
2. تصمیم سیاست: اجازه، رد یا نیاز به کنترل اضافی؛
3. اعمال سیاست: دروازه فراخوانی ابزار را تا تطبیق تصمیم و زمینه مسدود می‌کند؛
4. اعمال در منبع: API مقصد دوباره توکن، مخاطب، عملیات، سقف‌ها و نسخه رکورد را می‌سنجد.

این مسیر با اصل اعتماد صفر NIST SP 800-207 هم‌راستاست: موقعیت شبکه اعتماد ضمنی نمی‌آورد؛ منبع را محافظت و برای دسترسی تصمیم احراز و مجوز بگیرید. NIST SP 800-207A نیز برای هویت برنامه در محیط چندابری سیاست لایه هویت را شرح می‌دهد. هیچ‌یک استاندارد خاص عامل هوش مصنوعی نیستند، اما معماری قابل استفاده ارائه می‌کنند.

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

مثال عملی: بازپرداخت مشتری

فرض کنید عامل پشتیبانی بازپرداخت ۱٬۲۰۰٬۰۰۰ ریالی پیشنهاد می‌دهد:

1. کارمند وارد سامانه می‌شود و پرونده CASE-934 را باز می‌کند.
2. هماهنگ‌کننده اجرای refund-review/7f2a را با هویت بارکاری خودش می‌سازد.
3. خدمت توکن، اختیار نشست کارمند را با قابلیتی ۱۵ دقیقه‌ای و مقید به مخاطب عوض می‌کند که فقط یک سفارش را می‌خواند و تا سقف ۱٬۵۰۰٬۰۰۰ ریال پیشنهاد می‌دهد.
4. عامل سفارش را می‌خواند و سرور منبع مستأجر، مخاطب، عامل، فرد و دامنه سفارش را اعتبارسنجی می‌کند.
5. مدل پیشنهاد تایپ‌شده شامل دلیل، مبلغ و شاهد می‌سازد، اما نمی‌تواند پرداخت را اجرا کند.
6. کارمند پیش‌نمایش تغییرناپذیر را می‌بیند. تأیید دقیقاً نسخه سفارش، مبلغ، روش پرداخت مقصد و نسخه سیاست را ثبت می‌کند.
7. قابلیت یک‌بارمصرف تازه فقط refund.execute را برای همان مجموعه تأییدشده مجاز می‌کند.
8. خدمت پرداخت دوباره بررسی می‌کند سفارش قبلاً بازپرداخت نشده و کلید یکتایی عملیات را مصرف می‌کند.
9. دفتر ثبت، فرد، عامل، تأییدکننده، زنجیره تفویض، هش درخواست، تصمیم سیاست و نتیجه معتبر را نگه می‌دارد.

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

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

خرابی‌های رایج عبارت‌اند از:

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

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

لغو و پاسخ رخداد را عملیاتی کنید

عمر کوتاه دامنه خطر را کم می‌کند، اما جای لغو را نمی‌گیرد. چند کلید توقف بسازید:

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

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

راز را از پرامپت، متن گفت‌وگو، رد و تاریخچه ماندگار دور نگه دارید. مرجع کارگزار اعتبارنامه را ذخیره کنید، نه توکن تازه‌سازی خام. پس از احتمال نشت، کلیدها را بچرخانید و به‌اندازه لازم برای شناسایی اقدام‌های متاثر شاهد نگه دارید، نه بیشتر.

تصمیم را ممیزی کنید، نه استدلال پنهان را

رکورد ممیزی مؤثر باید این موارد را بگیرد:

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

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

دروازه‌های انتشار صفحه هویت عامل

پیش از اجازه نوشتن در تولید، این شروط را بخواهید:

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

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

وضعیت استانداردها و عدم قطعیت در ۲۰۲۶

NIST در فوریه ۲۰۲۶ «ابتکار استانداردهای عامل هوش مصنوعی» را راه‌اندازی کرد و احراز هویت عامل را حوزه پژوهش فعال دانست. سند هویت و مجوز NCCoE مرتبط با آن به‌صورت پیش‌نویس مقاله مفهومی منتشر شده، نه استاندارد نهایی هویت عامل. این نشانه توجه رسمی مهم است، اما نباید آن را گواهی یا اجماع نهایی بازاریابی کرد.

OAuth، DPoP، SPIFFE و معماری اعتماد صفر اجزای پخته می‌دهند. واژگان تفویض خاص عامل، تبادل سیاست میان فروشندگان، هویت زیرعامل‌های گذرا و لغو قابل حمل هنوز در حال تحول‌اند. برای نسخه صریح و آزمون سازگاری معماری کنید، نه با ادعای اینکه یک پروتکل کل پشته را حل کرده است.

پرسش‌های متداول

آیا هر اجرای عامل هویت تازه می‌خواهد؟

رده بارکاری می‌تواند هویت پایدار داشته باشد، اما هر اجرا باید شناسه یکتا و اختیار محدود به کار داشته باشد. اجرای پرریسک یا میان‌مستأجری ممکن است اعتبارنامه مستقل بخواهد.

آیا کنترل دسترسی مبتنی بر نقش کافی است؟

برای اقدام مهم عامل معمولاً خیر. نقش دروازه درشت‌دانه خوبی است؛ منبع، اقدام، هدف، ارزش، زمان، کار، مستأجر و شرط تأیید را اضافه کنید.

آیا عامل می‌تواند توکن تازه‌سازی OAuth کاربر را نگه دارد؟

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

هنگام اقدام عامل چه کسی پاسخ‌گوست؟

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

یادداشت منابع

منابع بررسی‌شده و جاری تا ۳۰ ژوئیه ۲۰۲۶:

• RFC 8693: تبادل توکن OAuth 2.0 — معنای استاندارد تفویض و جعل هویت در تبادل توکن.
• RFC 9396: درخواست مجوز غنی OAuth 2.0 — جزئیات ریزدانه مجوز؛ سیاست دامنه همچنان خاص استقرار است.
• RFC 9449 درباره DPoP و RFC 9700 بهترین رویه امنیت OAuth — قید فرستنده، کاهش بازپخش و محدودیت مخاطب و امتیاز.
• NIST SP 800-207: معماری اعتماد صفر — معماری احراز و مجوز منبع‌محور.
• استانداردهای SPIFFE — مشخصات باز هویت بارکاری، نه سیاست مجوز کسب‌وکار.
• ابتکار استانداردهای عامل هوش مصنوعی NIST — برنامه ۲۰۲۶ و کار پیش‌نویس هویت عامل؛ خروجی‌ها هنوز در حال توسعه‌اند.